LangGraph vs n8n: The Choice Is About State, Not Features

That is the short answer. The longer answer is that most teams asking the question already have n8n running, and what they actually want to know is whether their agent logic has outgrown it. Usually it has not. Sometimes it has, and the symptoms are specific.

What LangGraph vs n8n actually differ on

The ranking comparisons list node counts and integration numbers. Those are not the axis that decides the build. State is.

n8n passes an array of items from node to node. Each execution is a fresh run, and if you want anything to persist across runs you write it to a database, a static workflow data field, or an external store yourself. LangGraph holds a typed state object across the whole graph, and a checkpointer writes a snapshot after every super-step, so a thread can be resumed, forked or replayed from any prior point.

That one difference cascades into everything else.

	LangGraph	n8n
State model	Typed state object, reducers per key	Item array passed between nodes
Persistence	Checkpointer (Postgres, SQLite, memory) per thread	Execution log; you persist app state yourself
Resume after failure	Resume from last checkpoint, same thread	Retry the failed node or re-run the execution
Human in the loop	interrupt() pauses mid-graph, resumes with Command	Wait node, webhook resume, or a form node
Cycles	First class, edges can loop with a recursion limit	Loop node and IF branches, but back-edges get ugly fast
Integrations	Whatever you write or pull from LangChain tools	400-plus nodes, OAuth handled
Who maintains it	Someone who writes code	Someone who can read a canvas
Observability	LangSmith traces, or OpenTelemetry	Execution list with per-node input/output

The last row of that table decides more projects than the rest combined. A LangGraph agent is an application. It needs a repo, CI, a deploy target and someone on call. An n8n workflow is a config artefact a competent ops person can open at 11pm and understand.

When LangGraph beats n8n

Four situations, in my experience, where the LangGraph vs n8n call goes to LangGraph without much debate.

1. The model decides the next step, repeatedly. A research agent that plans, searches, evaluates whether it has enough, and loops back. In n8n you can build this with an AI Agent node and a tool set, but once you want custom routing between three or four specialist agents with shared scratchpad state, you are fighting the item model.
2. You need to pause for a human and resume days later in the same reasoning context. LangGraph's interrupt() stops mid-node, persists the state, and resumes with the human's input injected. n8n's Wait node resumes the workflow, but your agent's conversation state has to be rebuilt from wherever you stashed it.
3. You need to replay. When a proposal draft comes out wrong, being able to fork from checkpoint seven with a different prompt and compare is worth real money. n8n lets you re-run an execution with the same input data, which is close but not the same thing.
4. Token spend needs per-step caps and per-step attribution. You can do this in n8n, but you are writing Code nodes to do it. LangGraph gives you the hook points.

In BidStrike, the proposal drafting path fits case one and three exactly: three sequential review passes (Pink, Red, Gold) that critique and revise a Shipley-structured draft, where each pass reads the previous state. That is graph work.

When n8n beats LangGraph

More often than the agent framework crowd admits.

If the hard part of your problem is OAuth against HubSpot, pagination on a Salesforce Bulk query, a webhook that fires at 3am, and retrying a Google Sheets write that 429'd, then the LLM is a single node in a mostly boring pipeline. LangGraph gives you nothing there and costs you a deployment. This is the same reasoning that runs through most CRM workflow automation builds.

n8n also wins on handover. If the team operating the system cannot read Python, a LangGraph service is a black box to them forever. That is a legitimate architectural constraint, not a compromise.

And n8n has queue mode, concurrency controls and a supported self-hosting path, which means the operational story is solved out of the box. With LangGraph you either run LangGraph Platform or you build the API layer, the queue and the worker pool yourself.

LangGraph vs n8n on cost, honestly

The token bill dominates both. Neither framework meaningfully changes what you pay Anthropic or OpenAI, except in one respect: n8n's AI Agent node runs a model call to decide each routing step, where in LangGraph you can route with a plain conditional edge and skip the call entirely. On a graph with four decision points and 10,000 runs a month, that is 40,000 calls you did not make.

On infrastructure, n8n Cloud starts at €24 a month for 2,500 executions, and self-hosted Community has no per-execution charge, so a small VPS handles a few thousand executions a day for 10 to 40 dollars. LangGraph's open-source library is MIT and free; LangGraph Platform charges per node execution plus uptime for managed deployment, and self-hosting it means running Postgres and Redis yourself.

The cost nobody prices is the second system. Adding LangGraph to an n8n shop means a second deploy pipeline, a second on-call surface and a second place to look when something silently stops. That is the real number.

Running LangGraph and n8n together

This is what most mature setups actually look like, and it is what the LangGraph vs n8n framing tends to obscure.

n8n owns the edges. Triggers, CRM reads and writes, Slack, email, file handling, scheduling, retries against third-party APIs. When the flow reaches genuine agent reasoning, n8n calls a LangGraph service over HTTP with a thread_id, and either waits for the response or gets a callback into a Wait node webhook.

The boundary rules that matter:

• The LangGraph service owns the thread state. n8n passes the thread_id and nothing else stateful.
• Every tool call inside the graph gets logged with its arguments, its result and its token count, because n8n's execution log will only show you the one HTTP request.
• The HTTP call gets a hard timeout and a dead letter path in n8n. An agent that hangs is worse than one that fails.
• Human approval lives in n8n if the approver is a business user, and in LangGraph's interrupt() if the approval changes what the agent reasons about next.

That split is also the answer to "is n8n outdated now" and "what replaced n8n". Nothing replaced it. Agent frameworks took the reasoning layer, which was never n8n's strength, and left the integration layer where it always was. If you are weighing the runtime itself rather than the agent framework, the n8n alternatives worth taking seriously are Temporal, Windmill and Activepieces, not LangGraph.

If you are mid-build and cannot tell whether your agent logic has actually outgrown the canvas, send me the workflow export and the failure you keep hitting. Twenty minutes on a call usually settles it, and about half the time the answer is that you need better error handling, not a new framework.

Frequently asked questions

Is LangGraph better than n8n for building AI agents?

For agents where the model decides the next step and the graph loops back on itself, yes. LangGraph gives you typed state, checkpointing and mid-node interrupts that n8n does not have. For agents that mostly call three APIs and summarise the result, n8n's AI Agent node is faster to build and far easier for a non-developer to maintain afterwards.

Can n8n and LangGraph work together in the same system?

Yes, and it is the most common production shape. n8n handles triggers, CRM and SaaS integrations, scheduling and retries, then calls a LangGraph service over HTTP when real reasoning is needed, passing a thread_id. Keep all agent state inside LangGraph, log every tool call there, and put a hard timeout and dead letter path on the n8n side of the call.

Is n8n outdated now that agent frameworks exist?

No. LangGraph, CrewAI and similar frameworks took the reasoning layer, which was never what n8n was good at. n8n still owns OAuth, pagination, rate limit handling, webhooks and 400-plus integrations, plus a canvas that an operations person can debug without reading Python. Agent frameworks did not replace that work, they sit next to it.

Does LangGraph cost less than n8n at high volume?

Token spend dominates both, so the framework rarely changes the bill much. One genuine saving: n8n's agent node makes a model call to decide each routing step, while LangGraph can route on a plain conditional edge with no call at all. Self-hosted n8n Community has no per-execution fee, and the LangGraph open-source library is MIT licensed.

When should I choose CrewAI instead of LangGraph or n8n?

CrewAI suits role-based teams of agents with a fairly linear task handoff, and it is quicker to stand up than LangGraph for that shape. Choose LangGraph when you need explicit control over the graph edges, durable checkpoints and replay. Choose n8n when the bulk of the work is moving data between systems and the model is one step in a longer pipeline.