AgenticBook
Back to Handbook

Chapter 03 · Postmortem

Why agents enter loops: five real failure cases

The most common reasons production agents repeat actions, hallucinate tool calls, or spend without making progress—and the recovery patterns that work.

01

Detect repeated trajectories

A loop is usually a missing state transition disguised as model creativity.

The first failure case is an agent that retries the same search with slightly different wording. The second is a tool that returns an ambiguous error, causing the model to call it again. The third is a planner that recreates a completed task because completion was never written into state. Hash normalized tool names and arguments, compare recent observations, and emit a loop signal before the budget is exhausted.

  • Detect identical and near-identical tool calls in a sliding window.
  • Mark completed work in structured state, not only in prose.
  • Treat repeated errors as a state transition to recovery, not another prompt.
Editor's takeaway

Loop detection belongs in the runtime, not in a hope that the next prompt will be better.

02

Bound actions and context

Unlimited retries turn small uncertainty into an operational incident.

A production agent needs independent budgets: maximum turns, tool calls, wall-clock time, tokens, and estimated spend. Context also needs a budget. Summarize completed work, discard irrelevant tool payloads, and preserve only the evidence required for the next decision. A context window is not a queue.

  • Set per-tool and aggregate budgets.
  • Use deadlines propagated to every downstream call.
  • Summarize observations with links to durable trace records.
Editor's takeaway

A limit is not a failure of intelligence. It is the contract that makes autonomy safe enough to operate.

03

Recover without hiding failures

A good recovery is explicit, bounded, and useful to the person operating the system.

When an agent loops, stop the loop, preserve the trajectory, and classify the failure. Then choose a recovery: ask a clarifying question, fall back to a deterministic workflow, request human approval, or return a partial result with the missing step clearly named. Do not silently restart from a blank context; that destroys the evidence needed to fix the system.

  • Return a stable reason code such as TOOL_TIMEOUT or LOOP_DETECTED.
  • Expose the last safe action and the next recommended operator step.
  • Add every resolved incident to a regression dataset.
Editor's takeaway

The goal is not zero failures. It is fast, honest recovery and a system that becomes harder to break.

Field note

Ship the smallest reliable workflow first. Add autonomy only when your evaluation data shows that it improves outcomes.

More chapters