Stop Conditions: Teaching an AI Agent When the Mission Is Actually Complete
Stop conditions define when an AI mission is actually complete, preventing agents from confusing continued activity with progress and giving users trustworthy completion signals.
An agent loop needs a real stopping point
OpenAI’s practical guide describes the agent run as a loop that continues until an exit condition such as final output, tool behavior, an error, or a maximum number of turns is reached. [1] Product designers should translate those runtime exits into meaningful task semantics. “The model stopped calling tools” is not necessarily the same as “the user’s mission is complete.” A study plan is complete when required components exist and constraints are satisfied; a purchase task may require explicit user acceptance before final action.
Runtime exit and goal completion are different
The harness knows when the loop stopped; the product must know whether the objective was actually achieved.
The runtime should distinguish final answers from interruptions
OpenAI’s running-agent guidance separates normal completion, failures, and pauses such as human approvals. [2] A stop-condition model should preserve the same categories. Waiting for consent is not success. Hitting a max-turn limit is not success. Returning a partial result because an external system is down may be a useful terminal state, but it should be labeled partial. Honest state prevents gamified interfaces from awarding completion for technical termination.
Resumable state makes pause different from finish
OpenAI’s Results and State guidance explains that interrupted runs may carry saved state and pending approvals rather than a final output. [3] This is essential to completion design. A mission can be paused for hours while still remaining one mission. The UI should show what remains pending and what will happen after resumption. Treating every pause as a fresh quest fragments continuity and increases the risk of duplicated actions.
Paused is a first-class state
Systems should not force every run into the binary of success or failure.
Simple agents benefit from explicit exit criteria too
Anthropic recommends simple composable patterns and increasing agentic complexity only where needed. [4] Even a simple loop should know what “done” means. A coding agent can stop when tests pass and requested changes are present. A research agent can stop after required claims have supporting sources and unanswered questions are surfaced. Explicit criteria reduce wandering and make later evaluation possible.
Completion rules must be evaluated against traces
Workflow evaluation can inspect whether the agent chose the right tools, followed policy, and completed the intended path. [5] Teams should include false-completion cases: missing required fields, unverified external writes, unresolved blockers, or outputs that superficially resemble success. They should also test overwork: does the agent continue searching after confidence is already sufficient? Good stop conditions minimize both premature exit and needless continuation.
Test the two failure directions
Stopping too early loses quality; stopping too late wastes resources and may create new risks.
Use layered completion criteria
A robust mission often has several gates: structural completeness, factual or technical verification, side-effect confirmation, policy compliance, and user acceptance. Not every task needs all five, but the relevant layers should be explicit. For example, “draft complete” may be enough for an email-writing quest, while “message sent” requires external confirmation from the tool. This layered model also supports partial credit without confusing partial progress with final success.
Budgets are valid terminal constraints
An agent can be required to stop because it has exhausted a time, cost, retry, or tool-call budget even if the ideal goal is unfinished. That should produce a structured handoff: what was completed, what remains, and the best next action. A budget stop is not shameful failure; it is a designed boundary. In motivational systems, framing it honestly protects the user from the false promise that persistence is always beneficial.
Persistence is not the goal
A well-designed agent knows when further effort has diminishing returns or unacceptable risk.
Completion should be visible, evidence-based, and revisable
When the system marks a quest complete, it should show the evidence: artifact created, tests passed, appointment booked, approval recorded, or criteria satisfied. If later evidence invalidates that state, the quest can reopen with an explanation. This makes progress trustworthy. The agent learns that “done” is a claim supported by observable conditions, and the user learns that completion is not a decorative badge but a shared judgment about the actual state of the world.
Stop conditions should also account for user intent changing during the run. A mission that began as “find the best option” may become “give me three acceptable options and stop” once the user sees enough evidence. The current objective should therefore be revisable, and completion should be evaluated against the latest confirmed goal rather than the initial prompt forever. This matters for motivation because over-automation can feel as frustrating as under-delivery. An agent that keeps polishing after the user is satisfied is not demonstrating diligence; it is ignoring a newly established stopping rule. Completion belongs to the shared state between person and system, not solely to the model’s internal estimate of whether more work is possible.
Works Cited
- 01
- 02OpenAI Developers — Running Agents developers.openai.com
- 03OpenAI Developers — Results and State developers.openai.com
- 04Anthropic — Building Effective AI Agents anthropic.com
- 05OpenAI Developers — Evaluate Agent Workflows developers.openai.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.