LangChain vs LangGraph vs LlamaIndex Compared

The three frameworks are constantly compared as if they were alternatives to each other, and picking between them on that basis leads to the wrong answer. They sit at different layers. Two of them are maintained by the same team and are designed to be used together. The useful question is not which one wins but which layer the problem lives at.

What Each One Actually Is

LangChain is a composition and integration layer. It provides standard interfaces for chat models, embedding models, vector stores, retrievers, tools, and output parsers, so that swapping a provider is a configuration change rather than a rewrite. On top of those interfaces sits a declarative composition syntax for wiring components into a runnable pipeline that supports batching, streaming, and async execution without extra work. Its centre of gravity is a defined sequence of steps with pluggable parts.

LangGraph is a runtime for stateful, multi-step applications, built by the LangChain team. Instead of a linear pipeline it models the application as a graph: nodes that do work, edges that decide what runs next, and a shared state object that every node reads from and writes to. Its distinguishing features are durable execution with checkpointing, so a run can be paused and resumed rather than restarted; cycles, so a step can genuinely loop back; and human-in-the-loop interrupts, so a run can stop and wait for approval before continuing. It does not replace LangChain’s integrations; it orchestrates them.

LlamaIndex is a data framework for LLM applications, with the centre of gravity on the ingestion and indexing side. Its abstractions are a large and growing catalogue of readers for third-party data sources, node parsers, and multiple index structures beyond a plain vector index: the documentation ships module guides for summary indexes, keyword table indexes, knowledge-graph indexes, and property-graph indexes. Query engines sit on top of those, with routing and composition across several indexes. It also has agent and workflow support, but the depth is in getting heterogeneous data into a queryable form.

Side by Side

	LangChain	LangGraph	LlamaIndex
Primary layer	Component composition and provider integrations	Stateful orchestration runtime	Data ingestion, indexing and query
Core abstraction	Runnable pipeline of chained components	Graph of nodes over a shared state object	Index and query engine over parsed nodes
Control flow	Linear with branches	Cycles, conditional edges, subgraphs	Query engines and routers, plus workflows
State between steps	Passed along the pipeline	Explicit shared state, checkpointed	Held in the index and query context
Resume after failure	Not built in	Durable execution from checkpoints	Not built in
Human approval mid-run	Not built in	Interrupts before or after a node	Not built in
Retrieval depth	Retriever interface, hybrid via ensembles	Inherits LangChain retrievers	Multiple index types, routing, graph retrieval
Ingestion breadth	Loaders for common formats	Not its concern	Large connector catalogue, ingestion pipelines
Observability	LangSmith tracing	LangSmith tracing, plus state inspection	Instrumentation and callback handlers
Best fit	Defined pipelines with swappable providers	Long-running agents, approval gates, loops	Document-heavy retrieval over mixed sources

Choosing by Workload

A defined sequence of steps. Prompt, model call, parse, act. This is a LangChain pipeline and nothing more is warranted. Adding a graph runtime to a five-step linear flow adds a state schema and a mental model without buying anything. The general argument for preferring an explicit sequence over an agent loop is made in LangChain building blocks.

Question answering over a document corpus. Both LangChain and LlamaIndex do this. LangChain is the lighter option when the corpus is homogeneous, the retrieval strategy is a single vector index, and the value is in swapping models and stores freely. LlamaIndex earns its place when the corpus is not homogeneous: many formats, several indexes that need routing between them, or relationships between documents that a flat vector index cannot express. The stage-by-stage mechanics either way are in the RAG pipeline walkthrough.

An agent that runs for minutes, calls tools, and can fail partway. This is LangGraph’s case and the gap is not close. Checkpointed state means a crashed run resumes from the last completed node rather than re-executing every tool call from the start, which matters when those calls cost money or have side effects. Interrupts mean a destructive action can require approval without inventing a bespoke pause mechanism.

Anything a human must approve mid-run. LangGraph, for the same reason. Retrofitting an approval gate into a linear pipeline means splitting it into two applications with persistence bolted between them, which is what LangGraph already is.

A multi-agent system. LangGraph, expressed as subgraphs with explicit handoffs. Supervisor and swarm topologies are patterns over the same primitives rather than separate products.

Using Them Together

The combinations are normal, not exotic.

LangGraph over LangChain components is the intended configuration. The graph decides what runs when; the nodes call LangChain models, retrievers, and tools. There is no adapter layer, because LangGraph was designed against those interfaces.

LlamaIndex for ingestion with LangChain or LangGraph for orchestration is a common split. LlamaIndex has the wider connector catalogue and the richer index structures; the orchestration layer consumes the resulting retriever. This costs a dependency on both projects, which is a real maintenance burden and is only worth it when the ingestion side is genuinely the hard part.

What is not worth doing is using two composition syntaxes for the same flow. Pick one orchestration layer and let the other library do data.

When None of Them Is the Answer

There is a fourth option that the comparison usually omits: calling the model provider’s SDK directly.

For a single prompt with a single model and no retrieval, a framework adds an abstraction layer, a dependency tree, and a version to track, in exchange for very little. The provider SDK already handles streaming, structured output, and tool calling. The break-even point arrives when at least one of these becomes true:

• More than one provider has to be supported, or a provider swap is foreseeable.
• Retrieval is involved, so loaders, splitters, embeddings and a store are all needed.
• The flow has enough steps that composing, batching and tracing them by hand becomes the work.
• State has to survive a failure, or a human has to approve something mid-run.

None of those apply to a summarisation endpoint. All of them apply to a document assistant. Being honest about which situation the project is in avoids inheriting a large abstraction surface for a small problem, and it also avoids the opposite error of hand-rolling a retrieval stack that these frameworks already solved.

Migration Cost, Both Directions

Moving between these layers is not symmetrical.

Going from a LangChain pipeline to a LangGraph graph is the cheap direction, because the components carry over unchanged. The work is defining a state schema and re-expressing the sequence as nodes and edges. The prompts, models, retrievers and tools are the same objects.

Going from LlamaIndex to LangChain, or the reverse, is more expensive, because the data layer is where the divergence is. Index structures, node parsers and query engines have no direct equivalents, and the corpus generally has to be reindexed. That asymmetry is a reason to make the data-layer choice more carefully than the orchestration one, and it is another argument for starting with the simpler orchestration layer and moving up only when a requirement forces it.

Practical Selection Criteria

Beyond capability, three things decide the choice in practice.

Team familiarity. All three have large surface areas and their own idioms. A team already fluent in one will ship faster with it than with a marginally better fit they have to learn, unless the missing capability is structural. Durable execution is structural. A slightly nicer retriever API is not.

Version churn. These projects move fast and have made breaking changes across major versions. Pin versions, read the migration notes before upgrading, and check that the integration packages a project depends on are actively maintained rather than community stubs.

Cost visibility. None of the three make token spend visible by default. An agent that loops five times over a prompt carrying ten retrieved chunks costs far more per run than the same task as a two-step pipeline, and the difference does not appear until the invoice does. The token and agent cost sizer puts a number on step count and prompt size before the architecture is locked in.

The Short Version

LangChain for composing a defined pipeline out of swappable parts. LangGraph when the application needs state that survives a step, loops, or a human in the middle. LlamaIndex when the difficulty is on the data side rather than the control side.

Choosing on control flow requirements rather than on feature lists gets the right answer quickly, because control flow is the thing that is expensive to change later. Retrieval strategy can be swapped in an afternoon. An orchestration model cannot. When an agent built on any of the three starts looping, skipping tools, or failing to parse its own output, the diagnostic path is in LangChain agent errors.