Loop Detection

What it is

Recognising that an agent is iterating without advancing — reissuing the same call with the same arguments, alternating between two states, re-deriving a conclusion it already reached, or spending turns on self-correction that changes nothing material — and acting on that recognition before the allowance is gone. It is a judgement about progress, which is why comparing consecutive turns for equality catches only the most obvious case.

Why it matters

Non-progressing iteration is the most expensive agent failure because it looks exactly like work. A ceiling on iterations bounds the damage but not the waste: a run that reaches turn forty having reissued the same failing call thirty-five times costs the same as one that did forty useful turns, and the user waited for both. Detection converts a slow, invisible burn into an early, classified failure that something else can act on, and it makes the underlying defect visible in aggregate instead of hidden inside a completion rate.

Diagnosing is not stopping

Noticing that iteration has stopped producing progress is an observation; deciding that a run is over is a rule. The two are usually wired together — the observation triggers the rule — but they fail independently. A run can be ending correctly and promptly while spinning fruitlessly for most of its turns, and a run can cycle for a long time entirely within a correct stopping rule that simply has not been reached yet.

Key decisions

• What counts as progress for this workload: new information acquired, state changed, a work item completed, or measurable movement toward a success criterion.
• The signal used: an exact call signature, similarity between recent turns, absence of change in the shared record, or an explicit progress metric the task defines.
• The window — how many non-advancing turns constitute a cycle — and whether the threshold differs by task type, since a research task legitimately looks idle longer than a lookup.
• The response: inject a correction, force a different approach, escalate to a person, or end the run.
• Whether the check runs inside the iteration, where it must be cheap, or out of band, where it can be expensive but acts later.
• The acceptable false-positive rate, given that a legitimate retry after a transient fault is indistinguishable from a cycle at the second occurrence.

Failure modes

• Detection compares exact strings, so an agent that appends a changing timestamp or rephrases the same query escapes it entirely and cycles under a slightly different signature each time.
• A warning is injected into the context, the agent apologises and repeats the same action, and now every subsequent turn carries an apology as well.
• Thresholds calibrated on a fast workload fire constantly on a legitimately slow one, and the team switches detection off rather than calibrating per workload.
• Cycles that span participants are missed because each check is local: the first agent asks the second, the second asks the first, and neither repeats itself.
• The cycle is in the dependency rather than the agent — a paginated interface returns the same cursor indefinitely and the agent faithfully follows it.
• Detection fires and ends the run, but the outcome is recorded as a normal completion, so the cycle never appears in any metric and the underlying cause is never fixed.
• Oscillation with a period of two goes unnoticed because every turn differs from the one immediately before it.
• The detector itself uses a model call per turn and costs more than the waste it prevents.

Related capabilities

• Execution Loop — the iterations being examined for progress
• Termination Conditions — the rules a detection fires into
• Planning Engine — revision cycles are a common source of oscillation
• Shared State Management — absence of change here is a strong progress signal
• Multi-agent Orchestration — where cycles span several participants

Applies: Production readiness · Design questions