Termination Conditions

What it is

The explicit rules that decide a run is over and record which rule ended it: the goal's checkable criteria are satisfied, an allowance or deadline is exhausted, a required input never arrived, a policy forbids continuing, or a person stopped it. Every run ends under exactly one of them, and which one fired is part of the result rather than an implementation detail.

Why it matters

An agent has no inherent sense of completion. Left to itself it will keep producing a plausible next step, because producing a plausible next step is what it does. These rules are where "finished" is defined by the system rather than asserted by the model. The classification matters as much as the stop: finished successfully, exhausted its budget at roughly seventy percent, and blocked awaiting an approval are three entirely different outcomes that a boolean result flattens into one, and retry policy, billing, and what the user is told all depend on telling them apart.

A backstop is not a definition of done

Iteration ceilings, spend caps, and deadlines exist to bound damage when everything else has failed. They are not criteria for completion, and a system whose only rule is a ceiling has no notion of done at all — it has a timer. The distinguishing question is whether anything would have stopped the run earlier had the work actually succeeded. If not, every run costs the maximum and the result is whatever happened to be in hand when the timer expired.

Key decisions

• How success is judged: a deterministic check against the world, a valid structured output, a verifier model, or the agent's own declaration.
• Which backstops exist and at what levels — iterations, wall clock, spend, tool calls, context size — and whether they are enforced outside the model.
• What is returned under each ending, and in particular whether partial work is preserved or discarded.
• Whether the agent may declare itself finished, and whether that declaration is verified before being accepted.
• Whether ending is per participant or per objective in a coordinated effort, and who is entitled to declare the objective over.
• What a terminated run leaves behind: committed effects, released resources, a resumable snapshot, or nothing at all.

Failure modes

• The only rule is the iteration ceiling, so every run costs the maximum and the answer is whatever the last turn happened to produce.
• Success is the model stating that it has completed the task; it states this on runs that accomplished nothing, with the same confidence.
• The budget rule discards everything on firing, so a run that was nearly complete yields nothing and its retry begins again from zero.
• A deadline is enforced only at the outer boundary while an inner call has no timeout of its own, and the run runs past its deadline waiting.
• In a coordinated effort the run ends when the coordinator stops, while participants keep working and writing into a record nobody is reading.
• Reasons for ending are not recorded, so the only available metric is completion rate and nobody notices that a third of completions are exhaustions.
• The rule depends on an external signal that can never arrive, with no timeout behind it, and the run waits indefinitely while appearing healthy.
• Success criteria live as prose in the instructions and are evaluated by the same model that produced the work, which marks its own output as meeting them.

Related capabilities

• Execution Loop — evaluates these rules between iterations
• Loop Detection — a diagnosis that feeds one of these rules
• Planning Engine — supplies per-step criteria these rules can check
• Agent Lifecycle — the terminal state an instance enters as a result
• Interrupt and Resume — the alternative to ending, when the work should continue later

Applies: Production readiness · Design questions