Short version, and it's less exciting than the framework debates suggest: build the agent in n8n unless the run has to survive a crash, wait hours on a human, or loop back on its own state — then move that one piece to LangGraph and leave everything else in n8n. Complexity is not the trigger. Durability is.
We've shipped over 200 production workflows, and a meaningful chunk of them include an AI agent of some kind. The number we've had to rebuild in code is small — maybe one in ten. Every one of those rebuilds failed in n8n for the same reason, and it was never "the logic got too complicated."
The question people ask vs. the question that matters
Every comparison post frames this as a power ranking. LangGraph is the powerful one, CrewAI is the friendly one, n8n is the no-code one. That framing is useless when you're quoting a client on Tuesday.
The actual question is narrower: does this agent need to remember where it was if the process dies?
n8n executes a workflow as a run. The run either finishes or it doesn't. There is no checkpoint at step seven that you can resume from — if the worker gets OOM-killed at step nine of twelve, that run is gone, and your retry starts over from step one. For a lead-scoring agent that takes 30 seconds, who cares. For a 40-minute research agent that has already burned $4 in tokens and written half its findings to a CRM, that's a real problem.
LangGraph is built around exactly that problem. It saves a checkpoint of full graph state after every node to SQLite or Postgres. Crash the server, restart it, and the run picks up where it stopped. Pause for a human approval and the state sits in the database for as long as it needs to — no thread held open, no timeout.
That's the whole difference, and it's worth being blunt: everything else you've read about "orchestration power" is downstream of persistence.
The three n8n limits that actually show up in production
Not theoretical ones. These are the ones we've hit on client accounts.
Max Iterations defaults to 10, and hitting it looks like success. The AI Agent node caps its reasoning loop so a confused model can't spin forever. Sensible. The catch is that when the agent hits the cap, it returns through the success output, not the error output. So a truncated, half-finished agent run flows downstream looking exactly like a completed one. We caught this on a client's research agent that was silently returning partial summaries for eleven days. Nobody noticed because the workflow was green. If you run agents in n8n, add an explicit check on the agent's output shape before you trust it — don't rely on the node's status.
Memory across runs is your problem, not n8n's. Inside a single run, the agent appends tool results to its own conversation history automatically. Across runs — a customer coming back tomorrow, a multi-day approval — n8n gives you nothing native. You wire up Redis, Postgres, or a vector store yourself. That's fine, it's a solved problem, but it's the point where "no-code" quietly stops being true and your workflow starts carrying a schema.
Context grows with iterations, and cost grows with context. Each loop appends the last tool result to the prompt. An agent that takes 12 iterations is paying for the transcript of the previous 11 on every call. We had a support-triage agent whose token bill was 4x the estimate purely because it averaged nine tool calls instead of the three we'd modelled. The fix wasn't a framework change — it was cutting the tool list from eleven to four, which dropped average iterations to three. We wrote up that whole cost model in what AI agent development actually costs.
When n8n is clearly the right call
Most of the time. Genuinely.
- The agent is event-triggered and finishes fast. A form comes in, the agent enriches and routes it, done in under two minutes. This is the majority of what agencies get paid to build.
- The value is in the integrations, not the reasoning. If 80% of the work is talking to HubSpot, Google Calendar, Slack, and a Postgres table, n8n has already written that code and you haven't. Reproducing four authenticated integrations in Python to save on a framework tax is a bad trade.
- Someone non-technical has to look at it. The execution log is an underrated production asset. When a client asks "what happened to the lead from Thursday," opening a visual run and pointing at the failed node is a 30-second answer. In a code agent it's a log-diving expedition.
- You need it live this week. An n8n agent goes from idea to production in a day or two. A LangGraph service needs a repo, a deployment target, a database for checkpoints, monitoring, and a CI pipeline before it does anything a client can see.
- The flow is linear or lightly branched. Trigger, fetch context, call the model, act, notify. If you can describe it left to right without saying "and then it goes back to," it's an n8n workflow.
If you're weighing whether a piece of logic even belongs in the agent node versus a plain sub-workflow, that's a separate and often better first question — we broke it down in AI Agent node vs. sub-workflow.
The four signals that mean it's time to write code
When we see any of these, we stop trying to force it into the canvas.
1. A dead run costs real money. Not "annoying," costly. Duplicated charges, half-migrated records, a partially sent campaign. Without checkpoints your only recovery is idempotency you've built by hand into every step — and by the time you've built that, you've built a worse checkpointer.
2. The agent has to wait on a human for longer than a timeout. Approval flows where a person might respond in ten minutes or three days. You can fake this in n8n by splitting into two workflows joined by a database row and a webhook, and we have. It works. It's also three moving parts pretending to be one, and each one can fail independently. LangGraph pauses, persists, and resumes as a first-class operation.
3. The control flow is a graph, not a line. The agent evaluates its own output, decides it's not good enough, goes back two steps with modified parameters, tries again, and gives up after the third attempt. That's a cyclic graph with state. n8n can express it — with loop nodes, static data, and a counter you maintain yourself — but you'll be reading your own workflow like a puzzle six weeks later.
4. You need to test the reasoning, not just the plumbing. Once an agent's quality is the product, you need eval suites, regression cases from real production traces, and the ability to replay a bad run against a new prompt. That's a code workflow. We've written about testing n8n agents before they hit production, and the honest limit of that approach is that you're testing the workflow, not systematically grading the model's judgment across hundreds of cases.
What we actually do: n8n as the shell, code as the core
The framing that both sides get wrong is that you have to pick one.
Our default for a hard agent looks like this. n8n owns the front door and the last mile. It receives the webhook, pulls the CRM record, holds the credentials, routes the result to Slack or email, and runs the error workflow when something breaks. The one genuinely stateful piece — the part that needs checkpoints, or the eval-gated reasoning loop — runs as a small LangGraph service behind an HTTP endpoint. n8n calls it like any other tool.
You get the operational layer your team can read and the durability the problem demands, and you only pay the engineering tax on the 10% that needs it.
Two practical notes if you go this route. First, put the service behind a real queue-mode n8n setup rather than a single main process, because you're now making a call that can take minutes — we sized that out in how many n8n workers you actually need, and the official queue-mode docs cover the setup. Second, wire the error workflow before you ship, not after the first 2am incident; our error handling and monitoring setup is the version we install on every client instance.
Where CrewAI lands
Briefly, because it comes up in every one of these conversations.
CrewAI is the nicest abstraction of the three when your problem genuinely is a team — a researcher who hands to a writer who hands to a reviewer. The code reads like the process description, which is worth something real. It's also the framework we reach for least in agency work, for an unglamorous reason: most client problems are one agent doing one job well. A crew of five agents is usually four agents and a lot of token spend that a single well-scoped agent with four tools would have handled. Multi-agent is an architecture, not an upgrade.
The rule, in one line
Ask what happens if the process dies at step nine. If the answer is "we run it again," build it in n8n and stop reading framework comparisons. If the answer makes you wince, extract that piece into LangGraph and let n8n keep doing what it's genuinely great at.
We've been wrong in both directions. We've rebuilt an n8n agent in Python that should have stayed on the canvas — six weeks of work for a system that was harder to hand off and no more reliable. And we've kept a long-running migration agent in n8n far too long, re-running the whole thing from scratch every time a rate limit killed it at minute 30. The second mistake was more expensive, but the first one was more embarrassing.
Not sure which side of the line your project falls on? Get a free automation audit. We'll look at what you're building, tell you honestly whether n8n handles it, and if it does, we'll say so — that's usually the cheaper answer, and it's the one we give most often.