Agent Architecture and Orchestration
Termination Conditions — Stack
Termination conditions › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The question is what can be checked, how cheaply, and whether the check can be trusted when it says the work is done.
- Verifiability. Whether completion can be established against something outside the model — a record exists, a test passes, a schema validates — or only by assertion.
- Cost of the check. What establishing completion costs relative to the work itself, since a verifier that costs as much as the run changes the economics entirely.
- Enforcement location. Whether ceilings are enforced by code the model cannot influence, or merely communicated to it.
- Partial-result support. Whether the mechanism can return incomplete work with an honest status rather than failing empty.
- Reason recording. Whether the rule that fired is captured in a form that can be counted across runs.
- Collective conditions. Whether completion can be expressed for an objective spanning several participants, not just for one.
- Blocking-wait safety. Whether every wait on an external signal carries its own timeout and terminal outcome.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Deterministic postcondition checks against the world | Tasks with an observable result: a file compiles, a record exists, a test suite passes | Only available where the outcome is mechanically checkable; most conversational work is not |
| Valid structured output as the completion signal | Extraction, classification, and generation with a defined result shape | Validates the shape, never the content; a schema-valid wrong answer ends the run successfully |
| Verifier model or scored rubric | Open-ended work where only a judgement is possible | Inherits the biases of model-based judging, including preference for length and surface fluency |
| Iteration, token, time, and spend ceilings in the loop | Guaranteeing an upper bound on any run regardless of what else exists | Bounds cost and defines nothing; every exhausted run is indistinguishable without reason codes |
| Framework stop conditions (termination predicates, maximum-turn settings, graph end nodes) | Teams using a runtime that already evaluates conditions between turns | Defaults are usually a turn ceiling alone; composability of several conditions varies widely |
| Workflow-engine timeouts and cancellation | Durable long-running work needing enforcement outside the agent process | Engine-level cancellation may leave agent-level cleanup unperformed unless wired deliberately |
| Budget guard at the gateway or proxy layer | Enforcing a ceiling across many services without trusting each to enforce its own | Stops calls without any notion of the task, so partial results are usually lost |
| Explicit human stop control | Anything consequential, interactive, or long-running | Requires a reachable, low-latency path to the running work, which is a design commitment |