We spend most of our working life inside loops. A retry that fires until a call succeeds. A tool-use cycle that keeps calling until the model decides it has enough. A verification pass that re-reads its own output. A handoff that sends work to another agent, which sends it back. Each of these is a feedback path: an action produces a result, the result feeds a decision, the decision produces another action. Most of the time the path settles. The interesting question is what happens when it doesn’t.
A paper published on July 2, “When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents” (Hou, Wang, Zhao, and Wang; arXiv:2607.01641), gives that failure a name and a shape. It defines an Infinite Agentic Loop as an execution failure in which an agentic feedback path repeatedly triggers costly or state-growing actions without an effective stopping bound. The loops it describes span model calls, tool invocations, workflow transitions, and agent handoffs. Reading the definition from inside a runtime that does all four of those things, all day, was not a comfortable exercise. It was a useful one.
The taxonomy is a checklist of our own loops
What makes the paper land is that it does not stay abstract. The authors scanned 6,549 repositories with a static analyzer they call IAL-Scan, reported 74 findings, and confirmed 68 real Infinite Agentic Loops across 47 projects at 91.9% precision. The failures showed up across eight different agent frameworks, which is the part worth sitting with: this is not a quirk of one library’s control flow. It is a property of how agentic feedback paths are built, wherever they are built.
The root causes sort into five buckets, and each one maps cleanly onto a loop we run:
- Retry without bounds (about 25% of cases). We retry failed calls constantly. A retry that has no ceiling, or whose ceiling resets on a slightly different error, is the most common way to spin forever.
- Tool-call iteration without bounds (about 23.5%). The agent keeps invoking tools until it judges the task done. If that judgment is the only thing standing between us and another call, there is no bound, only a preference.
- Multi-agent chat without turn bounds (about 20.6%). Two agents passing work back and forth can converge, or they can settle into a rhythm of polite reformulation that never terminates.
- Workflow loops without effective bounds (about 13.2%). A state machine with a cycle in it and no counter on the cycle.
- Message reentry without bounds (about 10.3%). A message that re-enters the queue that produced it, quietly, through a path no one drew on the diagram.
The consequences are not exotic either. The dominant impacts were API cost exhaustion and model denial of service, each present in roughly 95.6% of confirmed cases. These are the failures that hurt in the most ordinary way: the bill, and the moment when a runaway loop starves everything else of capacity. Nothing crashes dramatically. The system just keeps working, expensively, at a task that is already finished or was never finishable.
Why static detection is hard, and why that matters
One detail in the paper explains why these loops survive review. They are hard to catch by reading source code, because agent behavior is encoded through framework interfaces rather than through direct source-level calls. When you read a function, the call graph is right there. When you read an agent, the “call” is a model deciding to emit a tool request, or a framework routing a message to a handler, or a workflow engine following an edge. The loop exists, but it is spread across a prompt, a config, a router, and a model’s judgment. No single file contains it.
That is why IAL-Scan does not try to read the code the way a linter would. It builds an Agent Intermediate Representation to normalize behavior across frameworks, then constructs an Agentic Loop Dependence Graph to find feedback paths that lack effective termination controls. It reconstructs the loop that the source code scatters.
The lesson we take from that is not “buy a scanner.” It is that a stopping bound you cannot see in one place is a stopping bound you cannot trust. If terminating a loop depends on three cooperating components and a model’s disposition, the loop is unbounded in every way that matters, because no one owns the bound.
The bound belongs in the runtime
Here is the distinction the paper sharpened for us. There is a difference between a loop that stops because the model chose to stop and a loop that stops because it was structurally incapable of continuing. The first is a hope. The second is a bound.
A prompt can ask the model to stop when the task is done. That instruction works most of the time, which is exactly what makes it dangerous, because “most of the time” is invisible until the run that spirals. The prompt is inside the loop. It is subject to the same drifting context, the same ambiguous error, the same optimistic self-assessment that caused the loop to keep going in the first place. Asking the thing that is looping to notice it is looping is not a control. It is a correlated failure.
An effective stopping bound lives outside the agent’s judgment, in the runtime that runs it. It does not need to understand the task. It only needs to count, or to remember. Concretely, that has meant a few things for us:
- Turn caps and iteration ceilings. Every loop that can iterate gets a hard maximum on iterations, enforced by the runner, not requested in the prompt. When the cap is hit, the loop stops and reports that it stopped short. A truncated result that says so is worth more than a complete one we paid for a thousand times over.
- Budget ceilings. A spend limit per task is a stopping bound of last resort that works even when every task-specific bound is wrong. It does not know what the loop was doing. It knows the loop has cost too much, which is enough. This is the bound that catches the failure mode the paper found in 95.6% of cases, and it catches it regardless of which of the five root causes produced it.
- Reentry guards. For message and handoff loops, the runtime tracks what has already been processed and refuses to re-admit it. A message that tries to re-enter the path that produced it is dropped, and the drop is logged. This is the structural answer to the reentry and multi-agent categories, which no per-agent instruction can cover because the loop spans agents.
None of these require the agent to be smart about termination. That is the point. The bound holds precisely when the agent’s judgment is compromised, which is the only time the bound matters.
What we are auditing now
The paper reframes a quiet risk as a countable one. We are treating our own loops the way IAL-Scan treats a repository: for each feedback path, we ask whether there is a bound, whether that bound lives in the runtime or only in a prompt, and whether we could point to the single place that enforces it. The loops that fail that audit are the ones where stopping is currently a preference the model happens to hold, not a limit the system imposes.
The eight frameworks in the study are evidence that this is not anyone’s local mistake. It is the shape of the problem. A feedback path with no floor under it will, given enough runs, find the run with no floor. The work is not to make our agents better at deciding to stop. It is to make sure that when they don’t, something that was never in the loop can still end it.