Which runtime safeguards prevent an agent from looping indefinitely?

An agent runs a loop: it reasons, calls a tool, reads the result, and repeats. An **infinite loop** happens when that cycle never reaches a stopping point. The classic case is an agent that keeps calling the same failing tool, misreading the error each time, and trying again forever. Three safeguards genuinely stop this. A step budget caps the number of iterations, so the loop dies after, say, thirty turns no matter what. Repeated-call detection notices when the agent fires the identical tool call twice and breaks the cycle. Progress detection checks whether each step actually produced something new, and halts when nothing changes. Two tempting options do not help. A bigger context window only lets more loop history fit before the prompt overflows. It does not notice that the agent is stuck. A faster model only makes each turn quicker, so the loop spins faster and burns money faster. The lesson is simple. To stop a loop you need a rule that detects stuckness or enforces a hard limit. Buying more room or more speed changes the size of the problem, not whether the loop ever ends.

An agent loop spins forever when no exit condition fires. The three correct safeguards each attack that directly. A **step budget** is a hard cap on iterations. After a fixed maximum, the runtime kills the loop regardless of state. Repeated-call deduplication hashes each tool call's name plus arguments and breaks the cycle when an identical call repeats. Progress detection requires each step to yield a new observation, and halts when successive states are unchanged. The first is a blunt ceiling. The other two detect the specific pathology of a stuck agent. The two distractors are tempting but wrong. A larger context window only changes how much history fits before truncation. A loop with a bigger window simply runs more iterations before overflowing. It never notices it is stuck. A faster model only reduces per-step latency. The loop still has no exit condition. It just reaches infinity sooner and cheaper per call, which often means a higher total bill. Both distractors change the cost or capacity of the loop without adding any termination logic, so neither prevents the runaway.