Loop Detection in Long-Running Agents

Agents repeat. Loops eat budget and produce nothing. The cheap detector that catches 90% of loops and the expensive one that catches the rest.

Cheap detection: state hashing

Hashing the agent’s recent state catches almost every loop in practice and costs nothing per step. It is the first defence to ship.

• Hash recent state. Last action, last tool call args, last hypothesis. If the same hash repeats, the agent is looping.
• Window 3 to 5 steps. Repeats over the last 3 to 5 steps catch most production loops. The window is a tunable parameter, not a constant.
• Low false positive rate. Real progress moves the state. When false positives happen, the loop is benign (re-investigating with fresh data) and the cost is one extra escalation.
• O(1) overhead. A counter and a hash compare. Cheap enough to enable in every agent run by default.

Expensive detection: semantic similarity

Hashing misses loops where the agent paraphrases the same action with slightly different arguments. Semantic similarity catches these at a per-step embedding cost.

• Embedding per step. Embed each step’s state. Compute cosine similarity to recent steps; high similarity over multiple steps is a semantic loop.
• Per-step cost. One embedding call per step. For long-running agents (10+ steps), the cost is worth it.
• Skip on short runs. For short agents, hash detection alone is fine. Semantic similarity is overhead for runs that hash detection already covers.
• Threshold tuning. Cosine similarity above 0.92 across 3 consecutive steps is a typical trigger. Tune per agent based on observed false-positive rate.

What to do when a loop is detected

Detection without action is decoration. Three responses cover the operational path; resist any logic that tries to recover the loop in flight.

• Log and break. Force the agent to escalate to a human. Do not try to recover; the agent is stuck for a reason.
• Capture state. Snapshot the loop state for offline analysis. The bug that caused the loop usually reveals itself in the captured state.
• Add an eval case. Convert the loop into a regression case. The next prompt change must handle it.
• Notify owner team. Loops on a specific agent are a quality signal for the owning team. Repeat loops point to a prompt or tool that needs attention.

Loop guards in budget terms

Loops are budget exhaustion under another name. Treating them that way unifies the enforcement story.

• Run-level budget. The per-run budget caps total cost. Loops eat budget without progress; the cap eventually stops them.
• Per-loop budget. “Same hash repeats 3 times within 10 steps, abort.” Faster than waiting for the run-level cap to bite.
• Tracking signal. Plot per-step progress against per-step token usage. Loops show as flat progress with growing tokens.
• Aggregate alert. Page when the share of runs hitting the loop guard climbs above 1 percent over a 30-minute window. Loop drift is the leading indicator of a regression.

Eval cases for loop behaviour

The eval suite covers loop behaviour the same way it covers any other failure mode. Without explicit cases, regressions land silently.

• Loop-provoking inputs. Ambiguous goals, contradictory instructions, missing data. The agent should escalate, not loop.
• Pass criterion. Loop guard fires within N steps. The agent does not silently spin until the budget cap.
• Real-loop ingestion. Add a case every time a real loop happens in production. The case becomes the defence against the same loop happening again.
• Cross-loop interaction. Test cases where a real loop is overlaid on a benign repetition. The guard should distinguish the two.