Archive note: This incident occurred on December 31, 2025. The linked
n8n issue remained open when this article was reviewed in June 2026.
Node versions and workarounds should be tested against a current
installation.
The automated editor stopped editing.
Every request ended with a maximum-iterations error. Execution
history showed the agent calling the same status tool repeatedly, often
twenty-five times in less than a minute. The tool returned data, but the
agent behaved as though it had never seen the response.
Changing the language model did not help. Removing conversational
memory did not help. Increasing the iteration limit only allowed the
loop to run longer.
The repetition was the clue.
Isolate the Failing Layer
Other workflows using the same model providers still worked. They
called models through ordinary HTTP request nodes and did not use the AI
Agent’s tool loop.
That narrowed the problem:
- The model endpoint was reachable.
- The credentials were valid.
- n8n could execute workflows.
- The failure occurred when the Agent node called a connected tool and
continued reasoning.
The system was not suffering a general model outage. It was losing or
failing to use the record of its own tool call.
A Matching Upstream Report
An n8n GitHub issue opened in November 2025 described an AI Agent
repeatedly querying a data-table tool across multiple models and n8n
releases. The symptoms matched our execution history closely.
The issue did not establish that every repeated tool call shared one
root cause, and our draft initially stated the internal mechanism too
confidently. What we could verify was narrower:
- Tool execution succeeded.
- The next agent iteration repeated the same call.
- Multiple models produced the same behavior.
- An older Agent node implementation did not reproduce it in our
workflow.
For this installation, changing the Agent node from a 3.x type
version to 1.9 stopped the loop without downgrading the entire n8n
platform.
That was a workaround, not a universal fix.
Why Raising the Limit Was
Wrong
n8n exposes a maximum-iterations setting for its Tools Agent. The
current documentation describes it as the number of model runs allowed
while attempting to produce an answer.
When an agent is making useful progress, a larger limit can
accommodate a multi-step task. When it is repeating one tool call, the
limit is a circuit breaker.
Increasing it from ten to twenty-five did not improve reasoning. It
increased API usage and delayed the failure. The correct question was
not “How many calls should the agent be allowed?” but “Why does the
second call contain no new information?”
Repeated identical calls should be treated as an incident signal.
The Older Node Changed
Input Behavior
The older node version solved the loop in this workflow but
introduced compatibility work. Tool parameters arrived in a different
shape, sometimes as a string that needed parsing rather than the
structured object expected by newer nodes.
That trade-off is why silently editing a workflow’s exported JSON is
risky. A node type version is not cosmetic metadata. It can change
execution semantics and the contract between connected nodes.
The safer migration process was:
- Duplicate the workflow.
- Change the Agent node version in the copy.
- Inspect actual tool inputs and outputs.
- Add explicit parsing where required.
- Run a bounded test with harmless tools.
- Compare execution traces before replacing production.
Direct database edits should be a last resort backed by an export and
database backup.
Add a Repetition Guard
Even with a corrected node, an agent should not be free to call the
same tool with identical arguments indefinitely.
A wrapper can hash the tool name and normalized arguments, then track
recent calls within one execution. If the same request appears
repeatedly without an intervening state change, the wrapper can stop and
return a diagnostic error.
Useful guardrails include:
- Maximum total tool calls
- Maximum identical calls
- Per-tool rate limits
- Timeout for the whole agent run
- Read-only tools during diagnosis
- Execution logging that preserves arguments and summarized
results
These controls turn a runaway reasoning loop into a bounded
failure.
The Broader Lesson
Agent frameworks combine models, prompts, tools, memory, parsers, and
orchestration code. A failure that appears to be “the model is confused”
may live in any of those layers.
Changing models repeatedly was initially attractive because models
are visible and easy to swap. The decisive evidence came from comparing
workflow types and reading the execution trace.
The agent called the same tool twenty-five times because the system
permitted it to. The practical fix was partly a version workaround and
partly a better operational posture: bounded iterations, repetition
detection, harmless test tools, and skepticism toward any agent that
repeats itself without changing state.
References: