# Stuck in the Loop: Why AI Agents Retry, Oscillate, and Never Finish > Source: > Published: 2026-07-16 12:44:11+00:00 An agent moving through a multi-step task needs two things it doesn't automatically have: a reliable way to know when the task is actually finished, and a reliable way to recognize when its current approach isn't working. Without both, the agent has no internal alarm bell. It just keeps acting — and if the same action keeps producing the same unhelpful result, nothing tells it to stop, change course, or ask for help. This isn't a minor implementation detail. It's a structural gap in how most agent loops are built: observe, decide, act, observe again. That loop has no natural exit condition unless one is explicitly designed in. The retry loop is the simpler of the two failure modes. The agent takes an action, it fails, and the agent tries the exact same action again — sometimes with trivial variation — expecting a different outcome. A few reasons this happens: **Misread failures**: The agent doesn't correctly interpret why the action failed, so it can't adjust its approach. It just repeats the attempt. **No failure memory**: Without a persistent record of "I already tried this and it didn't work," the agent has nothing to check against before trying again. **Overconfidence in the plan**: If the agent's internal reasoning treats the original plan as correct, it may conclude the execution was the problem, not the plan — and simply re-execute. The result is a kind of insanity loop: identical input, identical output, repeated until a turn limit, budget cap, or timeout finally intervenes from the outside. Oscillation is subtler and, in some ways, more dangerous, because it can look like activity rather than failure. The agent doesn't repeat the same action — it alternates between two (or more) states, undoing its own progress each cycle. **A classic example**: An agent editing a file makes a change, then in a later step "fixes" that change back to something close to the original, believing it's correcting an error. The next cycle, it reintroduces the original change again. Neither state is stable; the agent just orbits between them. This tends to emerge from: **No persistent sense of completed work**: If the agent re-evaluates the current state from scratch each turn, without a clear memory of why it made a prior change, it may re-judge that earlier change as wrong and reverse it. **Conflicting objectives**: If two instructions or two parts of the task pull in opposite directions, satisfying one requires violating the other, and the agent can flip back and forth trying to satisfy both. **Noisy or inconsistent tool feedback**: If a test, linter, or validation step gives slightly different signals from one run to the next, the agent may interpret this as "my last change made things worse," triggering a reversal that wasn't actually warranted. A retry loop is easy to spot — the exact same action shows up over and over in the log. Oscillation is harder to catch programmatically because no single action repeats; it's the pattern across actions that's the problem. Naive check like "did the agent just do the same thing twice" won't catch it. You need to track state over a longer window and recognize when the system is cycling rather than progressing. A few practices address these patterns directly, rather than relying on a blunt turn limit to eventually cut the agent off: **Explicit progress tracking**: Give the agent (or the surrounding harness) a persistent record of what's been tried and what the outcome was, so a repeated action is recognizable as repeated. **State hashing or diffing**: For tasks like file edits, comparing the current state to recent past states can flag oscillation — if the agent is heading back toward a state it was just in, that's a signal worth surfacing. **Distinct failure handling**: Treat "the action failed" as a trigger for a different strategy, not a retry of the same one. This can be as simple as requiring the agent to state what it will do differently before trying again. **Bounded retries with escalation**: Cap how many times a given action can be attempted, and route to a fallback — asking for human input, trying an alternative tool, or giving up gracefully — once the cap is hit. **Stability checks before finishing**: Before declaring a task done, verify the result reflects a stable state rather than one snapshot in an ongoing oscillation. Both retry loops and oscillation come from the same root gap: an agent acting without a reliable model of its own history. A human doing the same task naturally remembers what they already tried and gets frustrated enough to change strategy. An agent doesn't have that unless it's built in deliberately. Fixing looping behavior isn't about making the model smarter in the moment — it's about giving the surrounding system enough memory and self-awareness to recognize when it's going in circles.