Describe two distinct conditions that cause an agent loop to run indefinitely. Then name three runtime safeguards, explaining why each one alone is insufficient as the only protection.
Loops come from same-tool repetition and no-progress oscillation. Step caps, call dedup, and progress checks each miss a case, so production stacks all three plus a cost and time budget.
Imagine someone lost in a hedge maze. One way they get stuck is walking into the same dead end over and over, never learning it is a dead end. Another way is pacing back and forth between two spots, looking busy but going nowhere. A simple fix is a kitchen timer: when it rings, leave the maze. But the timer is dumb, it might ring while you are about to find the exit, or let you wander for an hour first. So you add more checks. One watches for the same wrong turn twice. One watches whether you are actually getting closer to the exit. No single check catches everything, because each one is blind to a different kind of stuck. Only stacking them all makes the maze safe to enter.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
An infinite agent loop is the failure mode where the observe reason act cycle never reaches a terminal final-answer state. The runtime keeps asking the model for the next action, the model keeps producing one, and no exit condition ever fires. In production this is not a hypothetical. It is one of the most common ways an agent run turns into a runaway cost line or a hung request, and it shows up the moment you give a model a tool and a while not done loop.
The reason loops are easy to create is that the model has no global view of its own trajectory. On each turn it sees the accumulated state and picks the locally best next action. Nothing in that local decision guarantees the sequence as a whole converges. A model that retries a failing call thinks each retry is reasonable in isolation, and a model that ping-pongs between two tools thinks each switch is progress. The pathology lives in the sequence, not in any single step, which is precisely why the model itself cannot reliably break out.
The interesting part of this question is therefore not listing safeguards. It is reasoning about why each safeguard, taken alone, leaves a gap. A senior answer treats the safeguards as a layered system where each layer covers the blind spot of the others, and it names the budgets and observability that make the whole thing operable.
The two conditions that produce a loop
The first condition is same-tool repetition. The model issues the same tool call with identical or near-identical arguments, the tool returns the same error or unhelpful payload every time, and the model lacks the self-awareness to recognise it is stuck. A classic trigger is a tool error the model misreads. It assumes a transient failure, retries, gets the same error, and retries again indefinitely. Another trigger is an empty but valid result. A search that returns zero rows is not an error, so the model keeps rephrasing the query, convinced the next phrasing will work, when the real problem is that the data simply is not there.
The second condition is a no-progress cycle, also called oscillation. Here the model does not repeat one call. Instead it cycles across a small set of states. It calls tool A, observes result X, calls tool B, observes result Y, then calls tool A again, and the trajectory orbits without ever converging on a final answer. Each tool's output nudges the model toward the other tool, so the cycle is self-sustaining. The action log looks varied and healthy, which is what makes oscillation so much harder to spot than a flat repeat.
The distinction matters because the two conditions defeat different detectors. Repetition is caught by checking whether this turn equals the last turn. Oscillation slips past that check entirely, because consecutive turns genuinely differ. You need a detector that looks at a window of recent turns, not just the immediately previous one. This single observation already tells you that one safeguard cannot cover the space. The two failure shapes live in different parts of the trajectory, so they demand different machinery.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- LangGraph exposes a recursion_limit on its StateGraph that hard-stops a cyclic agent after a fixed number of super-steps, the canonical step-budget backstop in production.
- Cursor and Cline coding agents detect when the same file edit or test command repeats with no new diff and inject a message forcing a different strategy before the budget runs out.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you build a progress detector that is not fooled by observations that change but do not advance the goal?
Score progress against the goal rather than against the previous observation. Use a cheap LLM judge or a goal-specific metric, track it across a sliding window, and flag a run when the score plateaus over several turns even though raw observations differ.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Naming only a step cap and stopping there. A step cap bounds the worst case but cannot tell a productive long run from a stuck short one, so it either fires too early or wastes a full budget on a hung agent.
60 second bullets to scan on the way to the call.
Name the two distinct loop conditions: same-tool repetition and multi-state no-progress oscillation.
State the step budget and the dilemma of setting the cap too low versus too high.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.