LangChain vs LangGraph: why the chain model ran out of room

AI Agents · By Caleb Sakala · April 9, 2026

Every langchain vs langgraph argument in production traces back to a specific failure mode. Here is one of them. A user asks a customer support bot about a disputed charge. The agent looks up the transaction, then queries a second database for merchant details, and the second call times out. The agent returns a half-formed answer and marks the conversation resolved. No retry. No escalation. No hint in the logs that anything broke.

LangGraph fixes this. That pattern shows up in most langchain vs langgraph arguments once you strip away the feature tables. A specific moment arrives, the chain abstraction runs out of room, and the team either picks a different building block or ships a bot that ghosts its users.

This post walks through that specific moment, and why it keeps happening to teams that picked LangChain first.

The one langchain vs langgraph call the whole argument hinges on

Open any LangChain chain. The core object, a Runnable, pipes together with the | operator:

chain = prompt | llm | output_parser

That pipeline runs left to right, exactly once, with no way back. LangChain's expression language (LCEL) compiles the code into a Directed Acyclic Graph and executes it top-down. Every time.

LangGraph compiles code into a graph too, minus the acyclic part. Nodes can loop back. Edges can be conditional. State persists across hops. Everything else a langchain vs langgraph comparison lists (checkpointers, human-in-the-loop patterns, multi-agent orchestration, time-travel replay) follows from the single fact that a LangGraph graph can contain cycles and a LangChain chain cannot.

Teams whose workflows never need to loop, retry, or branch based on runtime state have already finished this argument. LangChain works. They should ship the chain.

Teams whose workflows need any of those things are in a LangChain migration, whether they realize it yet or not.

Inside a LangChain chain, nothing holds state

A concrete example. Here is a simplified LangChain chain that classifies an email and drafts a reply:

chain = (
    {"email": RunnablePassthrough()}
    | classify_prompt
    | llm
    | parse_category
    | route_to_template
    | llm
    | StrOutputParser()
)
result = chain.invoke({"email": email_text})

LCEL walks this graph top-down. Each step passes its output to the next step. There is no shared scratchpad and no memory across nodes. For route_to_template to see the original email, that data has to be manually threaded through every intermediate step using RunnableLambda or RunnableParallel wrappers.

The same workflow in LangGraph looks structurally different:

class State(TypedDict):
    email: str
    category: str
    draft: str

graph = StateGraph(State)
graph.add_node("classify", classify_node)
graph.add_node("draft", draft_node)
graph.add_node("review", review_node)
graph.add_edge("classify", "draft")
graph.add_conditional_edges(
    "draft",
    lambda s: "review" if s["category"] == "refund" else END
)

In LangGraph, every node has access to the full State. Every node can read and write every field. If review_node decides the draft isn't good enough, it routes back to draft and the graph loops. If classify_node miscategorizes, a verification node can intercept and route to a corrector. Your workflow becomes a graph, and that changes what can sit on top of it.

LangChain teams have shipped workarounds for years. RunnableBranch for conditionals. RunnableWithMessageHistory for memory. Custom AgentExecutors for tool loops, plus a handful of smaller sidecar patches. Each of them works around an abstraction that was designed to execute once and return.

Chains were right for 2022. Loops broke them.

The LangChain team wasn't wrong to start with chains. In 2022 and early 2023, the dominant LLM workflow looked exactly like a DAG: prompt, LLM, parser, done. Retrieval-augmented generation fit the model. Sequential text processing fit the model. The first wave of LLM applications were pipelines.

Agents changed that. An agent behaves as a loop: observe, plan, act, observe again, repeat until done. You can simulate an agent loop inside a LangChain chain using AgentExecutor, but the executor runs as a sealed black box. You cannot inspect its internal state mid-run. You cannot checkpoint it. When a tool call fails partway through, you re-run the whole loop from scratch.

LangGraph promotes the loop to a first-class concept. A graph has nodes, a graph has edges, and one of those edges can point backward. Persistence, human-in-the-loop patterns, multi-agent orchestration, time-travel replay: all of them sit downstream of that one affordance.

LangChain's own team built LangGraph

Most langchain vs langgraph comparisons skip this part. LangGraph came from Harrison Chase and the LangChain team, the same people who shipped LangChain. They pushed LangGraph to 1.0 GA in October 2025 and they wrote it because chains had a ceiling.

The LangChain team's own framing is that chains were correct for RAG and wrong for agents. LangGraph's TypeScript package ships 42,000+ weekly npm downloads as of April 2026, which makes it the most-used TypeScript framework for stateful agents. A more interesting number: LangGraph lives inside the same monorepo as LangChain. A LangGraph node can call LangChain components directly. Migration happens additively.

LangChain tools still run inside LangGraph. LangChain retrievers still run, and so do output parsers and document loaders. What changes is the orchestrator above them. Teams keep their frameworks and swap the thing that decides what runs next.

The state persistence tax nobody quotes

Here is where feature-comparison articles lie by omission. LangGraph's state persistence carries a cost. Every node that runs with a checkpointer enabled writes the full State object to your backing store, whether that store is SQLite for development or PostgreSQL or Redis for production. For a 10-step agent workflow with a 2KB state payload, that adds up to 20KB of writes per run. Run the agent 100,000 times a month, and you are writing 2GB/month in state snapshots alone, before counting the LLM traces or the tool outputs.

At AWS Postgres RDS rates (roughly $0.115/GB-month for gp3 storage, plus IOPS charges), a single heavy agent workflow adds around $15 to $25/month in pure storage. That is a rounding error for one workflow. It becomes real money for twenty. Budget 10-20% infrastructure overhead compared to stateless LangChain chains, higher when workflows involve long-running threads or frequent human interrupts.

That number belongs in every langchain vs langgraph comparison and sits in none of them. LangGraph buys reliability and observability; it costs database rows. Whether the trade works out depends on whether the workflow actually needs cycles, which is the question worth asking before importing either library.

Where LangGraph still breaks in production

Nobody in the Medium-tier comparison posts will tell you this, so here: LangGraph adds a second learning surface on top of LangChain, and the curve is real. Teams new to stateful graph programming write their first three LangGraph agents wrong. They put too much data in State (checkpoints bloat), they forget to handle partial failures (nodes that throw mid-graph leave the checkpoint in an ambiguous state), and they treat conditional edges as if they were function calls instead of graph transitions.

The docs walk you through the happy path. The docs do not walk you through the graph that hangs because two nodes both wrote the same State key in the same step, or the checkpointer that silently dropped updates because no thread_id got passed.

Gartner published a prediction in June 2025 that over 40% of agentic AI projects would be canceled by the end of 2027. That prediction wasn't aimed at LangGraph specifically. The shape of the failure mode matches exactly the shape of a team that picked LangGraph because it sounded like the production-grade answer and then spent six weeks debugging state-ordering bugs they didn't realize they had written.

When langchain vs langgraph is the wrong question entirely

For most teams asking "langchain vs langgraph," the honest answer is neither.

Consider what the choice bets on. Writing agent code means committing to the idea that your product's differentiation lives in the orchestration layer, that your agent graph specifically is something worth owning line by line. True for foundation model companies. True for agent-native products. True for research labs building new kinds of agents. Rarely applicable to the rest of the industry.

Most teams are automating business workflows. Procurement triage. Contract review. These workflows need cycles and human-in-the-loop patterns. They do not need a developer handwriting StateGraph definitions to get them. They need a platform that takes a description of the workflow and constructs the graph automatically, then lets someone edit the steps as objects instead of as code.

Chase Agents takes that approach. Picture a procurement automation that receives a purchase request, calls a pricing API, routes the result through a research step, hands the research to an approval step, then returns the approved result to the original requestor. In LangGraph, that lives as a hand-written StateGraph with nodes, edges, and a carefully scoped State object. In Chase Agents, the same automation gets constructed from a plain description, with action-type routing between steps, explicit input schemas on each node, and conditional edges all set up by the platform. The team writes the business logic for each step (the pricing query, the approval criteria) and the orchestration sits a level higher.

That distinction changes which decision a team makes. "LangChain vs LangGraph" lives at the level of which Python library to import. A more interesting question lives one level up: whether writing agent code is the right use of engineering time at all, or whether the graph belongs to something a level above it.

How the 2026 decision shakes out

Teams already running a LangChain application that works should not rewrite it. LangGraph did not deprecate chains, and the LangChain team's own position treats chains as correct for linear workflows. Chains that never loop do not need a graph.

Teams starting a new agent workflow this year should skip LangChain's agent abstractions entirely and go directly to LangGraph. The team is unified, the migration path only runs one direction (you can call LangChain from LangGraph, not cleanly the other way), and LangChain 1.0's own agent documentation now points teams toward LangGraph for anything beyond a linear chain.

Teams writing any agent code at all should first ask whether they should be. Forty-two thousand weekly npm downloads counts as impressive for a framework that assumes the engineer wants to own the graph. That number is a rounding error compared to the number of teams who will try to build agentic workflows in 2026 and should not be writing StateGraph code to do it. For those teams, the right layer lives above LangGraph. By 2027, the langchain vs langgraph question will feel like asking which JavaScript bundler your CRM uses.