How to fix: agent stuck in a loop / repeating the same tool call
Last verified: June 2026· AI agents
Where this shows up
AI agents
How it shows up
The same root cause surfaces in a few different ways. If any of these match, you're in the right place.
- The same tool is called repeatedly with identical or near-identical arguments.
- The agent alternates between two actions indefinitely, undoing its own work each time.
- Token spend climbs steadily while no new information enters the conversation.
- The agent reports progress in prose while its tool calls show nothing changing.
- The run only ends when it hits a budget or timeout, never because the task completed.
Diagnose it first
Confirm which cause you actually have before changing anything — most wasted time here comes from fixing the wrong one.
| Check | What the result tells you |
|---|---|
| Read a full trace of the loop, including every tool result. | The repeated element identifies the loop type: identical arguments mean the agent is not seeing the result; changing arguments mean it is searching without a stopping condition. |
| Check what the failing tool actually returns to the model. | A bare false, null, or empty string gives the agent no basis to change approach, so it reasonably retries the same call. |
| Verify tool results are appended to the conversation the model sees. | If results are logged but never fed back, the agent is genuinely blind to its own actions and repetition is the correct behaviour given its inputs. |
| Confirm the success condition is expressible with the tools available. | An agent asked to reach a state it has no tool to reach or verify cannot terminate, no matter how good the prompt is. |
| Check whether early turns are being truncated as context fills. | If the original instruction ages out of the window, the agent loses the goal and re-derives its task from recent turns — which produces circling. |
The fix
- 1Return informative tool errors (not just failures) so the agent can adjust rather than retry blindly.
- 2Add a max-iteration or token budget so a stuck agent stops instead of burning cost.
- 3Check that tool results actually feed back into the loop and that state isn’t being lost between turns.
- 4Give the agent a way to escalate to a human when it can’t make progress.
- 5Inspect a trace of the loop to see what it’s reacting to — this is where agent observability pays off.
Provider-specific behaviour
The error means roughly the same thing everywhere, but each provider signals it differently.
- Tool error design
- Errors returned to an agent are prompts, not log lines. "File not found: /app/cfg.yml. Nearby: /app/config.yml" lets the agent correct itself; "Error: ENOENT" gives it nothing to act on and effectively invites a retry.
- Iteration budgets
- A maximum turn count is a backstop against unbounded spend, not a fix. It should be paired with a distinct terminal state so a stopped agent reports that it could not finish, rather than appearing to have completed successfully.
- Context window pressure
- As a long agent run approaches the context limit, early instructions are the first thing dropped by naive truncation. Summarising completed work while preserving the original goal verbatim keeps the objective in view.
- Idempotency
- Agents retry. Tools with side effects that are not idempotent turn a harmless reasoning loop into duplicated writes, repeated emails, or double charges — the loop becomes an incident rather than a cost problem.
What doesn't work
Common fixes for this error that look right and aren't.
Lowering max iterations to stop the loop.
This caps the symptom and hides the cause. The agent still fails to complete the task, but now fails faster and without the trace length needed to work out why.
Telling the agent "do not repeat yourself" in the system prompt.
The agent is not repeating deliberately — it is responding to inputs that never change. Adding an instruction does not give it the new information it needs to choose differently.
Switching to a larger model.
If the loop is caused by a tool swallowing errors or results not being fed back, a stronger model reasons more capably over exactly the same missing information and loops just as reliably, at higher cost.
Prevent it
Build observability and budgets into your agent harness so loops are visible, bounded, and debuggable.
Common variations and related errors
You'll usually hit this same root cause under a few different names. Same fix.
- "agent looped"
- "infinite tool calls"
- "repeating same tool call"
- "agent didn
Frequently asked questions
What causes “agent stuck in a loop / repeating the same tool call”?
The agent isn’t making progress — often a tool keeps failing the same way, or it lacks the context/feedback to change approach.
How do I prevent “agent stuck in a loop / repeating the same tool call” from recurring?
Build observability and budgets into your agent harness so loops are visible, bounded, and debuggable.
How do I stop an agent from repeating the same failed tool call?
Make the failure informative. The agent repeats because each attempt looks identical from its perspective, so nothing suggests a different approach. Return what failed, why, and where possible a hint at the correct input — a not-found error that lists near-matches lets the agent self-correct on the next turn. Detecting an exact repeat and injecting an explicit note that this call already failed is a useful safety net on top.
What is a sensible iteration limit for an agent?
Set it from observed behaviour on tasks that succeed. Measure the turn count distribution for successful runs and set the ceiling above the tail, so the limit only ever catches genuinely stuck runs. A limit that also truncates legitimate long tasks produces silent partial failures, which are considerably worse to debug than an obvious loop.
Should the agent be able to give up?
Yes, and it should be an explicit, first-class outcome. An agent with no way to declare that it is stuck will keep trying, because continuing is the only action available to it. Giving it a way to stop and report what it tried converts a runaway loop into a clear handoff — and the report is usually a precise description of the missing tool or permission.