LangGraph: stateful, graph-based LLM workflows

Plain LangChain chains are linear: input flows through a sequence of steps, each producing the next input. That works for simple RAG, but breaks for anything with branches, loops, or human intervention.

LangGraph is LangChain's answer: a small graph library where nodes are functions (often LLM calls or tools) and edges are routing rules between them. You define the graph; LangGraph runs it. It handles state, checkpointing, branching, cycles, and human-in-the-loop interruptions out of the box.

If LangChain is "chain together LLM calls", LangGraph is "build a state machine where the transitions are decided by LLMs".

Almost everything in LangGraph is one of:

1. State — a single Python dict (typically a TypedDict) that flows through the graph. Each node receives state and returns updates to it.
2. Nodes — Python functions or LangChain Runnables. They read state, do work, return new state pieces.
3. Edges — connections between nodes. Three flavours: normal edges (always go from A → B), conditional edges (a function chooses the next node based on state), and the special END node (terminates the run).

That's the whole API. Everything else is a recipe on top.

A two-node graph that asks an LLM, then conditionally calls a tool:

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

class State(TypedDict):
    messages: list
    needs_search: bool

def think(state: State) -> dict:
    reply = llm.invoke(state["messages"])
    return {"messages": state["messages"] + [reply], "needs_search": "search:" in reply.content}

def search(state: State) -> dict:
    results = web_search(state["messages"][-1].content)
    return {"messages": state["messages"] + [results]}

g = StateGraph(State)
g.add_node("think", think)
g.add_node("search", search)
g.set_entry_point("think")
g.add_conditional_edges("think", lambda s: "search" if s["needs_search"] else END)
g.add_edge("search", "think")
app = g.compile()

think decides whether to search. If yes, the graph cycles back through search and into think again. If no, it terminates.

Two nodes, one cycle, one terminal edge.

A subtle but important detail: nodes don't replace state, they update it. When a node returns {"messages": [...]}, LangGraph applies a reducer to merge the update with existing state.

The default reducer is overwrite. For lists, you typically want concatenation, which you declare with the add_messages reducer:

from langgraph.graph.message import add_messages
from typing import Annotated

class State(TypedDict):
    messages: Annotated[list, add_messages]

Now every node that returns {"messages": [new_msg]} appends rather than replaces. This is the LangChain-y idiom and worth getting right early — wrong reducer semantics is the #1 source of "why did my history disappear?" bugs.

LangGraph can persist state after every step. Pass a checkpointer when you compile:

from langgraph.checkpoint.sqlite import SqliteSaver

app = g.compile(checkpointer=SqliteSaver.from_conn_string("checkpoints.db"))
result = app.invoke({"messages": [...]}, config={"configurable": {"thread_id": "abc123"}})

This is how you get:

• Resumable conversations — close the tab, come back, pick up the same thread_id.
• Time travel — inspect or replay any prior step in the run.
• Human-in-the-loop — pause at a node, wait for human input, resume.

For production, swap SqliteSaver for PostgresSaver. Same API.

LangGraph's killer feature is its built-in handling of pauses for human review. Mark a node as interrupt_before:

app = g.compile(checkpointer=..., interrupt_before=["send_email"])

When the graph reaches send_email, execution stops. State is checkpointed. Your UI shows the user what's about to happen. The user approves; you call app.invoke(None, config=...) to resume, or modify state first to change the proposal.

This pattern works for any sensitive operation — approving a refund, posting to a public channel, deploying a config change. The graph guarantees the dangerous step doesn't run until you explicitly continue.

Reach for LangGraph when you have:

• Real branching logic the LLM decides on
• Cycles ("keep refining until this condition")
• A multi-step process where you need to pause for human approval
• State that must persist across sessions
• Multi-agent coordination with explicit handoffs

Don't reach for it when you have:

• A linear RAG pipeline (use a plain LangChain chain or just raw API calls)
• A single-shot prompt with structured output (use the SDK directly)
• A short tool-using agent (the SDK's built-in agent loop is fine)

LangGraph adds dependencies, a learning curve, and a state-machine mental model. It's worth it for genuinely graph-shaped problems. For 80% of LLM apps, it's the wrong abstraction.