Diagnosing Repetition and Loop Issues in AI Agents

An AI agent that loops on the same action, repeats a phrase indefinitely, or seems to forget it already failed at something and tries it again isn't behaving randomly. There are three genuinely different mechanisms that produce this, and they call for different fixes. Conflating them is the most common reason a fix doesn't actually work.

Three Different Mechanisms, Not One Bug

Context Loss

This connects directly to how a context window works: the model can only consider a limited amount of the conversation at once, and anything outside that window is effectively invisible to it. In a multi-step agentic task, "I tried X and it failed" is itself just text sitting in that window, and it's subject to the same aging-out behavior as any other detail in a long conversation. Once that record drops out, the agent has no way to know X was already attempted, so it tries X again. The fix here follows the same logic: keep tasks shorter where possible, summarize progress before continuing, or size the context window to what the task actually needs rather than running at its default.

Decoding-Level Repetition: A Different Mechanism Entirely

This one has nothing to do with context length. Text generation is autoregressive: each token is generated conditioned on everything generated so far, including the model's own prior output. Once a phrase repeats even once, the token sequence containing that repetition becomes part of the input for predicting what comes next, and the model's learned patterns make continuing the repetition more probable than breaking from it. Research on this describes it as a self-reinforcing "attractor": the conditional probability of the repeated token increases each time it recurs, which is why these loops tend to be stable rather than self-correcting once they start.

This shows up as an agent generating the same sentence, the same tool call, or the same explanation over and over within a single response, not across a whole conversation. It's most common with more deterministic decoding settings (low temperature, greedy decoding), and reasoning models are particularly susceptible to a variant of this called circular reasoning, where the model's own chain-of-thought gets caught in a repeating logical loop rather than a repeating phrase. This is directly relevant to DeepSeek's R1 models when running in thinking mode, covered in our model sizes article.

The practical fixes work at the decoding level, not the context level: repetition penalties and frequency penalties (available in most Ollama-served models' settings) explicitly reduce the probability of tokens that have already appeared, and slightly raising temperature can help the model escape a loop it's already fallen into, though aggressive settings on either can degrade output quality if pushed too far.

Orchestration Failure: A Design Problem, Not a Model Problem

The model itself can be behaving perfectly and an agent can still get stuck, if the layer coordinating its actions doesn't handle failure the way you'd expect. This isn't hypothetical; each of the major orchestration tools handles this differently, and the exact behavior is worth checking against current documentation rather than assumed, since these safeguards are actively being refined over time.

n8n's AI Agent node has a configurable Max Iterations limit to stop runaway tool-call loops, defaulting to 10. Separately, individual nodes have a Retry On Fail option for handling failed API calls, but it's off by default and, once enabled, uses a Max Tries value you set yourself rather than a fixed number applied automatically. The gap here isn't the absence of a limit, it's that hitting one doesn't always behave as expected: a documented bug in n8n showed a node configured with "Continue (using error output)" could route a caught error through the workflow's Success output instead of its Error output, meaning the workflow wouldn't register that anything had actually gone wrong. That specific issue has since been fixed, but it's a good reminder to test your error path directly rather than assume a configured limit is being enforced the way you expect.

OpenClaw has a dedicated tool-loop detection system that watches the rolling tool-call history for repeated patterns and can block a model that keeps calling the same tool without making progress. The catch is that the main detector is disabled by default; only a narrower post-compaction guard, which catches a model repeating the exact same tool call, arguments, and result immediately after a context compaction, is active out of the box. Getting the fuller protection means turning on the main detector explicitly and setting your own thresholds for what counts as a warning versus a hard block, rather than relying on something that's already active from install.

Paperclip takes a different approach entirely: agents run on a scheduled "heartbeat" rather than continuously, which limits how often a runaway loop can actually fire even if one starts. Paperclip's retry handling for failed runs is an area of active, ongoing development, with different transient failure types (provider capacity limits, quota exhaustion, and similar errors) handled through their own specific retry logic rather than one universal policy, so whether a given failure gets automatically retried can depend on exactly what kind of failure it was. If a run seems to fail without retrying when you'd expect it to, that's worth checking against the project's current documentation or issue tracker rather than assuming a single fixed behavior.

The common thread across all three is that a loop rarely comes from the model refusing to stop on its own. It comes from a gap in how the surrounding system defines "stop," and closing that gap usually means checking what's actually enabled by default, since a real safeguard that's off out of the box is easy to mistake for one that's already protecting you.

Working Out Which One You're Actually Dealing With

• If the repetition happens within a single response, it's almost certainly decoding-level. Check repetition penalty and temperature settings first.
• If the agent repeats a failed action across multiple steps or after a long conversation, it's more likely context loss. Check how long the task has run and whether the context window is large enough for it.
• If the agent keeps retrying the same tool call with the exact same result every time, that's an orchestration failure. Check the agent's retry and error-handling configuration rather than the model itself.

Summary

"Getting stuck" or repeating itself isn't a single failure mode with a single fix. Context loss, where a prior failed attempt has aged out of the context window, is genuinely the same underlying issue covered in our context window article. Decoding-level repetition is a separate, well-documented property of how autoregressive models generate text at all, and it responds to different fixes, like repetition penalties, not context management. Orchestration failure is different again: a design gap in how an agent's steps are coordinated, unrelated to the model's behavior, and often a matter of a safeguard existing but not being enabled by default. Diagnosing which one you're actually looking at, based on whether the repetition happens within one response, across a long task, or on the exact same failed action, determines which fix is actually worth trying.