LangChain and LangGraph come from the same company and are usually mentioned in the same breath, and that closeness is precisely why the relationship between them is worth being clear about. They are not two competing ways to build an agent. One is built on the other, and the practical question is rarely which to pick, it is which layer a given piece of work actually belongs to.
LangChain: a harness around a model-and-tools loop
LangChain’s current agent interface reduces to a small idea: an agent is a model plus a harness. The
harness covers everything wrapped around a single call to the model that is not the model itself:
the system prompt, the tool list, and any middleware that inspects or modifies what happens between
one model call and the next. LangChain’s create_agent function builds that harness for the common
case, a loop where the model is given a set of tools, decides which to call, and continues until it
produces a final answer, with the wiring between provider-specific APIs handled for you.
The value of this layer is that most agents fit that shape and do not need to be built from scratch. Swapping the underlying model, adding a tool, or adjusting the system prompt does not require touching the loop that ties them together, because LangChain owns that loop. The cost is that a workflow shaped differently, one with a genuinely fixed sequence of steps where only some of them involve a model, does not fit an interface built around a single model-and-tools loop as naturally.
LangGraph: the runtime underneath, with the loop taken out
LangGraph is described by its own documentation as a low-level tool built for one job, agent orchestration, and that framing is more useful than it first sounds. It provides no built-in notion of a model-and-tools loop at all. Instead it gives you a graph: a set of named steps, edges that say which step follows which, and a shared state object that flows along those edges and that every step can read and update. A step can be a call to a language model, but it does not have to be, it can equally be a database write, a validation function, or a branch that routes based on the state so far.
That generality is the reason LangGraph exists as a separate, lower layer rather than being folded into LangChain’s agent interface. It lets a workflow mix deterministic, ordinary code, the part of the system that should behave exactly the same way every time, with agentic steps where a model is genuinely deciding what happens next, inside a single execution graph. A support workflow might run a deterministic lookup, a model-driven classification, another deterministic policy check, and only then hand off to a model-driven response, as one graph rather than as separate systems stitched together by hand.
LangGraph also supplies infrastructure that a hand-rolled loop tends to reinvent badly: the ability to persist a graph’s state so a long-running task can resume after a failure or a restart instead of starting over, and the ability to pause execution at a defined point for a person to inspect or change the state before it continues, which is what makes human approval before an irreversible step something the framework understands rather than something bolted on with custom code.
Reading the difference in one table
LangChain (create_agent) |
LangGraph | |
|---|---|---|
| What you define | Model, tools, system prompt, middleware | Nodes, edges, and a shared state object |
| Built-in loop shape | One: model calls a tool, sees the result, repeats | None: you define the graph’s shape yourself |
| Best fit | A standard tool-calling agent that needs to ship without custom orchestration | A workflow with steps that are not themselves model calls, or that need persistence and mid-run inspection |
| Relationship | Built on top of LangGraph | Usable standalone, without LangChain, if you do not need its harness |
The practical question this table is meant to answer is not “which is better”, it is “does this task fit inside one model-and-tools loop, or does it need a sequence with real structure”. A task that is genuinely one loop and is forced into a hand-built graph gets more code and more places for a bug to hide, for no benefit. A task with real structure, deterministic steps that must happen in a fixed order, forked into a graph only because it was built using LangChain’s agent interface, usually ends up fighting the interface to express branching it was not designed for.
Where this fits with the rest of the stack
Neither framework changes what a tool call actually is: the mechanism is the same one described in tool calling, and a tool exposed through the Model Context Protocol is callable from either framework exactly like a function defined in the same codebase. What the choice between LangChain and LangGraph changes is how the calls to that mechanism are sequenced, retried, and made resumable, not what happens at the point a tool is actually invoked. Splitting work across more than one agent is a separate decision again, covered in multi-agent orchestration, and is usually the wrong place to start: get one agent’s loop right before deciding a second one earns its coordination cost.
Where LangGraph sits
How this component relates to the rest of the stack. Items without a link are not covered here yet.
Depends on
Must be present for this to run
- Embedding model