Stopping Conditions: Preventing Infinite Agent Loops

Infinite agent loops pose a significant liability when dealing with stochastic decision-makers. Each agent requires multiple halt conditions to catch different pathologies, as none of them can catch all of them. The naive loop ends when the model stops requesting tools, but this approach is incorrect as control should flow in the opposite direction. There are four ways this naive loop fails to terminate: oscillation, optimistic re-checking, goal drift, and ambiguous completion.

Oscillation occurs when an agent edits a file, tests fail, reverts the edit, and tests fail differently, creating a cycle with no exit. Optimistic re-checking happens when a tool returns empty, leading the model to conclude it must have made a small mistake and retrying with a trivially different query. Goal drift occurs when the original task scrolls out of context or gets summarized away, causing the agent to continue working on adjacent, plausible tasks without a clear completion.

Ambiguous completion arises when there is no observable predicate for "done," such as the case with the instruction "improve the docs" where nothing in the environment signals that the task is complete.

While prompting can help mitigate some of these issues, they cannot be entirely fixed by simply adjusting prompts. The root cause of these problems lies in the model's inability to see its own history as a pattern and the finite window of the task. To address these challenges, an instruction like "do not repeat yourself" can provide marginal assistance, but the true control lies in the code that enforces limits.

To prevent infinite loops, six independent conditions can be applied. These conditions include a hard cap on loop iterations, cumulative input and output tokens, cost budgeting, a wall clock timeout, no progress detection, and an explicit finish tool call with a structured result. Each of these checks serves a distinct purpose in ensuring that an agent's run is stopped appropriately.

A hard cap on loop iterations is the crudest and most reliable method, setting the cap based on the task type. Tracking cumulative tokens and cost allows for budget enforcement, which remains relevant regardless of model changes during a run. Monitoring wall clock time bounds the user's wait time and identifies tools that may hang without timing out.

No progress detection catches oscillation, where repeated calls and results fail to produce new information, and explicit finish tool calls signify successful completion.