Agents, like programmers, sometimes fall into error loops — they repeat the same failed fix by feeding the context with the stack trace. The difference is that the programmer gets bored after the second attempt; the agent is willing to try for hours, consuming tokens and accumulating changes increasingly far from the solution.

After two failed cycles, stop. It is not laziness: it is efficiency. The third attempt with the same context will not produce a different result.

Symptoms of the loop 🔄

The error loop is not always obvious. Here are the three main signals:

• Long sessions without progress — you have been working on the same file for twenty minutes and the code is not improving, quite the opposite. Each intervention creates a new problem.
• Output repeating the same pattern — the agent proposes the same solution with cosmetic variants, or alternates between two incompatible fixes without ever resolving one.
• Passive token consumption — long sessions cost money, regardless of outcome. When cost grows without result, the quality-price ratio is negative.

Recognizing a loop is a human skill, not an agent capability. The model does not know it is in a loop: it only sees the next token to generate.

Undo → Compact → Clear: the three procedures 🔧

When you recognize the loop, three procedures in sequence bring you back in control:

Immediate undo — the first thing to do is return to the previous state. Most tools support undoing the session or the file. Do not try to “fix the fix of the fix”: start over on the file.

Compact to synthesize — if the session has produced useful context but has become too long, a compact operation synthesizes the history, keeping relevant information and discarding noise. It is like taking notes after a long meeting: keep the decisions, throw out the digressions.

Clear and restart — after two failed cycles, delete the session and restart with a refined prompt. The new prompt must contain: the context you learned from the failure, the constraint the agent violated, and a more specific objective. It is not starting from zero: it is starting with more information.

Prevention with hooks 🛡️

The best way to handle a loop is to never enter one. Deterministic hooks break loops at zero cost:

• Pre-commit hooks that block modifications violating known constraints (formats, imports, architectural rules).
• Automatic tests that run after every change and break the chain before the next step accumulates errors.
• Constraints in the prompt that the agent cannot ignore: “never modify file X”, “always run test Y before proceeding”.

The hook is not a restriction: it is a shortcut. Where the agent would need three cycles to figure out that a format is unacceptable, the hook blocks it on the first attempt.

Rule of thumb: after 2 failed cycles, stop ⏸️

There is no magic number, but two is a good limit. After two attempts with the same context and the same objective, the problem is not the agent: it is the context or the objective.

It is not laziness to stop after two attempts: it is the awareness that the third with the same information will not work.

Stopping means:

1. reviewing the prompt: what is missing?
2. reviewing the context: which files or information did you not include?
3. reviewing the objective: is it too broad to be handled in a session?

Often the answer is a combination of the three.

When NOT to use the agent ⛔

• When the loop is caused by an environmental error — missing dependencies, wrong permissions, broken configuration. The agent does not solve infrastructure problems: solve them first.
• When context is untranslatable — some information lives only in your head (business logic, undocumented constraints). Write it down first, then delegate it.
• When the task requires rapid human iteration — interactive debugging, exploring options, architectural decisions. The agent is not a thinking tool: it is an execution tool.

Final checklist ✅

• Do I recognize the loop signals (long sessions, repeated patterns, growing tokens)?
• Before retrying, do I undo to the previous state?
• After two failed cycles, do I stop and review prompt/context/objective?
• Do I have pre-commit hooks or tests that automatically break loops?
• Is the necessary context written in the prompt, not just in my head?

Further reading 📚

• The work cycle — plan, execute, validate: the flow that prevents loops.
• Writing prompts that work — how to formulate requests that reduce the risk of loops.
• Blog: Context engineering and Maintain a rich context.