The pipeline that succeeded without doing the work

Four agent jobs ran in sequence overnight. The first was supposed to finish a LinkedIn workflow before the next job started. It did not finish: the Agent used every allowed iteration and printed Task incomplete. The shell saw exit zero, marked the step green, and launched the other three anyway.

By morning, the run log looked healthy. Only the English sentence buried in stdout revealed that the first job had stopped halfway through. The later jobs had inherited an assumption that was never true, and the scheduler had no signal it could use to halt or retry. Raising the iteration limit made the run more expensive, but did not make that signal any more honest.

The important turn was realizing that the partial answer was not the problem. It was useful evidence and, for a resumable session, worth preserving. The lie was the process status. We changed one-shot execution so it commits the partial session and prints the result, then exits nonzero when the terminal reason is max_iterations. JSON mode makes the same distinction explicit:

{"session_id":"...","result":"...","outcome":"max_iterations","error":null}

A naturally completed turn reports outcome: "natural" and exits zero; an execution failure reports outcome: "error". An orchestrator can now stop, alert, or resume based on data instead of grepping prose.

The lesson was smaller than a new budgeting system: a safety limit is not a success criterion. Cost ceilings and in-context budget guidance need their own design, but no future budget feature can compensate for reporting unfinished work as green.