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.
What The Workflow Could Not Tell Me
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: