My First n8n AI Agent Build Went Into an Infinite Loop — Here's What Actually Fixed It

The setup

I'd used n8n for straightforward automations for a while — triggers, transforms, API calls, the usual — but this was my first time actually building with the AI Agent node instead of a plain LLM node. The task was simple enough on paper: an agent that takes an incoming support message, checks an order lookup tool, and replies. One tool, one clear job.

First run, it worked. Second run, on a slightly ambiguous input, it just kept calling the same tool over and over. No error, no crash — the execution log just kept growing, same tool call, same-ish arguments, until I killed it manually after it had run for a few minutes straight.

Where I went looking first

My first assumption was the prompt — that I hadn't been specific enough about when to stop, so I rewrote the system prompt to be much more explicit: "once you have the order status, respond immediately, do not call the tool again." Ran it again. Looped again, on a different input this time. That ruled out "the agent just doesn't know when to stop" as the whole story, because I'd told it exactly that, and it still didn't stop — which meant the problem wasn't really about instructions at all.

What was actually happening

I went digging into how the Agent node actually decides whether a tool call succeeded, instead of assuming the model was just ignoring my prompt. The core issue: the version of the AI Agent node I was on predated n8n's January 2026 update (v1.28), which added structured tool calling specifically to prevent infinite loops. Before that, tool call outputs weren't validated against a schema — if my tool returned something the model didn't parse cleanly (in my case, a lookup that sometimes returned null for an unmatched order ID), the model would treat that as an unclear or failed result and just try the tool again, hoping for a better answer. Nothing was catching that loop before it happened.

There was a second thing wrong too, and I wasn't sure yet whether it mattered as much: my agent had no memory configuration at all. Every tool call was happening with no record of what had already been tried, so from the model's perspective, calling the same tool a second time with a null result looked identical to calling it the first time.

Rather than fix both at once and guess at which one actually mattered, I decided to isolate them.

The fix, tested in isolation

Step 1: Update to structured tool calling alone, nothing else changed. Upgraded to v1.28, left the agent stateless with no memory backend, made no prompt changes beyond reverting my earlier "don't call it again" edit. Ran the same batch of test inputs that had triggered loops before — 15 cases, including the ones that previously ran indefinitely.

Result: loops stopped happening in the literal sense — the schema validation now caught the malformed null response and returned a clean error to the agent instead of letting it silently retry forever. But the agent's behavior on a null result was still bad: it would apologize, then immediately try the same tool call again anyway, sometimes two or three times before giving up. Not an infinite loop anymore, but not a good answer either — just a shorter, bounded version of the same confusion.

Step 2: Add memory on top, same 15 test inputs. Added Postgres as the memory backend, since I already had a database in the stack for everything else, and reran the same batch with no other changes. This is where the repeated-call behavior actually went away — with memory in place, a repeated tool call with the same failing input showed up as a repeat in context, and the agent stopped trying the same thing a second time on its own, without needing to be told to.

Step 3: Add the explicit null-handling instruction, same batch again. Only after steps 1 and 2 were both in place did I add:

If the order lookup tool returns no match, do not retry the same

lookup. Respond to the user directly: explain the order ID wasn't

found and ask them to double check it. Only retry the tool if the

user provides a corrected order ID.

This step mattered less than I expected going in — memory alone had already stopped most of the repeat-calling. What the explicit instruction added was consistency: without it, the agent sometimes handled a null result by explaining it well, and sometimes by giving a vague non-answer. The instruction closed that gap rather than fixing a loop that, by this point, mostly wasn't happening anymore.

What the isolation actually showed

Breaking it into three steps instead of shipping all three fixes at once made the actual weighting clear, which I wouldn't have gotten from just comparing "before" and "after everything":

• Schema validation (step 1) stopped the unbounded looping — the literal never-ending version of the bug.
• Memory (step 2) stopped the repeated calling — the shorter but still wasteful version.
• The explicit instruction (step 3) improved consistency, not the loop itself.

If I'd only done the version update and called it fixed, I'd have shipped something that no longer hung forever but still wasted tool calls and confused the customer on a decent share of null results. If I'd only added memory without the version update, the schema validation gap would still have let a genuinely malformed response go unhandled in a way memory alone can't catch.

Result

Across the same 15 test cases plus a wider batch of about 40 runs afterward, zero unbounded loops with just the version update, occasional (2-3x) repeat calls with the version update alone, and no more than one retry — the reasonable, expected kind — once memory was added. The explicit instruction didn't change the retry count further but did make every null-result response read the same way, instead of varying in quality run to run.

What I took away from this

The loop looked like a prompting problem because that's the layer I could see and edit easily. It wasn't, and isolating the fixes is what actually proved that — memory and schema validation were solving two different failure modes that happened to look identical from the outside (both showed up as "the agent called the tool again"). If your first AI Agent build loops or repeats itself, check the node version and memory configuration before you spend more time rewriting the system prompt, and if you're not sure which one is doing the work, ship them one at a time. A stateless agent calling an unvalidated tool will find creative ways to repeat itself no matter how clearly you ask it not to — but which of those two problems you actually have changes what "repeat itself" looks like, and it's worth knowing which before you call it fixed.