LangGraph

Push a chain far enough and developers naturally want more: instead of a fixed sequence, what if the model decided what to do next itself? That's an agent. Instead of answering directly, it reasons about the task, picks an action, executes it, observes the result, and decides what to do next, repeating until the task is done. This loop has a name: ReAct, reasoning and acting.

That loop breaks the assumption a chain depends on. Chains follow a directed acyclic graph: task A leads to task B leads to task C, always forward, never back. An agent's workflow has loops, searching again if the first result wasn't enough, branches, calling a different tool depending on what it finds, and state that needs to persist across many reasoning steps.

A chain literally cannot represent that shape. It is a graph problem, not a sequence problem, which is exactly what LangGraph was built to model directly.

LangGraph represents a workflow as an explicit graph made of two things: nodes and edges. A node is a unit of work, an LLM call, a tool execution, a retrieval step, a plain function. An edge defines how control moves from one node to the next.

The crucial distinction: graph does not mean directed acyclic graph. A DAG only ever moves forward. LangGraph's edges can be conditional, and they can point backward, task D can route back to task A, a decision node can send execution around the same loop again. That's what lets an agent retry, re-plan, or loop until a condition is met.

Multiple nodes can each be their own AI agent, handling one piece of a larger job and handing off to the next, communicating through the graph itself rather than through one monolithic prompt. That's what "multi-agent" means in practice: several focused agents cooperating on a workflow no single call could handle cleanly.

Rather than passing data manually from step to step, LangGraph keeps one shared state object that the entire graph reads from and writes to. A node picks up the current state, does its work, updates it, and passes control forward.

This is what "stateful" means here, and it's a meaningfully more efficient kind of persistent memory than threading context through a chain by hand: any node can see any update any other node made, without every step needing to explicitly forward it along.

It also makes the whole run auditable. Because every node's input and output is just a read and a write to one object, it's possible to inspect exactly what information a given step had, what it changed, and what triggered the next move, which matters enormously once something goes wrong.

That state can also be checkpointed, saved between runs instead of only held in memory during one. That's what lets a long-running agent pause mid-task for a human to approve something risky, a purchase, a sent email, a code change, and resume later exactly where it left off, not just retry the current step from scratch.

Take a research agent answering an open question. It reasons about what it needs (a node), runs a web search (a node), reads the results (a node), then hits a decision point: does it have enough to answer?

If not, the edge out of that decision routes back to the search node with a refined query, exactly the loop a DAG can't express. If it does, the edge routes forward to a final answer node instead.

Nothing here is exotic, it's the same idea as a code review loop, write, review, send back for changes, generalized so that both an automated check and a human-feedback step can be plugged into the graph as their own nodes.