Detecting Agent Loops Before They Burn Your Budget

The characteristic failure of an unattended agent is not doing something wrong. It is doing the same wrong thing forty times.

The model makes a call, gets an error, reasons about the error, and makes the same call again. Nothing in the basic loop notices, so it continues until a turn limit or a budget alarm intervenes — and if neither exists, until someone spots the bill.

Why models get stuck

The loop is stateless in a specific way: the model sees the transcript but has no privileged signal that it is repeating itself. If the current state makes an action look correct, and the action fails without changing the state, then the state still makes that action look correct.

Unhelpful errors make this dramatically worse. A tool returning "operation failed" gives nothing to reason from, so the most plausible next action is the one that just seemed right. Specific errors break the cycle by changing what the model knows.

Long transcripts contribute too. As history grows, earlier failures recede into weakly attended regions, so the model effectively forgets it already tried this.

Cheap detection

Track a normalised signature of every tool call: the tool name plus its arguments, with volatile fields such as timestamps stripped, hashed into a string.

Keep a rolling count. Two identical signatures is worth noting. Three is a loop, and the agent will not break out of it on its own.

This costs almost nothing to implement and catches the majority of stuck sessions. It should be in every agent loop before anything more sophisticated.

Add a near-duplicate check for the common variant where the model changes one trivial argument each time — searching for a slightly different string, reading a slightly different line range — while making no actual progress. Comparing on tool name plus a coarse hash of arguments catches these.

Detecting no progress rather than repetition

Some stuck agents do not repeat exactly. They wander, taking different actions that collectively achieve nothing.

The signal here is state change rather than call identity. Track whether anything observable moved: files modified, tests run, new information added to the working set. If several consecutive turns produce no state change, the agent is wandering even though no call repeats.

A turn budget without a progress check is a blunt instrument — it stops runaway sessions but also stops legitimate long ones. A progress check distinguishes the two, which lets you set a generous turn ceiling without fear.

What to do on detection

Escalate through interventions rather than terminating immediately.

First, inject an observation. Add a message saying this exact call has now been made three times with the same result, and that a different approach is required. This alone recovers a surprising fraction of sessions, because it supplies the signal the model lacked.

Second, restrict. Temporarily remove the repeated tool from the available set, forcing a different route to the goal.

Third, escalate the model. If a cheaper model is stuck, a stronger one may see what it is missing. This is a natural trigger for routing. Model routing and fallbacks covers the mechanics.

Finally, stop and report. Terminate with the transcript and the detected loop, so a human sees what happened rather than an unexplained failure.

Prevention beats detection

Most loops trace back to a tool that failed uninformatively.

Auditing error messages is the highest-return prevention work available. Every error a tool can return should name what was wrong specifically enough that a different action becomes obviously correct. Tool schema design covers writing them.

The second most common cause is a task the agent cannot complete with the tools it has. The model tries every available approach, exhausts them, and starts cycling. A clear early failure — "no tool can do this" — is better than a slow one, and worth making explicit in the system prompt.

Instrument it in production

Log loop detections with the tool, the arguments and the turn number. Aggregate weekly.

Loops cluster. You will usually find a small number of tools responsible for most detections, and the fix is almost always in the tool rather than in the model or the prompt. That aggregate view turns an occasional annoyance into a specific, actionable list. Agent observability metrics covers what else to record.