LangChain vs LangGraph: which to choose and when

LangChain is a library of components for building LLM applications. LangGraph is an orchestration layer from the same team for running stateful, looping agent workflows. Choose LangChain when the flow is linear, and LangGraph when the flow has cycles, must pause for a human approval, or must survive a crash mid-task. Most production systems use both.

This comparison covers what each library actually does, a dimension-by-dimension table, the situations where each clearly wins, the hybrid that most teams land on, a four-step test you can run against your own design, and what it costs to reverse the decision if you get it wrong.

What LangChain actually is

LangChain is a set of composable building blocks: model wrappers, prompt templates, output parsers, document loaders, text splitters, retrievers, vector store clients and tool definitions, plus the expression syntax that pipes them together. Its value is breadth. If you need to read PDFs from object storage, chunk them, embed them, store them and query them behind three different model providers, LangChain has an adapter for nearly every piece and a consistent interface across them.

Its model of control flow is a pipeline. Input goes in one end, passes through a sequence of steps, and a result comes out the other. Branching is possible, and the framework supports agent loops, but the mental model is a chain: a directed sequence with a beginning and an end. That is exactly right for retrieval question answering, summarisation, extraction, classification and the large family of tasks that are one pass over one input.

What LangGraph actually is

LangGraph models an application as a graph of nodes and edges with an explicit shared state object. Each node is a function that reads the state, does something, and returns an update. Edges, including conditional ones, decide where control goes next, and cycles are first-class rather than an escape hatch. The state is checkpointed, so a run can be paused, inspected, resumed, replayed from an earlier point, or picked up after a process dies.

That design exists to solve the problems that appear when an agent runs for more than one turn: retries that do not lose context, a human approval step in the middle of a long task, a supervisor that routes work to specialist workers, and a durable record of what the system decided and why. The LangGraph documentation describes it as a low-level orchestration framework for stateful agents with durable execution and human-in-the-loop support, which is a fair summary of the difference.

LangChain vs LangGraph: a side-by-side

When LangChain is the right choice

Pick LangChain alone when the job is one pass over one input and the interesting work is retrieval quality, not orchestration. A support answer bot over your documentation, an extraction pipeline that turns invoices into structured rows, a summariser for meeting transcripts, a classifier that routes tickets: all of these are chains. Adding a graph runtime to them buys you state you do not need and a design meeting you do not need to hold.

It is also the right choice for the exploratory phase of almost any project. During a three-week ProofRun the question is whether the model can do the task at acceptable accuracy, and the fastest path to that answer is a short chain over real documents with an evaluation set behind it. Orchestration decisions made before you know the accuracy ceiling are usually wasted. If the answer quality is not there on a hundred real questions, no graph will rescue it, and if it is there, you have earned the right to argue about runtime.

When LangGraph is the right choice

Pick LangGraph when any of four things are true: the flow loops until a condition is met, a person must approve something in the middle, a run may last longer than a single request and must survive a restart, or several specialised agents coordinate under a supervisor. Refund handling, claims triage, onboarding journeys, research agents and code-modification agents all hit at least two of those. Trying to hold that state in a chain means inventing your own checkpointing, which is how teams accidentally write a worse version of LangGraph.

The planner, worker and reviewer shapes we use most often map onto graph nodes almost one to one. Multi-agent systems explained covers those patterns in detail, and the orchestrator entry defines the component that owns routing between them.

The case where the answer is both

In most production systems it is both, and the split is clean. LangGraph owns the shape of the work: which step runs next, what state persists, where a human approves, how a failure resumes. LangChain components sit inside the nodes: the retriever, the splitter, the vector store client, the provider wrapper. Nothing about LangGraph asks you to abandon the integrations, and nothing about LangChain gives you durable execution. Teams that argue about which to adopt are usually arguing about two different layers of the same stack.

How to choose in four steps

• Draw the happy path. If it is a straight line with no waiting, you need a chain. If your pen goes backwards, you need a graph.
• Count the pauses. Any step where a human approves, a callback arrives, or you wait on a slow external system is a checkpoint, and checkpoints want LangGraph.
• Ask what happens on a crash at step four. If rerunning from step one is acceptable and cheap, a chain is fine. If it re-charges a customer or re-sends an email, it is not.
• Check how many agents there are. One agent with tools is comfortable in either. Three agents with a supervisor is a graph.
• Then check the team. A team that has never run an evaluation suite should ship a chain first and earn the graph.

What it costs to change your mind

Moving from LangChain to LangGraph is the cheap direction. The components survive intact; what you write is the state schema and the node boundaries around code that already exists. For a system with three or four steps, budget one to two weeks of engineering plus a re-run of the evaluation suite, and expect the state design to surface bugs that the chain was quietly hiding. That surfacing is worth the cost on its own.

The other direction is rarer and harder, because anything that relied on checkpointing, interrupts or replay has to be rebuilt or dropped. If you suspect you over-engineered, the honest fix is usually to simplify the graph to a handful of nodes rather than to migrate off it. The LangGraph versus custom versus workflow engines comparison is the one to read if you are also weighing Temporal or a home-grown runner against both of these.

Where neither is the right choice

If your workflow is deterministic and rule-based, neither library earns its place. A scheduled job that moves rows between systems is a script, and wrapping it in an agent framework adds latency, cost and a failure mode. We say no to this regularly, and the AI agent versus chatbot comparison sets out the test we apply before recommending either.

Neither library solves the problems that actually sink agent projects: no evaluation set, no observability, and no gate between the model and a consequential action. A graph with a clean state schema and no evaluation suite will fail in production exactly as fast as a chain with none. Build the evaluation first, whichever runtime you choose, and put tracing in on day one.

What this looks like in a build

In our work the pattern is consistent: LangChain components for retrieval and document handling, LangGraph for anything that acts on your systems, an evaluation suite before either, and shadow mode before autonomy. A multi-agent system of that shape starts at $24,500 or ₹16,00,000 and runs to $84,000 or ₹56,00,000 depending on the number of tools and gates, with a three-week ProofRun at $6,250 or ₹4,00,000 available first if you want the hardest step proven before committing. Starting prices are published on the pricing page, and the AI add-on to a care plan at $750 or ₹40,000 a month covers evaluations, prompt regression and cost monitoring after launch.

Related reading

Our comparison hub collects the other decisions that sit next to this one, LLM observability explains the tracing you need regardless of framework, and the in-app copilot case study shows what a graph-shaped agent looks like once it is live inside a product.

Choose LangChain for the pieces and LangGraph for the shape; the argument only looks binary from outside a production system.