What conditions produce an infinite agent loop and what runtime safeguards prevent one?

An agent runs in a loop: observe, reason, call a tool, read the result, repeat. The loop is supposed to stop when the model says it is done. An **infinite loop** happens when that stop never comes. There are two main ways it goes wrong. First, the model calls the same tool the same way over and over. The tool keeps returning the same error, but the model cannot tell it is stuck, so it tries again forever. Second, the model bounces between a few actions, like calling tool A, then tool B, then A again, never settling on a final answer. You stop this with safeguards. The simplest is a step budget: after some number of turns, force the loop to end. But that alone is crude. Pick a small number and you cut off hard tasks that legitimately need many steps. Pick a big number and a stuck agent burns the whole budget before stopping. So real systems add more. One safeguard spots when the exact same tool call repeats. Another checks whether each turn actually moves the task forward. Each catches a different failure, and none catches all of them. The lesson is that no single guard is enough. You layer the step cap, repeat detection, progress checks, and a cost or time budget so they cover each other's blind spots.

Two conditions produce an **infinite agent loop**. The first is same-tool repetition. The model calls one tool with identical arguments, gets the same error or unhelpful result every time, and cannot recognise it is stuck. The second is a no-progress cycle. The model oscillates between two or more actions, never emitting a final answer. Three runtime safeguards address these, and each is insufficient alone. A step budget caps iterations at some count. It is insufficient because the cap fires before a legitimately long task finishes, or it lets a stuck agent waste the whole budget first. Unique-call deduplication detects and breaks exact repeated tool invocations. It is insufficient because the model can change one argument slightly while staying semantically stuck, so the calls look distinct. Progress detection requires each observation to differ from the last. It is insufficient because observations can change while the task makes no real advance toward the goal. The key insight is layering. Each guard is blind to one failure mode. You stack the step cap, call dedup, progress checks, plus a cost and wall-clock budget, so they cover each other's gaps.