LangChain vs LangGraph for Stateful Production Agents

LangChain vs LangGraph for stateful production agents is a question of execution model. LangChain fits a pipeline that moves from input to output, while an explicit LangGraph models a process that branches, loops, persists, and recovers. Start with LangChain’s create_agent, backed by LangGraph’s runtime, and introduce an explicit StateGraph when the workflow needs more control.

Why the LangChain-vs-LangGraph question is really about execution model, not framework preference

The confusion in 2026 begins when engineers treat LangChain and LangGraph as competing foundations. Both come from the same team at LangChain Inc., and they occupy different layers of the same stack. Comparing them as substitutes obscures the question that matters to an AI engineer or ML platform lead. Does the work follow a directed sequence, or must it respond to earlier results and keep track of its progress?

That distinction becomes costly when a sequential abstraction is stretched around a stateful workflow. When teams reach the limits of state management in a chain, they add control logic outside the framework. Approval handling, recovery, and persistence then become custom infrastructure. The eventual choice is often between maintaining those additions and rewriting the orchestration.

How the October 2025 v1.0 release clarified the division of labor between the two libraries

The October 22, 2025 v1.0 release made the relationship explicit. LangChain’s create_agent function runs on LangGraph’s execution engine, making LangGraph the runtime beneath the high-level API. LangChain supplies model abstractions, integrations, and LCEL composition. LangGraph supplies low-level orchestration through StateGraph, cyclic execution, persistence, streaming, and human-in-the-loop support.

This division separates the interface used to build an agent from the machinery that executes it. A team can begin with LangChain’s high-level abstraction without committing to hand-built graph orchestration. It can then introduce an explicit StateGraph when the process demands control that the higher-level interface does not express. The migration path is designed to let teams retain existing chains as they introduce graph orchestration.

What LangChain's DAG model does well and exactly where it runs out

LangChain’s LCEL pipe-operator model, expressed as prompt | model | parser, fits linear, acyclic work. RAG pipelines, document Q&A, summarization, classification, and extraction all fit this shape when their steps are fixed. Chains are fast to build and easy to test in isolation. Their integrations cover LLM clients, document loaders, vector store connectors, and output parsers, while clean tracebacks help locate failures.

A fixed retrieval-and-answer sequence can stay acyclic when it uses fresh facts in place of stored documents. Seltz is one option for supplying a LangChain pipeline with machine-ready, context-engineered content from the live web. In that arrangement, retrieval quality changes the material flowing through the chain.

Chains reach their limit when they need to go back over an earlier result. In chain composition, state passes through mutable dicts and message lists, but the chain needs Python logic outside it to handle conditional behavior. For a mid-session approval step, the chain needs a polling loop and signal mechanism outside it because it has no built-in interruption point. Structured tool-error recovery, including retry, fallback, and halt, also requires custom code. These are limits of acyclic chains, and LangChain’s LangGraph-backed agents support stateful execution.

How LangGraph models a process through state, nodes, edges, and four production primitives

A StateGraph carries state defined by a TypedDict through Python function nodes that are linked by direct and conditional edges. An edge can route execution according to an earlier result or return to a previous part of the graph. The useful comparison is a UNIX pipe versus a finite state machine, because the difference concerns shape.

The production mechanisms are checkpointing, interrupts, time travel, and replay. Checkpointers persist graph state after every node to backends including SQLite, Postgres, Redis, MongoDB, and DynamoDB. That persistence lets a workflow pick up where it left off after a server restart, a closed browser tab, or a multi-day approval cycle. Interrupts pause execution at a named node and expose the current state to a human through Slack, email, or a dashboard. Execution can resume from that point after approval, an edit, or rejection.

Time travel and replay make the saved execution history useful for recovery. Engineers can return to a checkpoint and replay execution. After fixing a failed step, they can continue from the last successful point.

The real cost of adopting LangGraph through learning, infrastructure, and unnecessary complexity

Graph-based thinking takes weeks to internalize. Engineers must learn how to define nodes, edges, conditional branches, and state schemas that work together in one execution model. The resulting control is valuable, but it demands more design work than connecting a prompt, model, and parser. For a genuinely linear RAG pipeline, document classifier, or two-node graph, that work can add more complexity than it removes.

LangGraph provides orchestration primitives, while teams bear the burden of deploying and maintaining the runtime, including a checkpointing backend such as Postgres, Redis, or SQLite. Debugging also gets harder because engineers have to look across graph nodes and saved state to understand what went wrong. LangSmith provides rich tracing, although LangGraph supports OpenTelemetry and built-in state inspection without it. LangSmith can help, though teams can work without it, but they still need enough observability to see what happens in complex execution.

Latency provides another boundary. Both frameworks add orchestration overhead per node, which is negligible for most production work but meaningful on paths with sub-100ms requirements. For those paths, framework convenience must be weighed against the execution budget. Plain SDK calls can be the better answer when orchestration adds no necessary behavior.

A practical decision framework for matching workflow shapes to execution models

The first branch in the decision is whether the work needs orchestration at all. A single LLM call with a single tool call and no orchestration logic can use the OpenAI or Anthropic SDK. Neither framework is the right fit when regulatory or audit requirements conflict with its logging model. The same applies to a non-Python stack when the JS equivalents lack required integrations.

If orchestration is needed but the workflow is strictly sequential, LCEL is the direct fit. This covers fixed RAG, classification, extraction, and summarization flows without branching or looping. A graph with only one or two nodes is another sign that explicit graph construction may be unnecessary. Teams building an agent can start at a high level with create_agent without having to name a StateGraph.

An explicit graph becomes appropriate when the workflow must loop until a condition is met or route according to an earlier result. Persistent state across sessions or restarts, human approval, multi-agent handoffs, and checkpoint-based recovery also point toward StateGraph. Before transitioning, check whether the high-level agent already handles the workflow’s need to branch based on an earlier result. In-memory state cannot take the place of production persistence, and teams can change the abstraction they start with.

How production deployments at Klarna, Uber, LinkedIn, and Elastic illustrate the framework decision in practice

Uber’s Developer Platform team used LangGraph to build productivity tools for thousands of engineers who work on hundreds of millions of lines of code. Validator detects best-practice violations and security issues, while AutoCover automates test generation. Both need conditional routing and a way to coordinate work across steps. Their architectural relevance lies in those requirements rather than in the size of the engineering organization.

LinkedIn deployed a hierarchical LangGraph agent system for AI-powered recruiting. It automates candidate sourcing, matching, and messaging, so agents working together are at the heart of the process. Elastic illustrates a different route to the same execution model. Its AI assistant began with LangChain and moved to LangGraph as features increased its complexity.

These examples support a narrower conclusion than “production requires graphs.” The execution model follows the work.

Where stateful agents meet retrieval through LangGraph orchestration in production RAG stacks

A retrieval agent becomes a process when it evaluates evidence, decides whether to re-query, and routes according to what it finds. A retrieval library can handle document loading, chunking, embedding, and indexing, while LangGraph receives documents through a tool interface and controls execution. This boundary keeps agent state out of the hands of the retrieval infrastructure. It also makes clear that better orchestration cannot compensate for poor evidence.

Query drift shows why the boundary needs care. During iterative retrieval, a model can rewrite a query away from the user’s original intent. A normalization step that anchors the query semantically before it reaches the retrieval API belongs in the graph. It is an orchestration concern because it governs the process’s next action.

Live web content adds variable latency and quality that the agent may need to handle conditionally. Shallow snippets push cleanup work into the agent, while unreliable extraction undermines the information on which resumed execution depends. When a graph uses a web retrieval API such as Seltz, retrieval freshness becomes part of the reliability design. A checkpointer preserves execution state, but it does not make saved web knowledge current.

The security surface that stateful graph execution opens for enterprise teams

Cyera’s coordinated disclosure on March 27, 2026 covered three vulnerabilities across LangChain and LangGraph packages. CVE-2026-34070 is a path traversal vulnerability with CVSS 7.5 that exposes filesystem files. CVE-2025-67644 is a SQL injection vulnerability with CVSS 7.3 that exposes conversation state. CVE-2025-68664, known as “LangGrinch,” is a serialization injection vulnerability with CVSS 9.3 that exposes environment secrets.

A prompt injection payload in a document processed by a RAG-enabled LangGraph agent can trigger serialization injection and expose database credentials. SQL injection can then be used to extract conversation history across agent threads and tenants. The OWASP Top 10 for Agentic Applications 2026 treats memory poisoning, ASI06, and cascading failures, ASI08, as separate risk categories from single-turn prompt injection. Stateful execution thus needs checks that go beyond traditional web application security testing.

CVE-2025-68664 is addressed in langchain-core version 1.2.5 or later for the 1.x line and 0.3.81 or later for the 0.3.x line. Teams must check the versions they have installed and patch them before they go into production. Retrieval needs a review of its own boundary because every external API call, including web search, goes outside the enterprise perimeter. For sensitive B2B data, evaluating a SOC 2-aligned web retrieval API means evaluating that boundary. The evidence here does not establish that Seltz or another retrieval API meets SOC 2 requirements. The checkpoint store, state schema, tool interface, and retrieval calls all belong within the security review of the full execution path.

Making the architectural choice through the process-versus-pipeline distinction

A fixed, acyclic sequence fits LangChain’s chain composition, while branching, cyclic, recoverable work calls for stateful execution. Most non-trivial production agents take the latter shape, but that does not make an explicit graph the required starting point. Use create_agent until the workflow needs the control that a named StateGraph gives it.

That transition brings obligations beyond drawing nodes and edges, including checkpoint infrastructure, observability, security review, and reliable retrieval. The failure to avoid is the gradual accumulation of custom logic outside the framework until the framework stops helping.