When an agent exhausts its budget mid-task, should it return partial results or continue?

## Exhaustion is a product decision When an agent hits its iteration cap, its token budget, or its cost ceiling with work outstanding, the harness has three options: return what it has, keep going somehow, or fail. Most teams discover only in production that they picked the wrong default. This is a policy question about how your product degrades, and it deserves the same thought as any other partial-failure design. ## Is partial output valuable? The deciding property is whether the task **accumulates**. - **Accumulative tasks** produce independently useful units: bugs found, tests written, records reconciled, documents classified, files reviewed. A QA agent that explored six of ten levels and found eleven bugs has produced eleven real bugs. Returning them with a `budget_exhausted` marker and a note that levels seven to ten were not visited is straightforwardly better than returning an error, because the consumer can act on the eleven and re-run for the rest. - **All-or-nothing tasks** produce one answer that is either right or misleading: a migration plan, a diagnosis, a financial reconciliation total. Half a reconciliation is not half correct — it is a number that looks authoritative and is wrong. Here the honest response is a failure with the trace attached, not a partial artifact. The failure to avoid is returning partial output *shaped like* complete output. If the caller cannot distinguish "here is the full bug list" from "here is what I found before running out", you have converted a budget event into a silent correctness bug. This is why the status belongs in the result type rather than in a sentence of prose the model wrote. ## Is continuing legitimate? The usual mechanism for continuing past a window limit is to compress the history and carry on with a summary plus the working artifacts. It genuinely works for long-horizon tasks and is standard practice. But as an *exhaustion policy* it has three costs worth stating plainly: - It spends more money than the budget the caller agreed to. If your cost ceiling exists to protect a per-user margin, continuing silently defeats it. - It adds latency, often multiplying the wait for a user already waiting. - It loses information. What survives is what the summariser chose to keep, and a detail dropped at step forty cannot be recovered at step ninety. So continuing is reasonable when the task is genuinely long-horizon and checkpointable, when the extra spend is authorised (by a caller-set tier, an operator policy, or a human in the loop), and when the run is asynchronous enough that latency does not matter. It is unreasonable as a silent default on a user-facing budget cap. ## Design so exhaustion is rare and graceful The strongest answer moves the problem upstream: - **Give the model an advisory budget** so it paces itself and lands on an answer rather than being cut off. Most exhaustion events should be soft landings, not hard truncations. - **Expose depth as a caller choice.** Named effort tiers — a quick pass versus a thorough investigation — let the caller size the run before it starts, which is far better than discovering at the cap that they wanted more. - **Externalise progress.** If the agent writes findings to a file or a todo list as it goes, partial results exist by construction and a resumed run can pick up where the last one stopped, rather than repeating everything. - **Bound tool payloads** so one enormous observation cannot consume a budget the model was pacing against. ## Irreversibility changes the calculus One more axis: what state did the agent leave behind? A read-only research agent can be stopped anywhere. An agent halfway through a sequence of writes — three of seven migrations applied, half a batch of tickets updated — cannot simply be abandoned. Either make the steps idempotent so a re-run converges, or record enough checkpoint state that a resumed run knows exactly where it stopped, or refuse to begin the sequence unless the remaining budget can plausibly finish it. Checking the remaining budget *before* starting an irreversible sequence is the cheap version of this and is often skipped. ## What a strong answer sounds like A principal-level response does not pick one option. It says: classify the task as accumulative or all-or-nothing, make the partial shape explicit in the contract so nothing masquerades as complete, keep continuing behind an authorisation decision rather than a silent default, and push the real fix upstream into pacing and depth selection so exhaustion becomes the rare tail rather than the routine ending.