A step budget, repeated-call detection, and no-progress detection genuinely stop runaway loops; bigger context windows and faster models do not.
Imagine a robot vacuum stuck in a corner, bumping the same wall over and over. How do you stop it from doing that forever? You could give it a timer that switches it off after a set number of bumps. You could notice it keeps hitting the exact same spot and force it to turn somewhere new. Or you could check whether the room is actually getting cleaner, and stop it if nothing is changing. Those three tricks each catch a stuck robot. What does not help is buying a robot with a bigger memory, or a faster motor. A bigger memory just lets it remember more bumps. A faster motor just lets it bump the wall quicker. Neither one notices that it is stuck. Agent loops are the same: you need a real stopping rule, not just more room or more speed.
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 agent is an LLM placed inside a loop with tool access. Each turn the model reads the running state, decides on an action, the runtime executes a tool, and the result is fed back. That cycle is powerful precisely because it is open-ended: the agent keeps going until it decides the task is done. The same open-endedness is the danger. If no exit condition ever fires, the loop runs forever, burning tokens and money with nothing to show for it.
This question asks you to separate genuine safeguards from plausible-sounding distractors. The discriminating idea is simple but easy to miss under interview pressure. A real safeguard must either detect that the agent has stopped making progress, or enforce a hard limit on how long it may run. Anything that merely changes how much history the loop can hold, or how fast each turn executes, leaves the loop's termination behaviour completely untouched.
That distinction is what the question is testing. Two of the five options sound relevant to long agent runs and so feel like safeguards, but they operate on the wrong axis. The sections below first explain why agents get stuck, then walk through each of the three real controls, then take the two distractors apart one at a time, and finally show how a production system layers everything together with observability on top.
Why agents loop in the first place
The canonical infinite loop is the stuck retry. An agent calls a tool, the call fails or returns an error, and the model misreads that error as a transient problem. So it issues the identical call again. The error repeats, the model misreads it again, and the cycle continues until something external stops it. The model has no memory across turns beyond what is in the transcript, and a short error string often does not carry enough signal for it to conclude that retrying is hopeless.
A second pattern is the no-progress oscillation. The agent alternates between two states without converging, for example searching, reading a result, deciding it is insufficient, and searching again with a near-identical query. Each turn looks productive in isolation, but the task never advances. This pattern is especially common when the underlying task is actually impossible with the available tools, so no amount of reasoning will produce the missing information.
A third, subtler pattern emerges in multi-agent systems. Two agents hand control back and forth, each deferring to the other, and neither ever commits to a final answer. All three patterns share one property: the loop has no internal sense that it is wasting effort, so the safeguard has to supply that sense from outside. The three correct answers map almost one to one onto these failure shapes, which is the clean way to remember them under pressure.
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 graph runtime that raises an error after a fixed number of node executions, the framework-level version of a step budget.
- Claude Code and Cursor cap agent turns per task and surface a stop prompt, preventing a misfiring edit-test loop from running unbounded.
What an interviewer would ask next. Try answering before peeking at the approach.
QExact-match call deduplication misses an agent that varies its arguments slightly each turn. How would you catch that case?
Move from exact hashing to a semantic signal: embed the action plus observation and flag low movement across recent turns, or track whether a task-level metric improved, terminating when progress stalls below a threshold over a sliding window.
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.
Picking the bigger context window or the faster model. Both change how much or how fast the loop runs, but neither detects that the agent has stopped making progress, so neither prevents the loop.
60 second bullets to scan on the way to the call.
Explain why a step budget always terminates a loop but is a blunt instrument.
Describe how repeated-call deduplication hashes a tool call to detect a cycle.
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.