The fortieth workflow is the one that gets you, not the four hundred thousandth execution.
The short version: n8n scales fine. People running it from a $6 droplet past 400,000 executions a month are not lying to you. What stops scaling is your ability to change it — and that bill arrives as maintenance, not as downtime.
The fortieth workflow
Here is a pattern we see often enough to describe it as a type.
A team adopts n8n and it goes well. The first workflow takes an afternoon and replaces a job someone hated. So does the second. Within a year there are forty, they touch billing, onboarding, support and reporting, and one person understands roughly thirty of them.
Then that person takes two weeks off, a supplier changes an API response, and four workflows fail quietly. Nobody notices until a customer does.
Nothing here is a failure of n8n. Every one of those forty workflows was the right call when it was built. The failure is that forty of anything needs a maintenance strategy, and node graphs in a web UI make it unusually easy to skip having one.
This piece is about where that line sits, and what to do about the workflows on the far side of it.
What n8n genuinely wins
Let us be straight, because the rest of this only counts if this part is honest.
Throughput is not the problem. n8n scales. In queue mode with workers it scales close to linearly, and the community is full of people running enormous volumes on modest hardware. If someone tells you n8n cannot handle your execution count, ask for their number — it is usually far below what n8n does comfortably.
Connectors and glue are its home ground. Triggers, webhooks, scheduled syncs, moving fields between two systems that were never designed to talk. Building that in code is slower, more expensive, and worse. n8n will beat a custom build on time-to-first-value almost every time.
And it evaluates AI now. This matters, because a year ago the honest criticism of agents built in n8n was that you could not test them properly. That is no longer true. n8n ships an Evaluations feature — you store test cases in Data Tables, run your agent against them, and score with built-in metrics including correctness comparison, string similarity and RAG document relevance. If you are running an agent node in production and not using it, that is the cheapest improvement available to you today.
So the argument is not that n8n is the wrong tool. For most of what people call AI automation, it is the right one.
Where the wheels come off — and it is not throughput
The revealing thing about how practitioners describe the problem is the adjective they choose. The community threads are not titled "why is n8n slow". They are titled things like "why do most n8n workflows become messy after scaling".
Messy, not slow. That is a different failure, and it has a cause.
A node graph grows with the number of cases you enumerate, not the number of times you run it. Every new edge case is a new branch. The supplier who sends dates in a different format, the invoice with two purchase orders, the customer who replies to the confirmation email instead of the support address. Each is a small, sensible addition. Each is permanent.
Run that for a year and the graph encodes every exception anyone ever hit, in the order they hit them, with no structure imposed by anything except chronology. It still executes in milliseconds. Nobody can safely change it.
And some things never become a branch at all. "Is this invoice discrepancy material?" is not a condition you can express in a node. You either hard-code a threshold that is wrong at the edges, or you route it to a human and accept the queue.
The maintenance bill
This is where the cost actually shows up, and it shows up in three places.
Version control is an Enterprise feature, and it gets skipped. This is not our claim — it is n8n's. Their own guidance on deploying AI agents in production notes that extended version control lives in the Enterprise tier, and that Community users can create their own backups. The consultancy HatchWorks put the practical consequence more bluntly in their n8n production checklist: version control for n8n workflows is "straightforward in principle and consistently skipped in practice."
The result is a production system with no diff, no pull request, no review, and no clean rollback. You would not accept that for application code. It arrived by default here because the editing surface is a canvas rather than a file.
Error handling is engineering you own — forever. n8n gives you the primitives: retries, error workflows, alerting. It does not give you the discipline. Every workflow needs its own error path, written by whoever built it, and nothing audits whether those paths still work six months later. The existence of an entire genre of "stop your n8n workflows failing" guides tells you how often this is the thing that bites.
Change cost compounds. One policy change — a new approval threshold, a renamed field, a supplier switching endpoints — and you are editing it in nine places, by hand, in a UI, with no compiler to tell you which one you missed. This is the cost people mean when they say they need someone to maintain n8n. They rarely mean the servers.
For a small team in Kuala Lumpur or Singapore this has a sharper edge than it does elsewhere. The workflows are usually built by one capable person who is not a full-time automation engineer. When they change roles, the institutional knowledge leaves with them, and what remains is a canvas nobody wants to touch.
What the Claude Agent SDK changes
The Claude Agent SDK is not a better n8n. It solves a different part of the problem, and the differences that matter are unglamorous.
It is code, so it inherits everything code has. Version control that nobody has to remember to do. Pull requests. Tests that run in CI. A diff a colleague can read. A rollback that takes one command. None of this is exciting and all of it is why the fortieth workflow stays maintainable.
You control the agent loop. How many tool-calling turns before it gives up. What happens when a tool fails — repair and retry, or escalate. Whether low confidence means guessing or refusing. How context gets compacted on a long-running task so the twentieth step still remembers the first. An agent node abstracts these decisions; on a job that runs against real money, you usually want them.
You route models per task. Haiku for classification, Sonnet for the reasoning step, Opus only where it earns its cost. Getting this wrong is the most common way to overspend on AI, and it is fiddly to express inside a node graph.
And evaluation is part of shipping, not a feature you remember to use. Every agent we put into production carries a scorecard: what it was measured on, what it scored, and where a human stays in the loop. We call the method Agent GPA, and the part that matters is the sequence — we score the manual process first, so "92% accurate" has something to be better than.
The answer is usually both
If you searched for something like n8n ai agent, you were probably not trying to pick a winner. You were trying to work out how they fit together. The honest answer is that they fit together well.
The shape that ships most often looks like this: n8n owns the plumbing — triggers, connectors, IO, retries, the scheduled sweep at 6am — and calls an agent for the one step that needs judgement. The agent does not need to know how to talk to your ERP; that is a solved problem and n8n solved it. n8n does not need to decide whether a discrepancy is material; that is not a thing a node graph is good at.
That division also fails gracefully. If the agent is wrong, it is wrong in one bounded step you can score and monitor, rather than diffused across a graph.
How to tell which side a workflow sits on
Three questions, in order.
1 · Does the work have a fixed set of outcomes you could list on a whiteboard? If yes — keep it in n8n. Routing, syncing, notifying, formatting. Adding an agent here means paying model costs and latency for something a deterministic node does perfectly.
2 · Does the number of edge cases keep growing? If every month adds branches and nobody can say how many exist now, the graph is encoding judgement it was never meant to hold. That is the migration candidate.
3 · Would you let it act without a person checking? If no, you do not need a smarter agent — you need a clearer boundary. Put the judgement step behind an evaluation and a human gate, and leave the rest where it is.
Most teams find that thirty-five of their forty workflows should stay exactly where they are, and three or four are quietly costing more in maintenance than they ever saved. Those are the ones worth moving.
Worked examples of agents built this way — with the workflow, the model reasoning and the evaluation scorecard published — are in our agent use-case library. How the agent reaches your existing systems is covered in connecting AI to business systems with MCP, and if you are still deciding what you need at all, chatbot versus AI agent is the more useful question to settle first.
The team described at the top of this article is a composite drawn from patterns we see repeatedly, not a single client.
Free consultation
Hitting the maintenance wall?
Bring us your workflow list. We will tell you which ones are worth moving to a custom agent and which should stay in n8n — and for most teams, most of them should stay. You will get the reasoning either way.
Related reading: AI agent development for what we build · how we score an agent before it ships · estimate what running one costs.