Loop Detection — Patterns

Define progress for the workload

Problem. Generic detectors ask whether anything changed, which is the wrong question. A research agent reading its twelfth document has changed nothing externally and is making excellent progress; a scheduling agent that has rewritten the same draft four times has changed plenty and made none.

Approach. Require each workload to supply a progress predicate evaluated after every iteration — items completed, new entities discovered, a distance to the success criterion. Treat several consecutive iterations with a false predicate as the signal, rather than any generic notion of similarity.

Trade-off. Every workload now owns a predicate, and a badly written one is worse than none: too lenient and nothing fires, too strict and legitimate deliberation is cut off. Predicates also need their own tests, which teams rarely build for a defensive mechanism.

Fingerprint the intent, not the text

Problem. Exact comparison of calls is defeated by anything that varies: a timestamp in a query, a reordered argument map, a rephrased search string. The agent cycles while every signature looks new.

Approach. Build the fingerprint from normalised intent — tool name plus canonicalised arguments with volatile fields removed, keys sorted, values lowercased and whitespace collapsed, and near-identical free-text arguments bucketed. Count fingerprints across the run rather than comparing adjacent turns.

Trade-off. Normalisation decides what counts as the same action, and an over-aggressive rule flags a legitimate sequence of similar queries over different entities. The exclusion list for volatile fields is per tool and will be incomplete.

Keep a visited set, not just a last value

Problem. Comparing each turn with the previous one cannot see alternation. An agent switching between two approaches differs from its predecessor every single turn and never triggers an adjacent-repeat check, while making no progress at all.

Approach. Maintain a set of visited states for the run, keyed by a canonical representation of position — the fingerprint plus the relevant state digest — and flag a revisit rather than a repeat. Count distinct revisits and the cycle length, because a period-two cycle and a wandering return are different problems.

Trade-off. Canonicalising a state well enough for set membership is genuinely hard, and too coarse a key flags legitimate returns to a prior step, which some workflows do on purpose. Memory grows with run length, though in practice far more slowly than the context does.

Change strategy first, escalate on recurrence

Problem. Ending a run the moment a cycle is suspected discards work that a nudge would have rescued; injecting a warning and continuing lets a genuinely stuck agent cycle in a slightly different way for another twenty turns.

Approach. Make the first response a substantive change rather than a warning: remove the failing tool from the available set, supply the accumulated failure evidence in structured form, or hand the step to a different approach. If a cycle is detected again after that intervention, stop and escalate with a distinct reason rather than intervening a second time.

Trade-off. Removing a tool mid-run can make the task impossible to complete and produce a confused final answer rather than an honest failure. A strict one-intervention rule also ends runs that a second nudge would genuinely have saved.