Short answer: Use LangChain when you need to build an agent fast with standard tool-calling. Use LangGraph when you need loops, durable state, human approval steps, or multiple agents coordinating. Most production teams in 2026 use both, because LangChain agents already run on the LangGraph runtime underneath.
That one paragraph settles the question for about 80% of readers. The remaining 20% — the people who have to actually ship and maintain the thing — need the details. This guide is for them.
What is LangChain?
LangChain is an open-source framework for building applications on top of large language models. It launched in late 2022 to solve a boring but expensive problem: every team was rewriting the same boilerplate for prompt templates, model calls, conversation memory, and vector store connections.
Its value today sits in two places:
The integration layer. Hundreds of provider integrations — chat models, embedding models, vector stores, document loaders, search tools — behind one consistent interface. Swapping OpenAI for Anthropic or Qdrant for pgvector is a config change, not a rewrite.
The agent abstraction. Since the 1.0 release in October 2025, the headline API is create_agent, a single function that builds a working tool-calling agent. Around it sits a middleware system for the things every real agent eventually needs: conversation summarization, PII redaction, human-in-the-loop approval gates.
The mental model is a pipeline. Data enters at one end, passes through composed steps, and comes out the other. Clean, readable, and predictable.
What is LangGraph?
LangGraph is a lower-level orchestration framework and runtime from the same team, also at 1.0 since October 2025. Instead of a pipeline, you describe your application as a state machine: nodes are units of work, edges are transitions between them, and a shared state object flows through the whole thing.
The critical difference is that a graph can contain cycles. A node can route back to a previous node. That single capability is what separates a workflow from an agent — an agent needs to be able to think, act, observe the result, and think again, an unknown number of times, until it decides it is done.
LangGraph adds three things a linear chain fundamentally cannot provide:
Durable state. A checkpointer persists the full execution state after every step. If the process crashes, a user closes the tab, or three days pass, the graph resumes from exactly where it stopped — not from a replayed message history, but from real execution state.
Interruption. You can pause a graph mid-run, surface the pending action to a human for approval or editing, and resume. This is table stakes for anything that spends money, sends email, or writes to a production database.
Time-travel debugging. Because every step is checkpointed, you can rewind to any point, change the state, and fork execution down a different path. For debugging agents and for compliance audit trails, this is the feature that wins arguments with your security team.
The core architectural difference
LangChain thinks in pipelines. LangGraph thinks in state machines. Everything else follows from that.
A chain is a directed acyclic graph — it always moves forward. Perfect for retrieval-augmented generation: embed the query, search the vector store, stuff the context into a prompt, call the model, return the answer. Five steps, one direction, done.
An agent is a cyclic graph — it loops until a condition is met. The model decides to call a tool, the tool returns a result, the model reconsiders, maybe calls another tool, maybe calls the same tool with different arguments, and eventually produces a final answer. You cannot express that as a straight line, which is exactly why LangGraph exists.
Once you internalize this, the decision stops being about brand preference and starts being about control flow. Does your problem have a loop in it? If no, a chain is simpler and you should use one. If yes, you need a graph — the only question is whether LangChain's prebuilt agent loop is enough, or whether you need to draw the graph yourself.
Side-by-side comparison
Abstraction level. LangChain is high-level and opinionated. LangGraph is low-level and explicit.
Control flow. LangChain composes linear sequences plus a prebuilt agent loop. LangGraph gives you arbitrary nodes, conditional edges, and cycles you define.
State. LangChain manages messages and scratchpad state for you. LangGraph makes state an explicit typed schema you own and can inspect at every step.
Persistence. LangChain stores chat history. LangGraph checkpoints complete execution state, enabling multi-day resume and forked replay.
Human-in-the-loop. LangChain offers it as middleware on tool calls. LangGraph offers native interrupts at any node.
Multi-agent. LangChain handles single agents well. LangGraph is purpose-built for supervisor patterns, agent handoffs, and shared state across agents.
Learning curve. LangChain: hours. LangGraph: days, because you have to think about state design before you write a node.
Best for. LangChain: RAG systems, chatbots, document pipelines, single-purpose assistants. LangGraph: long-running agents, approval workflows, regulated environments, multi-agent orchestration.
Ideal team stage. LangChain: prototype to early production. LangGraph: production systems where failure has a cost.
The same task, built both ways
Here is a research agent that searches the web and answers a question.
With LangChain:
python from langchain.agents import create_agent from langchain_tavily import TavilySearch
agent = create_agent( model="anthropic:claude-sonnet-4-5", tools=[TavilySearch(max_results=3)], system_prompt="You are a research assistant. Cite your sources.", )
result = agent.invoke({ "messages": [{"role": "user", "content": "What changed in EU AI Act enforcement this year?"}] }) print(result["messages"][-1].content)
Nine lines. The loop, the tool dispatch, and the message state are handled for you.
With LangGraph:
python from typing import Annotated, TypedDict from langgraph.graph import StateGraph, START, END from langgraph.graph.message import add_messages from langgraph.prebuilt import ToolNode from langchain.chat_models import init_chat_model from langchain_tavily import TavilySearch
class State(TypedDict): messages: Annotated[list, add_messages]
tools = [TavilySearch(max_results=3)] model = init_chat_model("anthropic:claude-sonnet-4-5").bind_tools(tools)
def call_model(state: State): return {"messages": [model.invoke(state["messages"])]}
def should_continue(state: State): return "tools" if state["messages"][-1].tool_calls else END
builder = StateGraph(State) builder.add_node("model", call_model) builder.add_node("tools", ToolNode(tools)) builder.add_edge(START, "model") builder.add_conditional_edges("model", should_continue, ["tools", END]) builder.add_edge("tools", "model")
graph = builder.compile()
Three times the code for the same behaviour. That looks like a bad trade — until you need to insert a budget check before every search, cap the loop at four iterations, pause for human approval when a source is paywalled, or persist state so the user can return tomorrow. In LangChain you would be fighting the abstraction. In LangGraph you add a node.
That is the whole trade-off in one sentence: LangChain hides the loop, LangGraph hands you the loop.
When to use LangChain
Reach for LangChain — and stay there — when:
You are building a RAG chatbot over your own documents, where the flow is retrieve, then answer.
You need fast time-to-demo. A stakeholder wants to see something working this week.
Your agent does standard tool calling with no custom routing — call tools until done, then answer.
You are evaluating models or vendors and want the integration layer to absorb the churn.
Your control flow has no branches you care about inspecting. If you never need to ask "why did it do that at step 3?", you do not need an explicit graph.
When to use LangGraph
Move to LangGraph when any one of these is true:
State must survive. A user starts a task, closes the browser, and returns three days later expecting to continue. Chat history is not enough — you need execution state.
A human must approve something. Refunds, outbound emails, code merges, database writes, medical or legal drafts. Anything where a wrong autonomous action is expensive.
Multiple agents must coordinate. A supervisor routing to specialists, agents handing work to each other, or parallel agents merging results into shared state.
You need conditional retry logic. Not "retry the API call" — that is a library concern — but "if validation fails, route back to the planner with the error attached and try a different approach."
You are in a regulated industry. Checkpoint history gives you a complete, replayable record of every decision the system made. Try producing that from a chain after the fact.
Loops need bounds. Any autonomous agent will eventually loop forever on a hard task. Explicit graphs let you cap iterations, degrade gracefully, and escalate.
The real answer: you use both
The most common mistake in 2026 is treating this as an either/or. It is not, and the frameworks themselves make that clear: LangChain agents are built on LangGraph. When you call create_agent, you get a compiled LangGraph graph back. You are already using LangGraph; you just are not looking at it.
This makes the migration path unusually gentle. Because graphs are composable, an agent created with create_agent can be dropped into a custom LangGraph workflow as a single node. You do not rewrite — you wrap.
The pattern that works in production looks like this:
LangChain provides the model integrations, the tool definitions, the retrievers, and the individual agent logic. It is what each agent knows how to do.
LangGraph provides the orchestration, the state schema, the checkpointer, the approval gates, and the routing between agents. It is how the system holds together.
A useful framing: LangChain is what each worker can do; LangGraph is the org chart, the handoff protocol, and the audit log.
What about performance and cost?
The orchestration overhead of LangGraph is real but small — milliseconds per step, against model latency measured in hundreds of milliseconds to seconds. In practice, your model provider, your prompt length, and your retrieval strategy dominate the cost and latency profile. Framework choice is noise by comparison.
Where LangGraph does change the economics is on long-running conversations. Because state is managed explicitly rather than by replaying an ever-growing message history, token cost stays roughly flat as a session grows instead of climbing with every turn. On a multi-hour agent session, that difference is not noise.
Optimize your retrieval and your context window first. Do not choose a framework on benchmark milliseconds.
Alternatives worth knowing
A senior recommendation names the competition:
PydanticAI — the cleanest option for simple, type-safe agents where you want end-to-end validation and minimal abstraction.
OpenAI Agents SDK — strong if you are committed to OpenAI and want managed state with minimal infrastructure.
CrewAI — role-based multi-agent teams with a gentler on-ramp than LangGraph, at the cost of control.
No framework at all — a while loop, a tool dispatcher, and a JSON schema. For a narrow agent with three tools, this is often the correct engineering decision, and it is worth saying out loud.
Frequently asked questions
Is LangGraph replacing LangChain?
No. LangGraph is the runtime layer beneath LangChain's agent abstraction. Both reached 1.0 in October 2025 with a commitment to stability, and both are actively maintained by the same team at LangChain Inc.
Can I use LangGraph without LangChain?
Technically yes — LangGraph's core is framework-agnostic orchestration. In practice almost nobody does, because you would be rewriting model and tool integrations that LangChain already provides.
Should I migrate an existing LangChain app to LangGraph?
Only if you are hitting a specific wall: you need durable state, human approval, multi-agent coordination, or custom retry routing. Migrating a working RAG pipeline that has none of those problems is a waste of a sprint.
Which is better for a beginner?
Start with LangChain and create_agent. Build something that works. Then rebuild it as an explicit StateGraph — the architectural difference only really lands once you have felt both.
Which one do employers ask about?
Both, and the question is usually a proxy for whether you understand cyclic versus acyclic control flow. Answer that and you have answered the interview question.
Do I need LangGraph for RAG?
Not for classic RAG. You need it for agentic RAG, where the system evaluates retrieval quality and decides to search again with a reformulated query. That loop is a graph.
The bottom line
The question was never "LangChain or LangGraph?" It is: is the prebuilt agent loop sufficient, or do I need to see and control every transition?
Start with create_agent. Ship it. The moment you need to intercept state mid-execution, insert a human, cap a loop, or coordinate a second agent, drop to an explicit StateGraph. That is not a workaround or an admission of failure — it is the intended path, and the frameworks were designed so the drop costs you a wrapper, not a rewrite.
Build the simple thing first. Add the graph when the problem earns it.