What Is LangGraph? Stateful AI Agent Framework

LangGraph is a Python and JavaScript library for building AI agents as explicit state machines rather than single prompt-response calls. The LangChain team released it in January 2024, and by mid-2026 it had passed 30,000 GitHub stars and become one of the most widely deployed frameworks for putting large language model (LLM) agents into production. Klarna's AI customer support assistant runs on it, handling millions of conversations a month for 85 million active users. LinkedIn, Elastic, AppFolio, and Replit have published similar case studies.

If you've ever built a chatbot that works fine in a demo but falls apart the moment it needs to retry a failed tool call, wait for a human's approval, or remember what happened three steps ago, you've hit the exact problem LangGraph exists to solve. This piece walks through what a "graph-based agent" actually is, how the pieces fit together, why durability matters more than most tutorials admit, and where LangGraph gets replaced by something else entirely.

The problem LangGraph is solving

Ask an LLM a single question and it gives you a single answer. That's a completion, and it's what most people mean when they say "I used ChatGPT." An agent is different: it's a system that takes an action, looks at the result, decides what to do next, and keeps going until the task is done or it gives up. Booking a flight, debugging a failing test, or resolving a customer support ticket usually takes several of these action-observe-decide cycles, not one.

The trouble is that "keep going until done" is a deceptively hard thing to build reliably. A naive agent loop is a while statement wrapped around an LLM call: keep calling the model, keep executing whatever tool it asks for, stop when it says it's finished. That works for a demo video. It falls apart in production for three predictable reasons.

First, state gets messy. As the loop runs longer, you accumulate conversation history, tool outputs, partial results, and user context, all of which need to survive from one iteration to the next without silently corrupting each other. Second, failures are inevitable. The LLM API times out, a tool throws an exception, the process gets killed by a deploy. A while loop has no concept of "resume from where I was" — it just starts over, which means repeated tool calls, duplicate emails sent, and wasted API spend. Third, humans need to intervene. Real workflows pause for approval ("this refund is over $500, get a manager to sign off"), and a bare loop has no natural place to stop, wait indefinitely, and pick back up later.

LangGraph's answer to all three problems is the same idea: model the agent as a graph, not a loop, and treat its execution state as a first-class object that gets checkpointed to a database after every step.

Klarna's LangGraph-powered assistant cut average resolution time from about 11 minutes to under 2, according to LangChain's published case study, while handling the equivalent workload of roughly 700 full-time human support agents in a single month.

How LangGraph models an agent

Every LangGraph program is built from four concepts: nodes, edges, state, and checkpoints. Understanding these four is close to understanding the whole library.

Nodes are ordinary Python (or TypeScript) functions. A node typically calls an LLM, calls a tool, queries a database, or transforms data in some way. Each node receives the current state and returns a partial update to it.

Edges connect nodes and define what runs next. A plain edge always goes from node A to node B. A conditional edge branches based on a function you write — for example, "if the LLM's response contains a tool call, go to the tool-execution node; otherwise, go to the end." Conditional edges are what let an agent make decisions rather than follow a fixed script.

State is a shared object — a TypedDict in Python, an interface in TypeScript — that flows through the whole graph. Every node reads from it and returns updates that get merged back in according to rules you define (overwrite, append to a list, or a custom reducer function). Because state is explicit and typed, you can always inspect exactly what the agent knows at any point in the run, which is a sharp contrast to burying everything in an unstructured conversation string.

Checkpoints are what make the graph durable. Attach a checkpointer (SQLite for local development, Postgres, Redis, or MongoDB for production) and LangGraph saves the full state after every "superstep" — its term for one full pass of node execution. If the process crashes, gets redeployed, or the run needs to pause for a human, the graph can resume from the last saved checkpoint instead of starting over. This is the piece most tutorial-level agent frameworks skip entirely, and it's the single biggest reason companies choose LangGraph for anything customer-facing.

Because the graph structure allows cycles, an agent can loop naturally — call a tool, observe the result, decide to call another tool or a different tool with different arguments, repeat. That's a stark difference from linear pipeline frameworks, which run a fixed sequence of steps once and stop.

A minimal working example

from typing import TypedDict
from langgraph.graph import StateGraph, END

class State(TypedDict):
    question: str
    context: str
    answer: str

def retrieve(state: State) -> dict:
    # hits a vector store — see our RAG explainer for how this works
    return {"context": vector_db.search(state["question"])}

def generate(state: State) -> dict:
    answer = llm.invoke(f"Q: {state['question']}\nContext: {state['context']}")
    return {"answer": answer}

graph = StateGraph(State)
graph.add_node("retrieve", retrieve)
graph.add_node("generate", generate)
graph.set_entry_point("retrieve")
graph.add_edge("retrieve", "generate")
graph.add_edge("generate", END)

app = graph.compile()
result = app.invoke({"question": "What is LangGraph?"})

Two nodes, one edge, and durable execution the moment you attach a checkpointer at compile() time. Add a conditional edge that routes back from generate to retrieve whenever the answer scores low on a confidence check, and this same skeleton becomes a self-correcting retrieval-augmented generation (RAG) agent — a pattern we cover in more depth in our RAG glossary entry.

Why "graph" instead of "chat" or "chain"

Two other mental models compete with LangGraph's graph approach, and it's worth being precise about the difference because it explains a lot of the framework's design choices.

The first is the chat model, used by frameworks like AutoGen, where multiple agents are modeled as participants in a conversation who take turns speaking. This is a natural fit for scenarios that genuinely resemble a group discussion — one agent proposes code, another critiques it, a third writes tests — but it's harder to reason about in production. If something goes wrong three turns into a five-agent conversation, tracing exactly why is closer to reading a chat log than debugging a program.

The second is the linear chain model, the original LangChain abstraction: step one runs, its output feeds step two, which feeds step three, done. Chains are easy to understand and easy to draw, but they can't loop and they can't branch without contorting the code into something unrecognizable. A support agent that needs to retry a failed tool call up to three times before escalating to a human simply doesn't fit a straight line.

A graph splits the difference. Think of it like the difference between a recipe written as a numbered list and a recipe written as a flowchart with a "taste it — if too salty, add water and go back to step 4" branch. The numbered list (a chain) is what you follow when everything goes right. The flowchart (a graph) is what you actually need when it doesn't. LangGraph's structure maps directly onto the flowchart diagram you'd draw on a whiteboard when designing an agent — which is exactly what LangGraph Studio renders as you build.

How does checkpointing actually work?

A checkpointer is a pluggable storage backend — SQLite, Postgres, Redis, or MongoDB — that LangGraph writes the full graph state to after each superstep, tagged with a thread ID. If execution stops for any reason, a new run against the same thread ID reads the last checkpoint and continues from there instead of re-running earlier steps. This is what lets an agent "remember" a conversation across separate API calls and survive a server restart mid-task.

It's worth being precise about what checkpointing does not do, because production teams get burned by this assumption. Checkpoints save state between nodes, not state that changes partway through a single node's execution — if a node itself crashes halfway through a long-running tool call, that in-flight work is lost and the node reruns from its start on resume. Checkpointing also doesn't coordinate multiple processes: if two workers try to resume the same thread ID at once during a distributed failure, LangGraph has no built-in lock to stop both from running simultaneously. Teams running LangGraph at real scale generally pair it with an idempotency layer on any side-effecting tool call (sending an email, charging a card) precisely because of this gap.

LangGraph vs Temporal — durable execution isn't one thing

A comparison that comes up constantly among engineers evaluating LangGraph for production is Temporal, the workflow engine originally built for things like payment processing and order fulfillment pipelines. They sound similar — both promise "durable execution" — but they solve different halves of the same problem.

Temporal is a general-purpose durable execution engine. It guarantees that if a workflow crashes mid-run, it resumes from the exact activity that was in-flight, with strong replay semantics that predate the current wave of AI agents by years. It has no built-in concept of a prompt, a context window, or an LLM's reasoning trace — you'd have to build all of that yourself on top of it.

LangGraph, by contrast, is agent-native. It understands message history, tool calls, and LLM state as first-class citizens, and its companion product LangSmith captures the full reasoning trace of a run — what the model saw, what it decided, and why — which is invaluable when a support agent gives a customer the wrong answer and you need to know exactly what context it was working with. What LangGraph doesn't offer is Temporal's battle-tested guarantees for high-stakes side effects like financial transactions.

In practice, teams running agents that touch real money or infrastructure often use both: LangGraph to model the agent's reasoning and decision graph, Temporal underneath to guarantee that the side-effecting steps (the actual charge, the actual database write) survive crashes with exactly-once semantics. Treating this as an either-or choice is a common mistake; the two tools solve adjacent, not overlapping, problems.

The ecosystem around the library

LangGraph the open-source library (MIT licensed, free) is deliberately small. Everything else the LangChain team sells sits around it:

• LangGraph Platform (formerly LangGraph Cloud) is the managed deployment layer — hosted infrastructure, autoscaling, a task queue, cron scheduling, and one-click deploys for compiled graphs. Pricing in 2026 starts around $35 a month for a base tier, scaling with node executions and team seats on higher tiers.
• LangGraph Studio is a visual debugger that renders your graph as a diagram while it executes, lets you pause a run mid-flight, inspect the current state, and manually edit it before resuming — genuinely useful when you're trying to figure out why an agent took a wrong branch.
• LangSmith is the tracing, evaluation, and monitoring product, shared with LangChain users. Every node execution, every LLM call, every tool result gets logged and is searchable after the fact.
• Checkpointer backends — SQLite for local dev, Postgres, Redis, and MongoDB for production — are interchangeable behind the same interface, so switching from a prototype to a scaled deployment doesn't mean rewriting your graph logic.

None of this ecosystem is required to use LangGraph. Plenty of teams run the open-source library against their own Postgres instance with no LangSmith subscription at all. But the paid tier exists because debugging a multi-step agent without visibility into its reasoning trace is genuinely painful, and LangSmith is the product built to solve exactly that.

Real production use cases

• Customer support agents with multi-step ticket resolution, automatic retries on failed lookups, and a human-in-the-loop step for anything above a dollar threshold or flagged as high-risk. Klarna's is the most-cited public example.
• Self-correcting RAG — retrieve documents, have the model evaluate whether the retrieved context actually answers the question, and loop back with a reformulated query if it doesn't, rather than confidently answering from thin context.
• Multi-step research agents that search, summarize, critique their own summary, and refine before returning a final answer.
• Code-writing and code-fixing agents that plan a change, write it, run the test suite, and loop back to fix failures — a pattern that requires exactly the cyclic, conditional structure a linear chain can't express.
• Long-running workflow automation where a process might legitimately take hours or days between steps (waiting on an external API, waiting on a human), and durability across that gap is the whole point.

Comparison table: agent orchestration frameworks in 2026

Framework	Execution model	Languages	Durable by default	Visual debugging	Best fit
LangGraph	Graph + explicit state	Python, TypeScript	Yes, via checkpointers	LangGraph Studio	Production agents with loops, branches, or human approval steps
CrewAI	Roles + tasks	Python	Limited	Limited	Fast prototypes, content-generation pipelines, non-engineer-friendly setup
AutoGen	Multi-agent chat	Python, .NET	Limited	AutoGen Studio	Conversational multi-agent debate and collaboration patterns
OpenAI Agents SDK	Tools + handoffs	Python, TypeScript	Limited	OpenAI trace UI	Teams fully committed to the OpenAI model stack
LlamaIndex Workflows	Event-driven steps	Python	Yes	LlamaIndex UI	RAG-heavy applications already built on LlamaIndex
Pydantic AI	Typed single-agent	Python	No	Logfire	Type-safety-first Python apps, simpler agent needs
Temporal	Durable workflow engine	Python, Go, Java, TS	Yes, exactly-once	Temporal Web UI	Side effects that must never double-execute (payments, orders)

Table: Agent orchestration and workflow frameworks compared by execution model and production readiness, mid-2026.

LangGraph vs CrewAI

CrewAI's abstraction is friendlier to a smaller engineering team or a less code-heavy background: you define agents with a role, a goal, and a set of tools, and CrewAI handles the coordination underneath. That simplicity is genuinely valuable for content pipelines, research summarization tasks, and prototypes where getting something working in an afternoon matters more than fine control over the execution path.

LangGraph trades that simplicity for explicit control. You write more code, but you can express patterns CrewAI's abstraction doesn't naturally support: arbitrary cyclic graphs, fine-grained conditional routing based on custom logic, and custom checkpointing strategies tuned to your infrastructure. The rule of thumb that holds up in practice: reach for CrewAI when the workflow is genuinely role-shaped (a "writer" and an "editor" working together) and reach for LangGraph when the workflow is genuinely process-shaped (retry, branch, escalate, resume).

LangGraph vs OpenAI Agents SDK

OpenAI's Agents SDK, released in March 2025, shares some surface-level DNA with LangGraph — tools, handoffs between agents, a straightforward Python API — but it's built specifically around OpenAI's Responses API. If your entire stack is already OpenAI models and you don't anticipate needing to swap in Anthropic's Claude, Google's Gemini, or a self-hosted open-weight model, the Agents SDK's simplicity is a real advantage: less code, less abstraction to learn.

LangGraph is provider-agnostic by design — swapping the underlying LLM is a one-line change to which model object a node calls — and its durability guarantees through checkpointing go further than what the Agents SDK offers out of the box. The honest trade-off: pick the OpenAI SDK for simplicity if you're all-in on one provider, pick LangGraph if you want either provider flexibility or production-grade durability, or both.

LangGraph vs LangChain

This confusion comes up in nearly every discussion of the two, so it's worth being blunt: they are separate libraries maintained by the same team, and neither requires the other.

LangChain is a utility library — prompt templates, document loaders, retrievers, output parsers, and integrations with hundreds of model providers and vector databases. It's the toolbox. LangGraph is the orchestration framework that decides in what order, under what conditions, and with what persistence those tools get called. It's the blueprint the toolbox gets used against.

You can build a LangGraph agent that never imports LangChain at all — many production teams do exactly this, calling model APIs directly from inside their nodes. You can also use LangChain's document loaders and retrievers inside LangGraph nodes, which is the more common pattern in practice because it saves you from reimplementing integrations LangChain already has. For a deeper look at LangChain specifically, including where it overlaps and diverges from LlamaIndex's approach to building retrieval pipelines, see our LangChain vs LlamaIndex comparison.

What people get wrong about LangGraph

The most common misconception is treating LangGraph as a replacement for prompt engineering or model selection. It isn't. LangGraph controls when and in what order your LLM gets called; it has no opinion on which model you use or how you write your prompts. A badly prompted agent wrapped in a perfectly designed graph is still a badly prompted agent — the graph just fails more predictably and with better logs.

A second mistake is assuming checkpointing alone makes an agent "safe" for anything involving money or irreversible actions. As covered above, checkpoints protect against crashes between steps, not against a tool call executing twice because two processes raced to resume the same thread, or a node crashing mid-execution after it already sent an email but before it recorded that fact in state. Production-grade agents that touch real-world side effects generally need an idempotency key on every tool that isn't purely a read, independent of whatever the orchestration framework provides.

A third mistake is choosing LangGraph by default because it's popular, then discovering the codebase for a genuinely simple, single-turn RAG pipeline has ballooned into a graph with more nodes and edges than the problem warranted. If a task is fundamentally "retrieve once, generate once, done," a chain or a plain function call is less code, easier to onboard a new engineer onto, and has nothing extra to debug. LangGraph earns its complexity when the task has loops, branches, or needs to survive a crash — not by default.

When to pick LangGraph

Reach for it when your agent is heading to production and reliability genuinely matters, not just for a demo. Reach for it specifically when the workflow has loops, conditional branches, or a human-approval step baked in, since those are exactly the patterns a linear chain can't express cleanly. Reach for it if observability matters to your team — LangSmith's tracing is close to best-in-class for understanding why an agent made the decision it made. And reach for it if you need durable execution: agents that need to resume correctly after a crash, a deploy, or an hours-long pause waiting on a human.

When LangGraph is overkill

Skip it for simple, single-shot LLM calls where there's no multi-step decision to make. Skip it for RAG pipelines that genuinely never loop — retrieve, generate, return, done every time. Skip it if what you actually want is a no-code agent builder for a non-engineering team, since LangGraph assumes you're comfortable writing Python or TypeScript. And skip it if the role-based mental model that CrewAI offers maps more naturally onto how you're already thinking about the problem — forcing a graph onto a task that's genuinely simpler than that is a common way teams over-engineer their first agent project.

Frequently asked questions

Q: Do I need LangChain to use LangGraph? A: No. LangGraph is a standalone library with no dependency on LangChain. Many production teams adopt LangGraph and never import LangChain at all, calling model provider APIs directly from within their graph nodes.

Q: Is LangGraph free? A: Yes, the core library is open source under the MIT license with no usage fees. LangGraph Platform (managed hosting) and LangSmith (tracing and evaluation) are separate commercial products with free tiers and paid plans starting around $35 to $39 a month depending on the tier.

Q: What languages does LangGraph support? A: Python and TypeScript/JavaScript, with feature parity across most of the core API surface as of the 2026 releases.

Q: Who is using LangGraph in production? A: Publicly documented case studies include Klarna's customer support assistant, LinkedIn's internal AI agent platform, Elastic, AppFolio, and Replit. Klarna's is the most detailed public writeup, covering a workload equivalent to roughly 700 human support agents.

Q: What is checkpointing and why does it matter? A: Checkpointing saves the graph's full state to a database (SQLite, Postgres, Redis, or MongoDB) after each step, or "superstep." If the process crashes, gets redeployed, or pauses for human approval, execution can resume from the last checkpoint instead of restarting from scratch. It's the mechanism that makes LangGraph agents "durable" rather than fragile scripts.

Q: Does checkpointing protect against duplicate side effects, like sending an email twice? A: Not by itself. Checkpoints save state between nodes, not mid-node, and LangGraph has no built-in coordination if two processes try to resume the same run simultaneously. Production teams typically add their own idempotency keys on any tool call that isn't purely read-only.

Q: How is LangGraph different from Temporal? A: Temporal is a general-purpose durable execution engine built for guaranteeing side effects (like a payment) happen exactly once, even across crashes, but it has no native concept of prompts or LLM reasoning. LangGraph is agent-native, understanding message history and tool calls as first-class state, but leans on you to add stronger side-effect guarantees for high-stakes actions. Many production teams run both together.

Q: How does LangGraph compare to AutoGen? A: AutoGen models a system as multiple agents taking turns in a conversation, which fits multi-agent debate and collaboration well. LangGraph models a system as an explicit state machine, which fits procedural workflows with retries, branches, and defined stopping conditions better.

Q: Can I use LangGraph without ever writing my own retrieval or vector database code? A: You can pair LangGraph nodes with LangChain's or LlamaIndex's existing retriever integrations rather than writing retrieval from scratch. For the retrieval side specifically, see our explainer on how retrieval-augmented generation works.

Q: Is LangGraph the right choice for a small, single-developer project? A: It can be, if the agent genuinely loops or branches. But for a simple one-shot RAG bot or a single tool-calling assistant with no retry logic, a plain function or a linear chain will be less code to write and debug. LangGraph's value shows up once the workflow gets complex enough that a while loop stops being manageable.

The takeaway

LangGraph's real contribution isn't the graph abstraction itself, since developers have drawn agent flowcharts on whiteboards for years. It's that the library turns that whiteboard diagram into code with the same shape, and then makes the resulting execution durable by default through checkpointing. That combination is what separates a demo agent that impresses in a meeting from one that survives a crash mid-transaction, resumes correctly after a human approves a refund an hour later, and can be traced step by step when it gets something wrong. Companies aren't adopting LangGraph because graphs are trendy; they're adopting it because the alternative, a hand-rolled while loop with no persistence layer, breaks in exactly the ways production software can't afford to.

---

Read next:

• LangChain vs LlamaIndex — LLM Framework Compared
• What is Retrieval-Augmented Generation (RAG)?
• What Is MLX? Apple's ML Framework