A Coding Agent Erased n8n's AI Agents. We Found the Commit.

Three weeks ago we published an audit tracing a widely repeated 97%-failure-rate statistic back to a content-marketing article with no source, and along the way found a data-integrity bug in the most-reused public n8n workflow dataset, traceable to one specific commit. We said at the time we'd extend the same tooling to n8n's hottest current subcategory: workflows built around AI agents.

We went to build that comparison. Here's what happened instead.

The hype is exactly what you'd expect

Before touching any data, we catalogued what's currently circulating about AI agent reliability in n8n. Same pattern as last time: specific, confident numbers, almost no sourcing.

Two of them are worth dwelling on, because they're not just unsourced: they're the same story. In April 2026, a practitioner blog described a five-person support team handling roughly 40 recurring questions (order status, returns, shipping), an n8n AI agent resolving 78% of tickets without human involvement, the remainder routed to a human with context attached, and the pattern claimed at scale "across 40+ production systems," across the same three industries in the same order: ecommerce, legal, logistics. A month later, a different site published what reads like the same case study under a different byline: same five-person team, same ~40 questions, same 78%, same 22% routed with context, the identical claim of "40+ systems," and the same three industries in the same order.

Neither site names the client. Neither publishes ticket counts, logs, a definition of "resolved," or a baseline. One of the same two bylines also supplies the source for an entirely different unverifiable claim we catalogued, a one-workflow, no-logs comparison of n8n against Zapier, meaning this isn't one company's isolated exaggeration, it's the same claim being laundered across what look like independent "expert" sites.

That pattern held across the rest of the sample we pulled: of twelve specific, dated numerical claims about n8n AI agent performance published in 2026, ten come from a business with a direct commercial interest in the claim being believed, and zero publish enough to independently reproduce the result: no client name, no log export, no defined denominator, no baseline. We're not calling any of them false. We're calling them, precisely, publicly unverifiable claims by an interested party. That's a different, and more useful, thing to say than "fake."

Then we tried to build the comparison. It returned zero.

The plan was simple: split our existing, pinned corpus into workflows that use an AI agent node and workflows that don't, then run the same reliability detectors from our first piece on both groups separately. Same corpus we already had: Zie619/n8n-workflows, 2,061 files, pinned at commit 94007c1445d9.

We filtered for the real n8n AI node types: @n8n/n8n-nodes-langchain.agent and its siblings.

Zero files matched.

That's not a small number for a dataset this size: it's a dataset that, by node type, appears to contain no AI agent workflows at all. Which didn't square with anything we knew about this corpus or this ecosystem, so before writing that off as "n8n's AI adoption is lower than expected," we checked by a different signal: node names instead of node types. A node someone named "AI Agent: Movie Recommendation" or "OpenAI Chat Model" is not ambiguous about what it's supposed to be, regardless of what its type field says.

711 of 2,061 files (34.5%) contain at least one node whose name unambiguously describes AI or LLM functionality. Across those files, we counted every individual node matching that pattern: 1,573 nodes. Of those, 1,457, or 92.6%, carry the type n8n-nodes-base.noOp: n8n's literal do-nothing placeholder. The node is still in the file. Its name is untouched. Its function is gone.

The commit

We traced this the same way we traced the connections-graph defect in the first piece: by reading the source repository's full public commit history, not just the pinned snapshot.

At the earliest commit touching one sample file (5 August 2025, a real contributor), the node types are correct and specific: @n8n/n8n-nodes-langchain.agent for the AI Agent node, @n8n/n8n-nodes-langchain.lmChatOpenAi for the OpenAI Chat Model, @n8n/n8n-nodes-langchain.memoryBufferWindow for its memory. A real, working, correctly-typed n8n AI agent workflow.

Those types survive the next commit intact, the one where the fabricated "Error Handler" and templated "Workflow Documentation" nodes we described in our first piece first appear, incidentally confirming those two defects were introduced separately, not in the same pass.

They do not survive the commit after that: 3c0a92c4, dated 29 September 2025, merging a pull request whose own description reads, in part, as a scramble of placeholder messages ("Initial plan" appears four times), building out unrelated Docker and Kubernetes deployment infrastructure. Its author trailers list Co-authored-by: copilot-swe-agent[bot] alongside a human GitHub handle. In that single commit, 2,057 workflow files changed. In the sample file, every LangChain-typed node (the agent, the chat model, three separate OpenAI embedding nodes in another file we checked) becomes n8n-nodes-base.noOp. The node's name is untouched in every case we checked. Only the field that tells n8n what the node actually does was overwritten.

We checked this on three files independently; all three show the identical pattern, at the identical commit. We confirmed that commit is a direct ancestor of the snapshot our analysis is pinned to; nothing between them repairs it.

We're not attributing this to any individual's judgment, and we don't know whether a human reviewed this specific diff before merging it. What we can state directly: an autonomous coding agent's authorship is attached to a commit that, while doing something else entirely, silently deleted the functional definition of the exact category of node that a study of "AI agents in n8n" would need to count.

Why this is worse than it sounds for anyone using this corpus

We ran the identical check against our second, independently licensed corpus: enescingoz/awesome-n8n-templates (CC BY 4.0), no shared history with the first. 226 of 342 files (66.1%) have AI-suggestive node names. Every single one of the corresponding node types is intact: real agent, lmChatOpenAi, lmChatAnthropic, lmChatGoogleGemini, embeddingsOpenAi types, zero substituted with noOp. Whatever happened in the primary corpus is specific to that repository's history, not a property of how n8n exports AI agent workflows.

This is now the third independently confirmed data-quality defect we've found in the primary corpus, and each one is invisible to a different kind of check. The connections-graph defect we reported previously doesn't show up in a security scan, because dangling references don't create an exploitable path. This one doesn't show up in a naive count of AI/LLM nodes by name, because the names were left alone; only the field an automated count would actually key on is gone. Anyone who has run, or plans to run, a "how many n8n workflows use AI agents" analysis against this specific 56,000-star repository by filtering on node type has almost certainly undercounted, possibly by close to the 92.6% we measured.

What we could still measure

With the primary corpus's AI-node data unusable for this specific comparison, we ran it on the clean one instead, smaller, but trustworthy. Same detectors as our first piece, same definitions, no new code:

We'll say plainly what we expected going in: that AI-agent workflows, being newer and more experimental, would show worse error-handling discipline than plain automation. That's not clearly what this shows. On several signals the AI cohort runs a few points higher, not lower. On webhook authentication, already close to universal in both groups, the AI cohort is somewhat worse, but the base rates there (46 and 22 webhook-bearing workflows respectively) are too small to lean on hard.

We're reporting this honestly rather than reshaping it into the more dramatic story we might have expected: on this one corpus, at this sample size, we do not see clear evidence that AI-agent workflows are configured any less carefully than ordinary automation. We also don't have the primary corpus's larger sample to check that against, for the reason described above. Treat this table as a first pass, not a settled answer; we'll revisit it if a larger, cleanly-typed public corpus becomes available.

What we're not claiming

• A verdict on AI agent reliability in general. This measures configured safeguards in published templates, on one corpus, at n=342. It is not a runtime study and it is not a large-sample one.
• Intent behind the commit. We can state what changed, in which commit, with which authorship attached. We can't state why, or whether it was reviewed.
• That the twelve marketing claims we catalogued are fabricated. We're stating that they're unverifiable by an outside reader as published, which is a narrower and more defensible claim.

Reproduce this yourself

Same open-source pipeline as before, now with the node-erosion detector and the second-corpus cohort split included: github.com/adix65/n8n-reliability.

python3 -m n8n_reliability.cli fetch-corpus --dest data/corpus/n8n-workflows
python3 -m n8n_reliability.cli analyze --corpus-dir data/corpus/n8n-workflows --out-dir out

Every number above has a numerator, a denominator, and the commit or file path it came from, in the repository. If you can't trace a percentage in this piece back to those three things, that's a bug in the piece, not a fact about n8n or about AI coding agents.

SEVENEDGE builds and runs self-hosted n8n automation for production clients, alongside custom business software. This piece is static analysis of publicly shared workflow files and publicly available commit history, not a claim about any specific client system, and not an evaluation of any specific coding agent's general reliability.