Agent Architectures: Control Loops, State & Planning › Termination Conditions

Without explicit termination conditions, agents might loop indefinitely, consume excessive resources, or pursue goals long after they have been achieved. Defining when an agent should stop is as necessary as defining how it should act. Termination conditions serve as guardrails that ensure agents remain practical tools rather than runaway processes, and they give the closure that allows users to receive results and move on.

Termination is philosophically interesting because it requires the agent to judge its own work. A human completing a task has an intuitive sense of "doneness": the report is written, the dish is cooked, the equation is solved. An LLM-based agent must make this judgment computationally, often without perfect information. Designing termination conditions that are neither too eager (cutting off before the task is complete) nor too reluctant (continuing long after the goal is achieved) is one of the more fine-grained aspects of agent architecture design.

The most intuitive termination condition occurs when the agent reaches its stated objective. For question-answering agents, this means giving a satisfactory answer; for task-completion agents, it means executing the requested action successfully. However, determining "success" requires careful definition upfront, because ambiguous success criteria produce agents that cannot reliably know when to stop.

Explicit success signals occur when external systems confirm task completion: a file is successfully written, a database transaction commits, or an API returns a success status code. These give unambiguous termination criteria. When a file write returns a success code, the agent can confidently conclude that the persistence task is complete. These signals are objective and verifiable, eliminating the need for the agent to make a subjective judgment about whether the work is done. Whenever possible, designing tasks around explicit success signals makes termination reliable and predictable.

Implicit success detection requires the agent to recognize when its goal is satisfied without an external signal. A research agent might terminate when it has gathered sufficient information to answer the original question, requiring self-assessment of coverage and confidence. This is akin to knowing when to stop reading and start writing an essay: there is no external signal that you have read enough, only an internal judgment that you have achieved sufficient understanding. Implementing implicit success detection often requires heuristics such as information saturation (new sources are not adding facts not already in working memory), confidence thresholds in generated answers, or a coverage checklist that the agent maintains and checks against its accumulated knowledge.

Practical deployments impose hard constraints on agent execution to control costs and prevent system degradation. These limits are not signs of poor design but prudent engineering: they acknowledge that agents operate in resource-constrained environments and must be accountable for what they consume.

Token budgets limit the total number of tokens processed or generated. Given the cost and latency implications of LLM inference, agents might terminate when approaching token limits, returning partial results or requesting user guidance. This is especially important in commercial deployments where API costs scale directly with token usage. An agent configured with a budget of 100,000 tokens must prioritize its remaining actions carefully once it has consumed 80,000, perhaps switching from exploratory search to synthesis even if the exploration feels incomplete. Token budgets force agents to make economically rational tradeoffs between thoroughness and cost.

Time limits cap wall-clock execution duration. Long-running agents might hit timeouts during extended tool executions or during reasoning phases. Time limits protect against hung processes and ensure that users receive responses within acceptable windows. They also force agents to prioritize speed versus thoroughness in ways that should be calibrated to the use case: a customer service chatbot needs responses in under a second, while a research assistant running as a background task might be allowed minutes or even hours to compile a complete report. The time limit communicates to the agent what kind of task it is performing and what level of thoroughness is expected.

Iteration limits restrict the number of loop cycles. This prevents infinite loops in misconfigured agents and guards against tasks that expand beyond their original scope through uncontrolled replanning or goal drift. Without iteration limits, an agent stuck in a cycle of "search for more information" might never conclude that it has enough data. Iteration limits are typically set between 5 and 50 depending on task complexity: simple fact retrieval might need only 3 iterations, while complex debugging might require 20 or more before a fix is found and validated.

Beyond resource constraints, safety considerations demand termination conditions that protect users and systems from harm. These conditions must fire unconditionally, regardless of task completion status, because the risk of proceeding outweighs any benefit.

Error thresholds trigger termination when consecutive tool failures or reasoning errors exceed a set limit, preventing agents from spiraling into unproductive error states. If an agent fails to connect to a database five times consecutively, continuing to retry is unlikely to help and may lock resources, trigger security alerts, or violate rate limits. Error thresholds recognize when the agent has lost its ability to make progress and redirect control to human operators or graceful failure handlers.

Content policies halt execution when agents generate prohibited content or attempt harmful actions. An agent instructed to research sensitive topics might encounter content that violates privacy policies, generates legally problematic material, or produces outputs that could facilitate harm. Content policy checks should run after every action and terminate execution immediately when violations are detected, with clear logging to support incident review.

User intervention allows human operators to terminate or redirect agents during execution, maintaining human oversight over autonomous systems. This might take the form of a "stop button" in a user interface, or periodic checkpoints where the agent pauses to request confirmation before proceeding with irreversible actions like deleting files, sending emails, or committing database transactions. User intervention preserves human agency in necessary decision loops. This keeps automated systems remain tools serving human intent rather than autonomous actors pursuing misaligned objectives. As agent autonomy increases, the design of intervention mechanisms becomes more important, not less: the more capable an agent is, the more consequential it is to get these mechanisms right.