What belongs in an AI agent stopping rule?
An AI agent stopping rule should distinguish verified completion, a required handoff, a resource limit and a lack of useful progress. Define the evidence for each condition, the component that enforces it and what happens to unfinished work. Reaching a limit ends an attempt; it does not establish that the requested task succeeded.
AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. Editorial policy.
Key takeaways
- Separate the condition that makes a task complete from the limits that prevent an attempt from continuing indefinitely.
- Define what counts as progress and which missing information requires a handoff before running the agent unattended.
- Test each stopping condition alone, including its saved output and recovery path, rather than relying on a final success message.
Give completion and limits different meanings
An instruction to keep working until the answer is good leaves two decisions undefined: what makes the answer acceptable, and what ends an unsuccessful attempt. A useful stopping rule answers both. It should also explain when the agent needs something only a person or another service can provide.
Anthropic's Building effective agents describes agents using feedback from their environment, pausing for human input and operating with stopping conditions such as iteration limits. The article was published in December 2024 and now carries a tooling-change notice. We use its general design principle here, not its examples as evidence of a current product release.
Consider our fictional research assistant, asked to compare the export formats of three named tools and save one note. Completion requires an answer for each tool supported by its official documentation, or a visible unresolved field where that documentation provides no answer. The note must be saved and read back. Merely reaching the end of a conversation does not satisfy those conditions. This is an illustrative design, not a measured BotBento run; BotBento remains in development.
Sources: Building effective agents.
Write four explicit decisions for one task
For the research assistant, we propose the following four decisions. They are an application contract, not names required by a framework. Write them before choosing a message count or timeout so that the numbers serve a defined task.
For example, an official page that says nothing about an export format leaves a useful unknown. The assistant can mark that field unresolved and finish the agreed comparison. A missing destination workspace is different: without knowing where to save the note, it cannot satisfy the requested delivery. That should trigger a handoff rather than a guessed destination.
- Complete: every requested tool has a cited answer or a clearly marked unknown, and the note exists in the agreed destination.
- Needs input: an unresolved choice would change the task's scope, authority or destination; ask the specific question and preserve the draft.
- Limit reached: the configured attempt allowance is exhausted; stop starting new work and report the unmet acceptance conditions.
- No useful progress: repeated steps produce no new relevant evidence or resolution; explain the blockage instead of silently repeating them.
Match each limit to something the runtime measures
AutoGen's AgentChat documentation offers termination conditions for message count, reported token usage, elapsed duration, handoffs and external control. It also allows conditions to be combined with AND or OR. Token-based termination depends on agents reporting their usage. These are examples of available mechanisms, not interchangeable definitions of task completion.
In our proposed research routine, count source retrieval attempts separately from model turns. One turn might request several pages, while another only summarizes existing evidence. If the operator cares about elapsed time or provider spending, a turn limit alone is insufficient evidence that those separate allowances are enforced. Define how the relevant measurement is collected and who owns it.
Review the combination logic as well. If either a cancellation request or an exhausted allowance should stop new work, combining those conditions so that both must be true would violate that intention. Test the actual behavior at each boundary. Also define what a stop means for work already in flight: stop scheduling, cancellation requested and remote action confirmed cancelled are different observations. Do not promise cancellation of an external action without a supported mechanism and a checked result.
Sources: Termination.
Inspect a loop before raising its allowance
LangGraph documents GRAPH_RECURSION_LIMIT as reaching the maximum number of steps before a stopping condition. Its troubleshooting guidance distinguishes an unintended cycle from a complex graph that legitimately needs more steps. Increasing the configured limit is therefore a possible adjustment, not a diagnosis of why the previous attempt stopped.
For our research example, imagine the assistant repeatedly opening the same overview page even though the missing answer is absent. A useful progress check asks whether a step supplied a new relevant source, resolved a field or saved a reviewed result. Simply restating the plan should not count. This is our suggested evaluation rule, and it needs tuning against the actual task.
Record the last useful change and the repeated action, then inspect why the agent chose it. Perhaps the tool result was not available to the next step, or the completion condition could never be satisfied. Raising the allowance before understanding that behavior can leave the same unresolved condition after a longer run. A larger legitimate task may need more room, but that decision should follow evidence about the work remaining.
Sources: GRAPH_RECURSION_LIMIT.
Test the exits and the next attempt together
Use disposable inputs to exercise four cases: all sources answer the question, a required destination is missing, the attempt allowance expires, and the same source keeps returning no useful answer. For each case, inspect why the agent stopped, what was saved and which acceptance conditions remain open. These are proposed tests; no pass rates or production outcomes are claimed here.
Then resume from the retained state. Check that the assistant reuses the existing draft, preserves unresolved external effects and does not reset the logical task's allowances accidentally. An operator may authorize another attempt, but the new attempt should remain connected to the earlier result. Otherwise, a per-attempt limit can hide an indefinitely repeated routine.
Keep the final message short and actionable: where the output is, which condition ended the attempt and what would allow the remaining work to continue. A stopping rule is useful when another person can make that next decision without reconstructing every tool call.
Primary sources
Sources checked 2026-09-10. Standards and product documentation can change; follow the linked version when implementing.
- Building effective agents — Anthropic
- Termination — Microsoft AutoGen
- GRAPH_RECURSION_LIMIT — LangChain
BotBento is in development. Suggest a correction.