What is agent loop detection?

Summary slides

Why agentic systems are prone to looping in ways a single model call never is

A single model call has a natural, built-in stopping point: it produces one output and the interaction ends there, which means there’s no opportunity for the kind of indefinite repetition that concerns agent loop detection at all. An agentic system, where a model makes a sequence of decisions, invokes tools, evaluates the results, and decides what to do next, removes that natural stopping point, replacing it with a loop that continues only as long as the model itself keeps deciding to continue, which means the system has to supply its explicit boundary on that process rather than inheriting one for free the way a single call does.

This structural difference matters quite a lot in practice because an agent that’s struggling with a task doesn’t typically fail loudly or visibly, throwing an explicit error or stating outright, in so many words, that it’s stuck, it usually just keeps trying, issuing another tool call, attempting another approach, revising its prior reasoning, each individual step looking like a reasonable, plausible next action in isolation even as the overall trajectory fails to converge toward completing the task. Nothing about any single step in a looping sequence necessarily looks wrong on its own, which is exactly why detecting the loop requires looking at the trajectory across multiple steps rather than evaluating any one step in isolation, a fundamentally different kind of monitoring than what catches an outright, single-step failure.

The consequences of an undetected loop also compound in a way that a single failed call’s consequences simply never do, since each additional step in a looping sequence adds further cost, further latency, and in tool-using agents, potentially further real-world side effects from actions taken along the way, which means the cost of missing a loop isn’t fixed the way the cost of a single failed request is, it grows for as long as the loop is allowed to continue undetected and unaddressed.

How to recognize the different shapes a loop can take

Not every unproductive agentic sequence looks the same from the outside, and building effective detection requires recognizing that loops come in different shapes, each of which calls for a somewhat different detection approach rather than a single, one-size-fits-all check applied uniformly across every case.

A literal state cycle, where an agent simply returns to a state it has already, clearly visited before, issuing a tool call it’s already issued with the same or nearly identical arguments, or revisiting a line of reasoning it’s already explored and already rejected, is the most straightforward shape to detect, since it can often be caught by directly comparing a current state or action against a record of states and actions already taken earlier in the same sequence. A productive-looking drift, where an agent keeps taking different actions, never literally repeating a prior state, but the sequence as a whole isn’t converging toward the task’s actual goal, wandering through a broad space of plausible-looking but ultimately unproductive actions, is considerably harder to detect, since no individual action repeats and a naive state-comparison check would see nothing obviously wrong at any single step along the way.

A retry storm, where an agent repeatedly, persistently attempts the same fundamental action in slightly different phrasings or with slightly different parameters after each successive attempt fails or produces an unsatisfactory result, sits somewhere between the two, technically varying its actions each time in a way a literal cycle detector might miss, while still representing a failure to make progress that a broader trajectory-level check should be able to catch. Recognizing which shape a stalled sequence is taking, rather than assuming loops always look like simple, literal repetition, is what determines whether a detection system built around only the most obvious case will catch the harder, subtler cases that show up just as often in practice.

How state-based cycle detection works

The single most direct detection technique available simply tracks a representation of each state the agent passes through, whatever combination of its current reasoning, the tool calls it’s made, and the results it’s received constitutes a meaningful state for the task at hand, and checks each new state against the record of states already visited earlier in the same sequence, flagging a match as a signal that the agent has returned to somewhere it’s already been without having made progress in between.

Defining precisely what counts as a matching state is the central design challenge here, since an overly strict definition, requiring an exact match on every detail, will miss loops where the agent varies some superficial detail each time while repeating the same unproductive underlying pattern, while an overly loose definition, matching on only a coarse summary of the state, risks flagging different, productive actions as false repeats simply because they share some surface-level similarity. Getting this granularity right generally requires task-tuning rather than a universal default, since what counts as a meaningfully distinct state for a research-oriented agent gathering information looks quite different from what counts as a meaningfully distinct state for an agent executing a fixed, well-defined multi-step procedure.

Bounding precisely how far back the state comparison looks is a related design decision carrying tangible practical consequences, since comparing every new state against the agent’s entire history so far becomes increasingly expensive as a sequence grows longer, while comparing only against a small, recent window risks missing a loop whose period is longer than that window, an agent that cycles through four or five distinct states before returning to the first one, for instance, which a window sized to catch only immediate, back-to-back repetition would never detect at all.

How to detect drift when no single state literally repeats

Because drift-based unproductive sequences, by their very nature, never literally repeat any single prior state, catching them requires a different kind of signal than state comparison, one that measures whether the sequence as a whole is converging toward the task’s goal rather than merely checking whether any individual step has been seen before.

Progress estimation, explicitly assessing after each individual step how much closer the agent is to completing the task relative to where it stood some earlier number of steps back, gives a direct, principled signal for this whether through a dedicated model call specifically tasked with judging progress, a task-heuristic tied to concrete, observable milestones, or a comparison against an expected step count the task type would normally require to complete under ordinary, non-looping conditions. A sequence whose estimated progress has stalled or is oscillating, moving forward for a stretch and then quietly sliding back, without any reasoning behind that regression, over several consecutive steps is exhibiting exactly the kind of drift that a pure state-cycle check would completely miss, since nothing about any individual step in a stalled-but-varying sequence would ever literally repeat.

Diversity-without-progress is a related, complementary signal worth watching for specifically because it can look deceptively like productive exploration from a purely surface-level view: an agent trying a wide range of different approaches in succession looks active and engaged, but if none of those different approaches are converging toward the goal, the sheer diversity of what’s been attempted isn’t evidence of progress at all, it’s simply evidence that the agent is searching broadly and, so far, entirely unsuccessfully. Distinguishing productive exploration, which narrows meaningfully over time as the agent learns what does and doesn’t work, from unproductive wandering, which keeps sampling a similarly broad space of options without any narrowing at all, is exactly the distinction progress estimation is meant to capture, and it’s considerably harder to capture reliably than the more mechanical task of simply comparing states for a literal match.

How retry and error-pattern detection catches loops that state comparison misses

A quite common category of looping behavior centers directly on an agent repeatedly attempting the same fundamental action after it repeatedly fails, retrying a tool call that keeps returning an error, re-attempting a step that keeps producing an unsatisfactory result, each individual retry varying just enough in its parameters or phrasing to evade a naive exact-match state comparison while still representing exactly the same kind of stalled, unproductive pattern a cycle detector is meant to catch.

Tracking retry counts specifically against the same underlying action, rather than only against a literal, exact match, catches this pattern directly: counting how many times an agent has attempted some recognizably similar version of the same action within a bounded recent window, and flagging the sequence once that count crosses a threshold that would be unusual for the task type under normal, non-looping conditions. This requires a looser, more forgiving notion of “same action” than a literal state-cycle check does, since the whole point of this failure mode is that each individual attempt varies just enough to dodge an exact match, which means the detection logic here needs to recognize a family of closely related actions as fundamentally the same underlying attempt rather than requiring bit-for-bit identical repetition before it counts anything toward the retry total.

Error-pattern tracking specifically, closely watching not just how many times an action has been retried but exactly what kind of error or unsatisfactory result each attempt produced, adds a further useful signal, since a sequence of retries that are all failing for the exact same underlying reason is a much stronger signal of a structural problem the agent isn’t equipped to work around on its own than a sequence of retries failing for a variety of different, unrelated reasons, which might still plausibly resolve on the very next attempt. Distinguishing these two cases lets a detection system respond proportionally, letting a sequence with varied, potentially resolvable failures continue somewhat longer than one whose failures are clearly, repeatedly structural and therefore unlikely to ever resolve simply by trying yet again.

How to decide what happens once a loop is detected

Detecting a loop in the first place is only useful if the system then does something meaningful once it’s been detected, and the right response depends heavily on how confident the detection signal is and how severe the apparent loop appears to be, which is why a mature agent loop detection system generally implements a graduated response rather than a single, binary reaction that always simply terminates the agent’s sequence the instant any detection signal fires at all.

A milder, less severe detection signal, a moderate rise in retry count or a moderate stall in estimated progress, might reasonably trigger a nudge rather than an outright stop: surfacing the detected pattern explicitly back to the agent itself, prompting it to recognize its apparent lack of progress and to explicitly consider a different approach rather than continuing to repeat variations on whatever hasn’t been working so far. A stronger, considerably more confident detection signal, a clear literal state cycle or a retry count well beyond what the task type would normally require, more reasonably justifies a harder intervention: terminating the current approach outright and either falling back to a simpler, more constrained strategy, escalating to a human for review, or surfacing the partial progress made so far honestly rather than either continuing to burn further steps on a sequence that isn’t converging or fabricating a confident final answer that the actual trajectory never earned.

This graduated response connects quite directly to the graceful degradation practices relevant to AI systems more broadly, since a detected loop is itself a well-defined instance of the general problem of a model-based component underperforming without failing outright in any conventional, cleanly detectable sense, and the same layered-fallback thinking that governs graceful degradation elsewhere applies just as directly here: a system that only ever has the binary choice between letting a detected loop continue unchecked or immediately terminating it entirely is missing the same valuable middle ground that graceful degradation design is generally built around preserving.

How to set thresholds that catch loops without over-triggering on legitimate complexity

Every single detection signal discussed so far, a state-repeat count, a retry count, a progress-stall duration, needs some concrete threshold before it triggers a response, and setting that threshold well is a balancing act: too sensitive, and the system starts interrupting legitimately complex tasks that simply require more steps, more exploration, or more retries than a shorter, simpler task normally would, while too permissive, and loops run for far longer than necessary before the system ever intervenes, burning cost and real time in the meantime.

Carefully calibrating these thresholds against a system’s actual task distribution, rather than picking a number that merely feels intuitively reasonable, is what gets this balance right in practice: measuring how many steps, how many retries, and how much apparent progress-stalling successful completions of a task type typically exhibit under ordinary, non-looping conditions gives an empirical baseline to set a threshold meaningfully above, rather than guessing at a number with no connection to how the system’s tasks behave in practice. Task-type-thresholds, rather than just one single universal threshold applied uniformly across every kind of task a system handles, matter here for the same underlying reason, since a research-oriented agent that’s expected to explore broadly before converging has a different normal step-count and retry profile than a narrow, well-defined procedural agent, and holding both to the same fixed threshold guarantees the threshold will be poorly calibrated for at least one of the two, if not for both simultaneously.

Thresholds also deserve to be revisited periodically rather than set once during initial design and then left untouched indefinitely, since a system’s actual task distribution, its underlying model, and its tool integrations all continue to evolve over time, and a threshold well calibrated against last quarter’s typical task behavior can quietly drift out of calibration as this quarter’s actual behavior shifts underneath it, either triggering too aggressively on tasks that have simply grown more complex over time, or missing loops that have grown longer than the threshold was ever set to catch in the first place.

How agent loop detection interacts with cost management directly

Every single additional step in an agentic sequence carries measurable cost, in tokens spent on the model calls that drive each step and often in the tool calls the agent makes along the way, which means an undetected loop isn’t merely a quality problem, it’s directly and measurably a cost problem, and the cost of an undetected loop can scale considerably worse than the cost of an ordinary, successfully completed task, since nothing structurally bounds how long an undetected loop might otherwise be allowed to continue running.

A hard, fixed step or cost ceiling, an absolute upper bound on how many steps or how much total cost a single agentic sequence is ever allowed to consume regardless of what the more nuanced loop-detection signals discussed earlier say, serves as a last-resort backstop specifically for the case where a loop’s shape manages to evade every one of the more targeted detection signals a system has otherwise built. This ceiling deserves to sit meaningfully above what the finer-grained, shape-detection signals should normally catch well before it’s ever reached, since a hard ceiling that’s the primary or only defense against looping behavior is a considerably blunter, more wasteful instrument than the more targeted detection discussed throughout this article, but it remains valuable precisely as the backstop that catches whatever the more sophisticated, targeted detection ultimately misses.

Cost-aware detection thresholds, meaningfully tightening a system’s tolerance for apparent looping behavior specifically on higher-cost tasks and loosening it somewhat on low-cost ones, let a system apply its available detection effort where the actual financial and latency stakes of a missed loop are highest, rather than treating every task’s looping risk as equally consequential regardless of how expensive letting that particular task’s loop continue unchecked would turn out to be in practice.

How to test and monitor loop detection once it’s built

Loop detection is exactly the kind of system capability that looks entirely straightforward on paper yet is considerably harder to validate well in practice, since it’s specifically meant to activate in situations that are, by their nature, somewhat rare and hard to reliably reproduce through purely ordinary, well-behaved testing, which is why deliberately constructing scenarios that force a loop to occur deserves the same investment as adversarial testing of any other consequential system behavior.

Deliberately designed test tasks, ones specifically constructed to push an agent toward a literal state cycle, a drift pattern with no convergence, or a retry storm against a consistently failing tool, let a team directly and concretely exercise each detection signal and each response tier rather than only hoping the detection logic behaves correctly once an unplanned loop eventually shows up in production. These deliberately constructed scenarios also give a team an empirical basis for the threshold calibration discussed earlier, since a threshold tuned only against a system’s typical, well-behaved task distribution has no evidence of how well it performs against the looping cases it’s specifically meant to catch.

Ongoing, sustained production monitoring, tracking how often loop detection fires, what shape of loop it caught in each case, and how the graduated response resolved once it fired, closes the loop between design-time testing and ongoing operation, since a detection system’s thresholds and its detection signals can silently drift out of calibration as the surrounding system evolves, a new tool integration introducing a retry pattern the original thresholds never accounted for, a new task type whose normal step count and normal progress-estimation profile differ meaningfully from what the existing calibration was originally built around. Treating loop detection as an ongoing system component deserving its continued monitoring and its continued recalibration, rather than a one-time addition built once during initial launch and then left untouched indefinitely, is what keeps it working reliably as the agentic system it protects continues to grow and change over the course of its sustained operational life.

How loop detection should communicate what it caught back to the user

A detected loop that resolves entirely behind the scenes, with the user only ever seeing either a final answer or a generic failure message, discards information that would help the user understand what happened and decide how to proceed, since the difference between “the agent tried and couldn’t find enough information” and “the agent got stuck repeating the same unproductive action” points toward meaningfully different next steps a user might reasonably want to take.

Surfacing what was detected, in plain terms rather than an opaque internal error code, gives a user actionable information: that the system attempted a particular approach some number of times without success, that it noticed itself repeating a similar pattern and stopped rather than continuing indefinitely, or that it’s made partial progress but couldn’t fully complete the task within its normal operating bounds. This honest framing matters for the same underlying reason honest communication matters in graceful degradation more broadly, since a user who understands specifically what happened is far better positioned to decide whether to rephrase their request, provide additional information the agent was evidently missing, or simply accept the partial result as sufficient for their actual purposes, than a user no signal beyond an unexplained, generic failure.

This communication also has product design implications beyond the text of any single response, since a system that visibly, consistently distinguishes a loop-terminated response from a normal, successfully completed one, through a clear interface treatment or an explicit status indicator, helps a user build accurate, well-calibrated expectations over repeated use of the system, understanding when a task requires their additional input to succeed versus when the system is simply going to need another, different attempt on its own to make progress.

How loop detection differs between single-agent and multi-agent systems

Everything discussed so far assumes a single agent working through a sequence of steps on its own, but multi-agent systems, where several agents coordinate, delegate subtasks to each other, or exchange information as part of completing a larger overall task, introduce a distinct failure mode: a loop that spans multiple agents rather than existing within any single one of them, where no individual agent’s local sequence looks obviously unproductive in isolation even as the overall multi-agent interaction as a whole fails to converge.

Two agents can end up in a mutual back-and-forth, each one responding reasonably to what the other just said or did, with neither agent’s individual behavior looking like a loop from its local perspective, while the interaction between them never makes progress toward the shared task, a pattern that’s structurally invisible to any detection logic scoped only to a single agent’s internal state and its internal history. Catching this requires detection scoped explicitly to the overall interaction between agents rather than to any single agent’s sequence in isolation, tracking the same kinds of signals discussed throughout this article, state repetition, stalled progress, retry patterns, but applied at the level of the full multi-agent exchange rather than within any one participant’s private, local view of what’s happening.

Coordination-failure patterns also deserve their dedicated attention in multi-agent systems beyond what single-agent loop detection would naturally catch, a delegation cycle where one agent repeatedly hands a subtask back to another agent that then hands it right back again, or a consensus failure where several agents keep revising their individual outputs in response to each other’s revisions without ever settling on a final, shared position. Designing detection that spans the full multi-agent interaction, rather than assuming that detection built for a single agent will automatically generalize to catch these different, inter-agent failure patterns, is what closes this increasingly relevant gap as multi-agent architectures become more common in production systems.

Common mistakes teams make with agent loop detection

A first mistake, and the foundational one nearly every other mistake on this list traces back to in some form, is building an agentic system with no explicit loop detection at all, relying entirely on the model’s internal judgment to recognize when it’s stuck, when a model rarely signals its unproductive repetition clearly, honestly, or reliably enough to be trusted as the sole safeguard against it.

A second mistake is relying only on literal state-cycle detection, catching exact, verbatim repeats while completely missing the considerably subtler drift patterns where an agent keeps taking different actions in succession without ever converging toward the task’s underlying goal at all.

A third mistake is defining state matching far too strictly, requiring an exact, literal match that misses loops where an agent deliberately or incidentally varies some superficial detail each time while repeatedly cycling through the same unproductive underlying pattern underneath that shallow surface variation.

A fourth mistake, the opposite failure of the third but equally damaging in its way, is defining state matching far too loosely, flagging different productive actions as false repeats simply because they happen to share some coarse, surface-level similarity with an earlier, entirely unrelated step in the sequence.

A fifth mistake is bounding the state-comparison window far too narrowly, catching only immediate, back-to-back repetition while entirely missing a longer-period cycle that only returns to an earlier state after several distinct intermediate steps in between, well outside whatever narrow window the comparison was checking against.

A sixth mistake is tracking retries only by an exact, literal match rather than by the considerably looser notion of the same underlying attempted action discussed earlier, letting an agent effectively evade retry-count detection simply by varying its phrasing or its parameters slightly on each successive attempt, however unproductive those attempts remain underneath.

A seventh mistake is treating every single detected loop identically with a single, rigid, binary response, either always letting a detected loop continue entirely unchecked or always terminating it outright the instant any signal fires, rather than implementing the graduated response that a range of detection confidence levels calls for in practice.

An eighth mistake is setting detection thresholds based on little more than intuition rather than on the system’s actual, empirically measured task distribution, leaving those thresholds either too sensitive for legitimately complex tasks that simply need more room, or too permissive to catch loops in anything close to good time.

A ninth mistake is applying one single, universal threshold uniformly across different task types, holding a broad, exploratory agent and a narrow, well-defined procedural agent to exactly the same normal-step-count expectations, despite their fundamentally, meaningfully different normal behavior profiles under ordinary, non-looping conditions.

A tenth mistake is treating a hard step or cost ceiling as the primary, main defense against looping behavior rather than as the last-resort backstop it’s best suited to serve as, missing the considerably more targeted, considerably more cost-efficient intervention that shape-detection signals could otherwise have provided much earlier, well before the sequence ever reached that blunt, final ceiling.

An eleventh mistake is applying exactly the same detection sensitivity uniformly regardless of a task’s actual cost profile, treating a cheap, low-stakes task and a considerably more expensive, high-stakes one as though they were equally consequential whenever a loop goes undetected in either case.

A twelfth mistake is only ever testing loop detection against a system’s typical, well-behaved task distribution, never deliberately constructing the adversarial scenarios needed to exercise and validate each detection signal and each response tier before an entirely unplanned loop eventually shows up, expensively, in live production.

A thirteenth mistake is resolving a detected loop entirely behind the scenes with no honest, meaningful communication back to the actual user about what happened, leaving them with either a generic, unexplained failure or an unexplained partial result rather than the actionable information that would help them decide how best to proceed from there.

A fourteenth and truly final mistake is simply assuming that loop detection built and tuned for a single agent automatically generalizes to multi-agent systems, missing the distinct failure patterns, mutual back-and-forth exchanges, delegation cycles, unresolved consensus loops, that remain structurally invisible to any detection scoped only to a single agent’s local, internal history and its private view of the interaction.

What connects all fourteen of these mistakes is treating agentic looping as an unusual, edge-case failure that will rarely occur and therefore doesn’t warrant dedicated, deliberate design attention, rather than as a structural, near-inevitable consequence of removing the natural stopping point a single model call has always had for free. Systems that build shape-aware detection, calibrate their thresholds against empirical task data, and respond to a detected loop with graduated, proportionate intervention tend to keep agentic behavior bounded, predictable, and cost-proportionate even as the tasks they handle grow more complex and more open-ended, while systems that skip this deliberate design tend to discover the gap only once an undetected loop has already run considerably longer, and considerably more expensively, than anyone intended it to, often in front of a paying user whose patience for an unresolving, repetitive sequence was never part of anyone’s original design assumptions in the first place.

The deeper principle underlying all of this is that autonomy without a bound is not a feature, it’s an unmanaged risk wearing the appearance of flexibility, and the value an agentic system offers, handling open-ended tasks without requiring a human to script out every step in advance, only holds up in practice when it’s paired with an equally deliberate, equally well-designed mechanism for recognizing the moment that open-endedness has quietly stopped producing anything useful at all. A system that can act autonomously but can’t recognize its unproductive repetition isn’t more capable than one with tighter, more scripted bounds, it’s simply less predictable about exactly when and how it will eventually fail, trading a visible, well-understood limitation for an invisible one that only surfaces once it’s already become expensive, and sometimes only once a user has already noticed the problem themselves, at which point the trust that autonomy was originally meant to earn has already, quietly, been spent instead.

Teams that build loop detection as a first-class part of their agentic architecture, rather than as an afterthought added only once a costly incident has already made the gap impossible to ignore, tend to get to keep the benefits open-ended agentic behavior offers without absorbing the largely avoidable cost of runaway, undetected sequences that were never converging on anything useful in the first place, and without ever having to explain to a user, after the fact, why the system kept trying something that was never going to work no matter how many additional attempts it was quietly allowed to take.