Core agents
What is Stop Condition?
A stop condition is the rule that ends an agent run: done, blocked, escalated, or timed out.
Without a stop condition, an agent can loop forever or stall in plausible prose. Production systems declare stop policies explicitly.
Why it matters
Without a stop condition, an agent can loop forever, consuming compute and potentially taking harmful actions. Stop conditions are the safety boundary that turns an unbounded loop into a tractable system.
Production agents typically have multiple stop conditions: task-complete, maximum steps reached, budget exhausted, error threshold hit, or human escalation triggered.
Types of stop conditions
Hard stops include step limits, token budgets, and wall-clock timeouts — these fire regardless of the model's opinion. Soft stops include the model declaring "done" or a verification check passing. Production systems combine both: the model can stop early, but the hard limit prevents runaway.
The worst failure is no stop condition at all, where the agent loops in plausible-sounding but useless iterations.
Key takeaways
- 1Every agent must have at least one hard stop condition (timeout, step limit, or budget).
- 2Soft stops (model declares done) should be paired with hard stops.
- 3The cost of a missing stop condition is unbounded compute and potential harm.
Common mistakes
- ✕Relying solely on the model to know when it is done.
- ✕Setting step limits so high they never fire in practice.
- ✕Not logging why the agent stopped — was it done, or did it hit a limit?
Related terms
Concept neighborhood
Terms linked from Stop Condition in the glossary graph.
- Stop Condition
- Agent
- Guardrail
- Human-in-the-Loop
FAQ
- What happens if an agent has no stop condition?
- It loops until it runs out of tokens, money, or time. In production, this can mean thousands of dollars of wasted compute and potentially harmful side effects from unchecked tool calls.