The LangChain vs LangGraph question trips up a lot of builders because they sound like competitors. They aren't. LangChain is the toolbox of integrations and the glue for linear pipelines; LangGraph is a runtime for stateful, cyclic agent control flow. Picking right depends on whether your workflow runs straight through or loops back on itself.
LangChain vs LangGraph: the core difference
LangChain models your app as a chain — a directed, mostly acyclic flow where output A feeds input B feeds input C. With LCEL (LangChain Expression Language), you compose runnables with the pipe operator: prompt | model | parser. It's clean, declarative, and great when the path is known ahead of time.
LangGraph models your app as a graph of nodes and edges with shared state. Nodes are functions that read and write a typed state object; edges decide what runs next — including conditional branches and cycles. That cyclic capability is the whole point: an agent that calls a tool, inspects the result, and decides whether to call again is a loop, and loops are awkward to express as a chain.
Put simply: LangChain is about composition, LangGraph is about control flow and durable state.
Where LangChain still wins
Reach for LangChain when the work is fundamentally sequential and you want to move fast:
- RAG pipelines: retrieve documents, stuff them into a prompt, generate an answer. One pass, no looping.
- Prompt-and-parse tasks: classification, extraction, summarization, rewriting — anywhere the structure is a fixed pipeline.
- Integration glue: LangChain's library of loaders, vector store wrappers, retrievers, and model adapters is enormous. Even LangGraph apps lean on these components.
- Prototypes: when you want a working demo in twenty lines and don't yet know if you need branching logic.
The catch: the moment your chain needs to retry on a bad result, branch on a classification, or let an agent decide its own next step, you start bolting conditionals onto something that wasn't designed for them. That's the signal to look at LangGraph.
Where LangGraph earns its place
LangGraph exists for the workflows that loop, branch, and need to survive interruption. Concrete cases:
- Tool-using agents: the classic reason-act loop. The model proposes a tool call, the graph executes it, feeds the observation back, and re-enters the model node until it's done.
- Multi-agent systems: a supervisor node routes to specialist nodes — a researcher, a coder, a critic — and collects results. Edges encode who hands off to whom.
- Human-in-the-loop: LangGraph can checkpoint state and interrupt before a sensitive node, wait for an approval, then resume from exactly where it paused.
- Self-correction: generate, run a validator node, and if it fails, route back to regenerate with the error in context. That's a cycle a chain can't model natively.
State is the real feature
The reason LangGraph handles these cleanly is its state model. You define a schema (often a TypedDict), and each node returns partial updates that get merged in. Reducers control how updates combine — appending to a message list instead of overwriting it, for example. Pair that with a checkpointer (in-memory, SQLite, or Postgres) and you get persistence, time-travel debugging, and resumable runs for free.
How to choose
Skip the brand loyalty and ask three questions about your workflow:
- Does it loop? If the same step can run an unknown number of times — agent reasoning, retries, iterative refinement — that's LangGraph. A fixed number of sequential steps is LangChain.
- Does it branch on runtime decisions? A few static
ifstatements are fine in plain Python around a chain. Many model-driven routing decisions want a graph with conditional edges. - Does it need durable state? If you need to pause for human approval, resume after a crash, or inspect intermediate state across a long run, LangGraph's checkpointing is the answer.
Three nos point at LangChain. Any yes points at LangGraph.
You'll often use both
This isn't an exclusive choice. A common production shape is a LangGraph control loop whose individual nodes are built from LangChain components — an LCEL chain for retrieval here, a LangChain model wrapper there. LangGraph orchestrates the when and whether; LangChain supplies the how inside each step.
A practical migration path: start a project in LangChain to validate the idea quickly. When you find yourself simulating a state machine with nested conditionals and manual retry counters, that complexity is telling you to lift the orchestration into LangGraph and keep your existing chains as nodes. You rarely throw the LangChain work away — you wrap it.
So the honest answer to LangChain vs LangGraph: use LangChain for pipelines, reach for LangGraph the instant you need cycles, branching, or durable state, and expect mature agents to combine them.