n8n vs Custom AI Agent Development: The Threshold
n8n vs custom AI agent development is a threshold question, not a religion. Five signals that tell you a visual workflow has stopped paying for itself.
Nobody Regrets Starting in n8n. Plenty Regret Staying.
The n8n vs custom AI agent development argument is usually staged as a matter of taste — low-code people on one side, engineers who want to write Python on the other — and that framing produces bad decisions in both directions. It isn't a taste question. It's a threshold question. There is a point where a visual workflow stops being the cheap option and starts being an expensive one wearing a cheap costume, and the useful skill is recognising that point before your automation becomes load-bearing.
We see both failure modes. Teams that rewrite a working nine-node workflow into a bespoke service because a senior engineer found the canvas undignified. And teams that keep bolting Code nodes onto a graph that now decides who gets refunded, with no tests, no staging environment, and one person who understands it.
This piece is about where the line actually sits.
What n8n Is Genuinely Good At
Start with the honest case for the tool, because it's stronger than most engineers admit.
n8n is a workflow engine with a visual graph, several hundred pre-built integrations, and a self-hostable runtime. Its real product is not the drag-and-drop canvas — it's the connector inventory and the execution log. Someone else already wrote the OAuth dance for Slack, HubSpot, Google Drive, Postgres and a long tail of SaaS, and every run leaves a per-node record of what came in and what went out. Rebuilding that from scratch is weeks of unglamorous work that produces zero differentiation.
For a deterministic pipeline — a webhook fires, three systems get touched, a message gets posted — n8n is faster to build and, crucially, faster to change than a service you'd have to deploy. Add an LLM call in the middle for classification or summarisation and it's still comfortably the right tool. That is not a prototype. That is a legitimate production architecture for a large class of internal automation, and self-hosting means the data never leaves your infrastructure.
The trouble starts when the thing in the middle stops being a step and starts being a decision-maker.
n8n vs Custom AI Agent Development: The Five Thresholds
Workflows are graphs you drew. Agents are graphs the model draws at runtime. Every threshold below is a symptom of that shift.
1. The control flow becomes non-deterministic
An n8n graph encodes the path in advance. A real agent chooses its own path: it decides which tool to call, how many times, and when it's finished. You can express a loop with a tool-calling node, but you're now asking a canvas designed for known edges to represent unknown ones. Debugging becomes reading an execution log to reconstruct a decision tree that only existed for 40 seconds.
Signal: you can't draw the expected execution path on a whiteboard before the run.
2. State outgrows the payload
Workflows pass data forward. Agents need memory: what was already tried, what failed, what the user corrected two sessions ago, which sub-goal is still open. Once you're writing state to Redis or Postgres from inside Code nodes and reading it back to decide the next branch, the canvas isn't holding your architecture anymore — it's decorating it.
Signal: more than one node exists purely to marshal state.
3. The Code nodes stop being glue
A Code node or two is normal. But when the meaningful logic lives inside JavaScript blocks embedded in a JSON workflow definition, you have written custom software with the worst possible developer experience: no type checking, no unit tests, no meaningful code review, no local debugger, and a diff that reviewers cannot read. This is the most common version of the problem, and it's invisible from a screenshot.
Signal: your workflow export is mostly code, and a pull request against it is unreviewable.
4. Failure needs semantics
Node-level retries handle transport errors. They do not handle an agent that succeeded mechanically and failed substantively — the call returned 200, the output is confidently wrong. Recovering from that needs compensating actions, idempotency keys, and an independent checker that decides whether the work was actually done. We've written at length about why agents fail in production, and the short version is that verification has to be a first-class component, not a node you tack on at the end.
Signal: "retry the node" isn't a meaningful recovery strategy for your worst case.
5. Somebody external will audit it
Multi-tenant data isolation, per-run scoped credentials, an immutable decision trail, evidence for a security questionnaire. n8n has credential management and execution history; it does not have your compliance model. When an auditor asks which customer's data touched which model on which date, you want that answer from a system you designed to produce it.
Signal: a customer contract or a regulator, not your team, defines what "correct" means.
The Decision Table
| Dimension | n8n fits | Custom agent fits |
|---|---|---|
| Control flow | Path known at design time | Model chooses tools and order |
| State | Passed along the payload | Persistent, cross-session memory |
| Logic location | Config plus light glue code | Versioned, tested application code |
| Integrations | Many, standard SaaS | Few, deep, proprietary |
| Change frequency | Weekly tweaks by an ops owner | Guarded by review and tests |
| Failure handling | Retry and alert | Compensation, checkers, budgets |
| Evaluation | Spot-checking runs | Regression evals on trajectories |
| Audit surface | Internal, low sensitivity | Contractual or regulatory |
| Concurrency | Tens of executions | Sustained or bursty at scale |
| Team | One ops-minded owner | An engineering team on call |
Read it as a count, not a verdict. One or two rows in the right-hand column is a healthy workflow with ambitions. Six is a distributed system that happens to be stored as JSON.
The Answer Is Usually Both
The framing that costs teams the most is treating this as a replacement decision. The architecture that survives is almost always a split:
n8n owns the edges. Custom code owns the reasoning.
Keep the connectors, the schedules, the webhook listeners, the human-approval steps and the notification fan-out in the workflow tool — that's where its connector inventory earns its keep and where non-engineers can safely make changes. Move the agent itself behind an HTTP boundary you control, so it can be tested, versioned, evaluated and deployed like any other service. The workflow calls one node. That node is your agent.
This is the same seam-first principle we apply to any custom software engagement: buy the boring substrate, build the part that's actually yours, and make sure the join between them is an interface rather than an entanglement. It also solves the migration problem before you have one — when the agent needs to become a real service, you replace the implementation behind the node instead of redrawing the graph.
Migrating Without a Rewrite
When a workflow has crossed the threshold, the move is incremental. In roughly this order:
- Draw the current graph as a contract. Inputs, outputs, side effects, and which nodes write to systems of record. Most teams discover here that two nodes do something nobody remembers approving.
- Extract the reasoning first. Move the prompt chain, tool selection and state into a service with a single well-typed endpoint. Leave every connector where it is.
- Build the eval set from real executions. n8n's history is an asset — twenty to fifty past runs with known-good outcomes become your regression suite. Do this before you change behaviour, not after.
- Run both in shadow. The workflow keeps executing; the new service receives the same input and writes nowhere. Compare for a week or two on real traffic.
- Cut the node over, keep the graph. The old branch becomes a fallback you can re-enable in one toggle.
- Move the gates into the tool layer. Scoped credentials per run, idempotency keys on every write, hard budgets on tokens and tool calls — controls that live in code, not in a prompt or a node description.
At Kuaray we do this in weeks rather than quarters, precisely because we don't start by throwing the workflow away. The graph is documentation of a process that already works, which is a much better starting point than a requirements doc written from memory.
The Rule of Thumb
If a human could write down the steps in advance and they'd still be right next month, use n8n. If the whole point is that the system decides what to do, and being wrong has consequences somebody outside your team will care about, build it — and build the checker before you build the agent.
Choosing custom code because a canvas feels unserious is vanity. Staying on a canvas because a rewrite feels expensive is deferral. The threshold is real, it's observable, and the five signals above will tell you which side of it you're standing on. If you're not sure, look at the last incident: whether you could explain what happened, and to whom, is the answer.
Talk to Kuaray about your automation architecture — we'll review your existing workflows, tell you which ones should stay exactly as they are, and build the ones that shouldn't. See how we approach AI and agent engineering, or our MVP approach if you're taking a first agent from workflow to product.