Agent loops are one of the fastest ways to lose trust in production. Users see repeated actions, costs spike, and tooling gets hammered. Many loops are not "model stupidity". They are predictable outcomes of missing budgets, unclear termination criteria, and unsafe retry behaviour.
Common loop patterns
Most loops fall into a small set of patterns:
- Retry loops. The agent retries the same failing tool call indefinitely.
- Planning loops. The agent keeps re-planning without making progress.
- Observation loops. The agent cannot interpret a tool result and repeats steps.
- Fan-out loops. The agent calls too many tools in parallel or expands scope unintentionally.
Good tracing makes these patterns obvious (see agent run tracing).
Control 1: step budgets and hard stops
Every agent run needs a bounded budget. Useful budgets include:
- Max steps per run. Stop after N reasoning/tool steps.
- Max tool calls per run. Cap tool invocations and restrict fan-out.
- Token and cost budgets. Abort or degrade when the run exceeds a cost threshold (see cost guardrails).
- Time budgets. End-to-end deadlines; do not let slow tools stall forever.
Budgets are not a failure. They are a product decision: the system must degrade predictably rather than loop indefinitely (see fallback and degradation).
Control 2: explicit termination criteria
Many loops happen because the agent never knows what "done" means. Define termination criteria at the task boundary:
- Success signals. What tool result or state change indicates completion.
- Safe completion. When to stop and hand back a partial answer.
- Escalation triggers. When to ask for approval or handoff (see agent approvals).
These criteria should be testable and observable, not implied.
Control 3: tool idempotency and deduplication
Even with budgets, retries can cause duplicate side effects. Design tools for safe retries:
- Idempotency keys. A stable key per user intent prevents duplicated writes.
- Read-after-write checks. Confirm state before repeating the action.
- Strict tool contracts. Validate inputs and return machine-readable errors (see tool contracts).
Control 4: retry policies by error class
A single retry rule is not enough. Use an error taxonomy to drive safe behaviour:
- Retryable. Timeouts and transient 5xx, with exponential backoff and jitter.
- Non-retryable. Validation errors; do not retry, ask a question or fix arguments.
- Permission errors. Stop and request approval or explain access limits.
This is easiest when tools return consistent errors (see error taxonomy and tool error handling).
Control 5: user-facing fallbacks
When a loop is detected or a budget is exhausted, the system should stop cleanly:
- Summarise what was attempted and what failed.
- Offer a safe next action (retry later, switch mode, or human handoff).
- Provide a reference ID for support so runs can be traced.
Measure loop health
Loop prevention is operational. Track:
- Mean steps per successful run.
- Aborted runs due to budgets.
- Tool retry rates and repeated tool calls per run.
These metrics should appear next to task success rates (see reliability metrics).
When you bound agent behaviour with budgets and clear termination criteria, loops become rare and diagnosable instead of unpredictable and expensive.