TL;DR: Tried to compare AI-agent n8n workflows against plain ones. Filtering the biggest public corpus by AI node type returned zero results out of 2061 files. Turned out 92.6% of AI node types had been overwritten to a do-nothing placeholder by a single squashed PR merge, co-authored by a Copilot agent. Names left intact, so it's invisible unless you count by type.
I set out to answer what felt like a simple question: are n8n workflows built around AI agents any more or less reliable than plain automation?
Never got to answer it. Here's what happened instead.
The plan
I already had a static analysis pipeline from a previous writeup, so the idea was just to split an existing corpus into two groups, workflows with an AI agent node and workflows without, then run the same detectors on both.
Corpus was Zie619/n8n-workflows. 56k stars, 2061 workflow files, MIT licensed, pinned to a specific commit so the whole thing is reproducible.
Filtered for the real n8n AI node types, @n8n/n8n-nodes-langchain.agent and friends.
Zero matches.
Not "a handful". Zero. In a 2000-file corpus. In 2026.
Something's off
That made no sense, so I filtered by node name instead of node type. A node somebody named "AI Agent - Movie Recommendation" isn't ambiguous about what it is, whatever the type field says.
711 of 2061 files came back.
So the names are there and the types aren't. Which means the types got overwritten at some point. Counted every individual node matching that name pattern:
- 1573 nodes with AI/LLM names
- 1457 of them typed
n8n-nodes-base.noOp
That's 92.6%. noOp is n8n's literal do-nothing placeholder. The node sits there with its descriptive name intact and does absolutely nothing.
Finding the commit
The repo's git history is public, so I went looking.
Earliest commit touching one sample file, Aug 2025, real contributor: types are correct. @n8n/n8n-nodes-langchain.agent, lmChatOpenAi, memoryBufferWindow. A real working AI agent workflow.
Types survive the next commit intact.
They don't survive 3c0a92c4, Sept 29 2025. A squashed PR merge. Its description is mostly placeholder text, "Initial plan" appears four times, and the actual change is Docker/K8s deployment infra. Author trailers include Co-authored-by: copilot-swe-agent[bot].
2057 workflow files changed in that one commit. Every LangChain-typed node in my sample files became noOp. Names untouched. Only the field that tells n8n what the node actually does got overwritten.
Checked three files independently, same pattern, same commit. Confirmed it's an ancestor of the snapshot I pinned to, and nothing after it repairs anything.
Someone in a discussion afterwards suggested this looks less like a serializer and more like a node type allowlist or package resolver that didn't recognise the scoped @n8n/ package and fell back to noOp. That would explain why only scoped types are affected and n8n-nodes-base.* nodes came through fine. Haven't confirmed it in the diff yet.
Is it just this repo?
Ran the identical check on enescingoz/awesome-n8n-templates, different owner, different license, no shared history.
226 of 342 files have AI-suggestive names. Every corresponding type is intact. agent, lmChatOpenAi, lmChatAnthropic, lmChatGoogleGemini, embeddingsOpenAi. Zero noOp substitutions.
So it's this repo's history, not how n8n exports things.
Why this is annoying for anyone counting
This is invisible to the obvious check. If you count AI nodes by name, everything looks normal. It only shows up if you count by type, which is what any automated analysis would actually do.
So if you've run, or are planning to run, "how many n8n workflows use AI agents" against this specific repo, your number is probably off by something close to 92%.
The comparison I actually wanted
Ran it on the clean corpus instead. Smaller sample (342 files, 251 with AI vs 91 without), so take it as a first pass:
| Signal | AI workflows | Plain workflows |
|---|---|---|
| Any node-level recovery mechanism | 21.1% | 13.2% |
retryOnFail configured |
8.0% | 6.6% |
onError continuation |
15.9% | 6.6% |
| Explicit throttling node | 17.5% | 9.9% |
| Webhook with no auth | 93.5% | 86.4% |
Honestly expected AI workflows to look worse, newer and more experimental, people moving fast. They mostly don't. A few signals run slightly better. Not the dramatic result I was fishing for, but that's what the numbers say.
Sample's too small to lean on hard, and the bigger corpus is unusable for this particular question for the reason above.
Repro
Detector code and the corpus fetch script with pinned SHAs: https://github.com/sevenedge-pl/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 a commit it came from. If you can't trace one of them, that's a bug in the post.
Longer version with the full commit archaeology is on my company blog. I run a two-person shop that self-hosts n8n for clients, which is how I ended up caring about this.
Top comments (0)