How it works
A stop condition turns “keep going” from an implicit model choice into a harness decision. The harness evaluates declared predicates at controlled points in the agent loop, usually before or after a model call, tool invocation, retry, delegation, or state transition. When a predicate matches, the harness stops scheduling new work and records why the run ended.
A practical control loop is:
- Load the authoritative run state, including goals, budgets, attempts, approvals, and outstanding work.
- Evaluate completion and failure predicates before granting another unit of execution.
- Execute one bounded step if no condition has matched.
- Persist the step result, costs, side effects, and updated state.
- Evaluate stop conditions again, then terminate, pause, recover, or continue.
Conditions should be deterministic where possible. Examples include a verified output artifact, an exhausted iteration budget, a denied approval, a safety-policy violation, an unrecoverable tool error, or a deadline. A model may supply evidence that completion has occurred, but the harness should verify that evidence against the run contract instead of accepting a self-reported “done.”
Stopping also needs a terminal classification. Completed, failed, cancelled, budget-exhausted, and blocked are materially different outcomes. Collapsing them into a generic stopped state makes recovery and evaluation unreliable.
Why it matters in an agent harness
An agent loop has no natural obligation to end. A model can keep refining an answer, retrying a failed tool, spawning subtasks, or alternating between planning and evaluation. Without an external stopping rule, progress is judged by the same stochastic component producing the work. That is a weak control boundary.
Stop conditions contain cost and blast radius. An iteration limit bounds repeated reasoning. A tool budget limits external actions. A deadline prevents abandoned work from consuming capacity indefinitely. A permission failure can stop execution before the agent searches for an unauthorized workaround. These controls matter even when the model is capable and the task appears routine, because loops fail through accumulation as often as through one dramatic action.
They also make runs legible. Operators need to distinguish successful completion from forced termination, infrastructure failure, and ambiguous outcomes. The terminal reason should therefore be written to the execution journal with the condition evaluated, the relevant state, and the last committed step. That record supports debugging, evaluation, and later policy changes.
A stop condition must account for side effects already in flight. Halting future scheduling does not prove that a timed-out tool call failed or that an external write did not occur. If the outcome is unknown, the harness should preserve that uncertainty and reconcile it before retrying. Idempotency keys, checkpoints, and compensating actions handle consequences that a stop rule alone cannot reverse.
The design tradeoff is between premature termination and uncontrolled continuation. Tight limits can stop useful work before convergence. Loose limits can hide loops until they become expensive or unsafe. I prefer separate budgets for model turns, tool calls, retries, elapsed time, and delegated work because one aggregate counter conceals which resource is actually under pressure.
Stop condition vs interrupt
The distinction affects recovery. A stop condition is part of the run contract and is evaluated by the harness. An interrupt is an event that requests attention or suspension, often arriving from an operator, scheduler, operating system, or another control component.
| Axis | Stop condition | Interrupt |
|---|---|---|
| Trigger | Declared state predicate | External or asynchronous event |
| Expected outcome | Terminal classification | Pause, cancellation, or controlled shutdown |
| Recovery | Start a new run or follow the declared recovery contract | Resume when safe if state was checkpointed |
| Example | Tool-call budget reaches its limit | Operator requests an immediate pause |
An interrupt may activate a stop condition, but the terms are not interchangeable. Treating every interrupt as final prevents safe resumption. Treating every stop as resumable can continue work after a hard safety or authorization boundary has been reached.
The Rifty take
We treat stopping as a first-class control contract, not a prompt instruction. We accept that explicit limits sometimes end work early because a visible, classified termination is easier to inspect and recover from than unbounded progress. A model can recommend stopping, but the harness owns the decision and the terminal record.
Implementation checks
- Define completion, failure, budget, safety, cancellation, and blocked conditions separately.
- Evaluate conditions at stable boundaries before and after consequential actions.
- Persist state before declaring a terminal outcome.
- Record the matched condition and the evidence used to evaluate it.
- Do not treat a timeout as proof that an external action failed.
- Bound retries independently from total iterations and tool calls.
- Verify model-reported completion against the run contract.
- Test precedence when multiple conditions become true together.
- Make hard stops distinct from resumable pauses.
- Exercise each condition with a failure test, including shutdown during an in-flight side effect.
Frequently asked questions
Should the model decide when an agent run is complete?
The model may propose that the task is complete, but the harness should make the terminal decision. It can verify required artifacts, checks, approvals, and outstanding work against the run contract. This prevents a persuasive completion message from substituting for evidence that the requested work actually exists.
What happens when several stop conditions match at once?
The harness should apply a documented precedence rule and retain every matched condition in the run record. Safety and authorization boundaries normally outrank completion, while an unknown external outcome may require reconciliation before success can be declared. Test these collisions because evaluation order can otherwise change the reported result.
Is a timeout a sufficient stop condition?
A timeout is a valid execution limit, but it is not evidence about the outcome of an in-flight action. The harness should stop scheduling further work, classify the result as uncertain where appropriate, and reconcile external state before retrying. Otherwise, a late successful write can be duplicated.
How should stop conditions work with checkpoints?
The harness should persist a checkpoint before recording a resumable stop whenever the execution boundary permits it. The checkpoint identifies committed work, pending actions, budgets, and the terminal reason. Hard safety or authorization stops may forbid resumption, while operator interrupts and infrastructure pauses can follow an explicit recovery contract.
How do you choose useful execution limits?
Choose limits from the task contract and the consequences of continued execution, then measure them independently. Model turns, tool calls, retries, elapsed time, and delegated tasks fail differently. Start conservatively, inspect where legitimate runs terminate, and revise the relevant limit without weakening unrelated safety or permission boundaries.