A developer I work with spent three weeks building a customer support agent with LangChain. It worked — until the product team asked for retry logic and conditional routing. He rewrote the entire thing in LangGraph in four days. Both frameworks are made by the same company. They share a name prefix. And that's roughly where the similarities end.
The confusion between LangChain and LangGraph costs teams weeks of wasted effort. I've watched it happen multiple times now. So here's the breakdown I wish existed when I first encountered both.
LangChain has 132,000 GitHub stars and pulls over 5 million downloads per week on PyPI. It's one of the most popular open-source AI projects ever built. LangGraph, by contrast, sits at 24,200 stars with 353 contributors and 240 releases since January 2024.
Here's what those numbers hide: LangGraph is growing faster relative to its age. And as of 2026, it's the officially recommended way to build non-trivial agents within the LangChain ecosystem.
The job market reflects both. LangChain developers earn an average of $109,905 per year in the US, with top earners hitting $150,500. Specialized AI agent skills — the kind you build with LangGraph — command a 20-40% premium on top of base compensation. There are currently 757 open LangChain developer positions on ZipRecruiter alone.
In LangChain's State of Agent Engineering report, 57% of respondents said they have agents running in production. That's not a prototype ecosystem anymore. That's infrastructure.
LangChain is a framework for chaining LLM operations together. Think of it as a pipeline builder. You have a prompt, an LLM call, an output parser, maybe a retriever — and LangChain connects them in sequence.
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
prompt = ChatPromptTemplate.from_template(
"Summarize this document in 3 bullet points: {document}"
)
model = ChatOpenAI(model="gpt-4o")
parser = StrOutputParser()
chain = prompt | model | parser
result = chain.invoke({"document": "Your long document here..."})
That pipe operator (|) is the core idea. Step A feeds into Step B feeds into Step C. It's clean, intuitive, and works great for linear workflows.
LangChain also gives you:
For straightforward tasks — chatbots, document Q&A, RAG, text summarization — LangChain is genuinely excellent. The problem starts when your workflow isn't a straight line.
LangGraph models your workflow as a state machine. Instead of "step A then step B," you define nodes (functions) and edges (transitions), including conditional edges that branch based on the current state.
from langgraph.graph import StateGraph, START, END
from typing import TypedDict
class AgentState(TypedDict):
messages: list
next_action: str
retry_count: int
def analyze(state: AgentState) -> AgentState:
# Analyze the user request
return {"next_action": "search", "messages": state["messages"]}
def search(state: AgentState) -> AgentState:
# Search for relevant information
return {"next_action": "respond", "messages": state["messages"]}
def respond(state: AgentState) -> AgentState:
# Generate final response
return {"next_action": "end", "messages": state["messages"]}
def should_retry(state: AgentState) -> str:
if state["retry_count"] < 3 and state["next_action"] == "retry":
return "analyze"
return "respond"
graph = StateGraph(AgentState)
graph.add_node("analyze", analyze)
graph.add_node("search", search)
graph.add_node("respond", respond)
graph.add_edge(START, "analyze")
graph.add_edge("analyze", "search")
graph.add_conditional_edges("search", should_retry)
graph.add_edge("respond", END)
app = graph.compile()
See the difference? The workflow can loop. It can branch. It can revisit previous states. The should_retry function decides at runtime where to go next — that's impossible with a simple chain.
LangGraph's core features:
Most "LangChain vs LangGraph" articles treat them as competitors. They're not. They're different tools for different problems, built by the same team.
Here's the actual comparison:
| Feature | LangChain | LangGraph |
|---|---|---|
| Workflow Model | Linear chains / simple DAGs | Full graphs with cycles |
| State Management | Implicit (memory modules) | Explicit (typed state dict) |
| Loops | Not supported | First-class support |
| Conditional Routing | Limited (via routers) | Native conditional edges |
| Human-in-the-Loop | Manual implementation | Built-in with interrupts |
| Checkpointing | Not built-in | Automatic persistence |
| Best For | RAG, chatbots, simple pipelines | Multi-agent, complex workflows |
| Learning Curve | Low to moderate | Moderate to high |
| Framework Overhead | ~10ms per query | ~14ms per query |
| Token Efficiency | ~2,400 tokens avg | ~2,030 tokens avg |
| Integrations | 600+ | Inherits from LangChain |
That overhead difference — 10ms vs 14ms — is noise. Your LLM API call takes 500ms to 3 seconds. The 4ms difference is rounding error.
But here's what surprised me: LangGraph is actually more token-efficient. It uses roughly 15% fewer tokens per query than plain LangChain. My guess is that explicit state management avoids redundant context passing that LangChain's chain abstraction sometimes introduces.
This is the part most people miss. LangGraph is built on top of LangChain. It's not a replacement — it's an extension.
You can use LangChain components inside LangGraph nodes. Your LangChain prompts, models, output parsers, and retrievers all work inside a LangGraph workflow. Think of it this way:
In 2026, the recommended LangChain stack (v0.3+) uses LangGraph for any agent that needs state, loops, or multi-step reasoning. The old AgentExecutor class still exists but is effectively deprecated for complex use cases.
Don't overcomplicate things. If your workflow is linear, use LangChain.
Use LangChain when:
Your pipeline goes A → B → C → done. Summarization, translation, simple Q&A — chain them and ship.
You're building a RAG pipeline. Retrieve documents, stuff them into a prompt, get an answer. LangChain's document loaders and text splitters are purpose-built for this.
You need a quick prototype. LangChain gets you from zero to working demo faster than anything else. The pipe syntax is readable, and the 600+ integrations mean you rarely need custom code.
Your team is new to LLM orchestration. The mental model is simpler. Chain = sequence of steps. Most developers grok this immediately.
# Perfect LangChain use case: RAG pipeline
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
retriever = FAISS.load_local("./index", OpenAIEmbeddings()).as_retriever()
prompt = ChatPromptTemplate.from_template(
"Answer based on context:\n{context}\n\nQuestion: {question}"
)
chain = (
{"context": retriever, "question": RunnablePassthrough()}
| prompt
| ChatOpenAI(model="gpt-4o")
)
answer = chain.invoke("What is our refund policy?")
Clean. Simple. Done. Don't drag LangGraph into this.
The moment your workflow needs to make decisions, loop, or manage complex state — switch.
Use LangGraph when:
Your agent needs to retry or self-correct. An LLM generates code, tests it, finds a bug, fixes it, tests again. That's a loop. Chains can't loop.
Multiple agents need to collaborate. A researcher agent finds information, a writer agent drafts content, a reviewer agent provides feedback, the writer revises. That's a multi-agent graph.
You need human oversight. LangGraph's interrupt mechanism lets you pause execution at any node, show the state to a human, let them approve or modify, then resume. This is non-trivial to build from scratch.
The workflow runs for a long time. LangGraph's checkpointing means if your agent crashes at step 47 of 50, it resumes at step 47 — not step 1.
You need conditional routing. "If the user asks about billing, route to the billing agent. If they ask about technical issues, route to the support agent. If it's unclear, ask a clarifying question." That's a graph with conditional edges.
In late 2025, LangGraph introduced the Functional API. This was a big deal and most comparison articles haven't caught up.
Before the Functional API, building a LangGraph workflow meant defining nodes, edges, and state classes. It worked, but it felt like boilerplate for simple cases. The Functional API uses two decorators — @entrypoint and @task — to turn regular Python functions into stateful, durable workflows.
from langgraph.func import entrypoint, task
@task
def research(topic: str) -> str:
# Call an LLM to research the topic
return f"Research findings for {topic}"
@task
def write_draft(research: str) -> str:
# Write a draft based on research
return f"Draft based on: {research}"
@task
def review(draft: str) -> str:
# Review and score the draft
return f"Review of: {draft}"
@entrypoint()
def write_article(topic: str) -> str:
findings = research(topic).result()
draft = write_draft(findings).result()
for attempt in range(3):
feedback = review(draft).result()
if "approved" in feedback.lower():
return draft
draft = write_draft(f"{findings}\nFeedback: {feedback}").result()
return draft
Look at that. Regular Python. A for loop. An if statement. No graph definition, no state class, no edge wiring. But under the hood, you get checkpointing, durability, and all of LangGraph's features.
The Functional API and Graph API use the same runtime, so you can mix them. Use the Functional API for straightforward workflows, the Graph API when you need fine-grained control over state transitions.
This blurs the line between LangChain and LangGraph significantly. The Functional API is almost as simple as writing a chain, but with graph-level capabilities.
Talk is cheap. Here's who's running LangGraph in production and what they built:
LinkedIn built an AI-powered recruiter that automates candidate sourcing, matching, and messaging. Their hierarchical agent system freed human recruiters for high-level strategy. They also built SQL Bot — an internal tool that converts natural language to SQL queries, finds the right tables, writes queries, and fixes errors automatically.
Uber uses LangGraph to orchestrate large-scale code migrations. They structured a network of specialized agents where each step of unit test generation is handled by a dedicated agent.
Replit built their AI coding copilot on LangGraph. It's a multi-agent system with human-in-the-loop capabilities — users can see every action the agent takes, from package installation to file creation.
Elastic uses LangGraph to orchestrate AI agents for real-time threat detection, improving security response times.
AppFolio created a copilot that saves property managers 10+ hours per week, cutting app latency and doubling decision accuracy.
Notice a pattern? Every one of these use cases involves complex, multi-step workflows with branching logic. None of them are simple RAG pipelines. That's the signal.
I'd be dishonest if I didn't mention the problems. Both frameworks have real issues.
Abstraction overload. LangChain has a reputation for wrapping everything in three layers of abstraction. You end up with prompts inside chains inside agents, and when something breaks, you're peeling back layers to find where it went wrong. One developer described it as having the same feature done in three different ways — which is confusion, not flexibility.
Dependency bloat. Installing LangChain pulls in a large number of packages. For a simple chain, you're importing an entire ecosystem. The community package alone has hundreds of integrations you'll never use.
Breaking changes. The API has shifted significantly between versions. Code written six months ago might not work today. This is less of a problem now that v0.3 has stabilized, but the ecosystem's trust was damaged.
Security vulnerabilities. In 2025-2026, multiple CVEs were disclosed. CVE-2025-68664 (CVSS 9.3) was a deserialization bug that leaked API keys and secrets. CVE-2026-34070 (CVSS 7.5) was a path traversal vulnerability. These are serious.
Learning curve. The Graph API requires thinking in nodes and edges. For developers used to sequential code, this is a mental shift. The Functional API helps, but the documentation still leads with the Graph API.
Debugging complexity. When your workflow has 15 nodes and conditional edges, tracing a bug through the graph is harder than tracing a linear chain. LangSmith helps, but it's an extra cost.
Still tied to LangChain. LangGraph inherits LangChain's dependency tree. If you're frustrated with LangChain's bloat, LangGraph doesn't solve that — it adds to it.
SQLite checkpoint vulnerability. CVE-2025-67644 (CVSS 7.3) was an SQL injection bug in LangGraph's SQLite checkpoint implementation. If you're using checkpointing (which is a core feature), this matters.
Here's how I'd think about this if I were starting a new project today:
Step 1: Define your workflow
Draw it on paper. Is it a straight line? LangChain. Does it have branches, loops, or decisions? LangGraph.
Step 2: Count your agents
One agent? LangChain is probably fine. Multiple agents coordinating? LangGraph.
Step 3: Consider state requirements
Do you need to persist state across sessions? Resume from failures? Human approval gates? LangGraph.
Step 4: Assess your team
New to LLM orchestration? Start with LangChain. Learn the basics — prompts, chains, retrievers. Then graduate to LangGraph when you hit LangChain's limits. You won't have to throw away your work because LangGraph uses LangChain components.
| Scenario | Recommendation |
|---|---|
| Simple chatbot with memory | LangChain |
| RAG pipeline for document Q&A | LangChain |
| Text summarization / translation | LangChain |
| Multi-agent customer support | LangGraph |
| Code generation with self-correction | LangGraph |
| Workflow with human approval steps | LangGraph |
| Quick prototype or proof of concept | LangChain (then migrate if needed) |
| Long-running data processing agent | LangGraph |
Step 5: Start simple, migrate later
The best path for most teams: build your first version in LangChain. If you start hitting walls — you need loops, conditional routing, checkpointing, multi-agent coordination — migrate to LangGraph. The migration is incremental because LangGraph wraps LangChain components.
If you want to try both, here's the fastest path:
# Install both
pip install langchain langchain-openai langgraph
# Set your API key
export OPENAI_API_KEY="your-key-here"
Start with a LangChain chain:
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
chain = (
ChatPromptTemplate.from_template("Tell me a joke about {topic}")
| ChatOpenAI(model="gpt-4o")
)
print(chain.invoke({"topic": "Python"}))
Then try LangGraph's Functional API:
from langgraph.func import entrypoint, task
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-4o")
@task
def generate_joke(topic: str) -> str:
return llm.invoke(f"Tell me a joke about {topic}").content
@task
def rate_joke(joke: str) -> str:
return llm.invoke(f"Rate this joke 1-10: {joke}").content
@entrypoint()
def joke_pipeline(topic: str) -> str:
for _ in range(3):
joke = generate_joke(topic).result()
rating = rate_joke(joke).result()
if "8" in rating or "9" in rating or "10" in rating:
return joke
return joke # best we got after 3 tries
Notice how the LangGraph version can loop — generating jokes until it gets a good one. You can't do that with a chain.
Quick sidebar. People often ask about these alternatives.
CrewAI uses a role-based model. You define agents with roles ("researcher," "writer," "reviewer") and they collaborate on tasks. It's faster for prototyping multi-agent systems but gives you less control over the workflow. Think of it as the "convention over configuration" option.
Microsoft's Agent Framework (successor to AutoGen) focuses on conversational collaboration between agents. If you're in a Microsoft ecosystem, it integrates well with Azure services.
LangGraph sits between these in terms of control vs. convenience. More control than CrewAI, more structure than Agent Framework, more integrations than either. Hybrid approaches — using multiple frameworks together — are increasingly common in production.
Here's my take, and I'll be direct about it.
LangChain is overbuilt for most use cases, and LangGraph is underused for the rest.
Most teams I've seen using LangChain don't need LangChain. A simple API call with a prompt template and some string parsing would do the job. They add LangChain because it's popular, not because they need 600 integrations. Then they complain about complexity they opted into voluntarily.
On the other side, teams building complex agent workflows often start with LangChain and struggle. They hack together retry logic, manual state management, and brittle conditional routing — all things LangGraph handles natively. They'd save weeks by starting with the right tool.
My recommendation: if your workflow fits on a napkin as a straight line, skip LangChain entirely and use the LLM SDK directly. OpenAI's SDK, Anthropic's SDK — they're clean, minimal, and you control everything. You don't need a framework to make one API call.
If your workflow fits on a napkin as a graph — with branches, loops, decision points — go straight to LangGraph. Don't pass through LangChain's chain abstraction on the way there.
The Functional API makes this easier than ever. You write normal Python functions, add two decorators, and get durable, stateful, checkpointed execution. That's a genuine improvement over the boilerplate that LangGraph used to require.
The security issues concern me. Two critical CVEs in one year for a framework that's handling API keys and user data is not great. If you're using either framework in production, audit your dependencies, pin your versions, and watch the security advisories.
But here's the bottom line: LangChain and LangGraph are not competing products. They're layers in a stack. Understanding when to use each layer — and when to skip both — is what separates teams that ship from teams that rewrite.