State graphs

1 min read
On trails:AGENTSstep 4/9

A state graph models an agent as nodes that read and write one shared state, joined by edges that decide which node runs next. The loops in this trail (tool useTool useFunction calling gives the model hands: it asks, and code does the work.Opens in a new tab, ReActReActReason, act, observe, repeat: planning, tool use and a loop in one pattern.Opens in a new tab, reflectionReflectionCritique the output before finalizing it: one agent does, another reflects.Opens in a new tab) are all drawn this way, so the shape is worth knowing before the loops.

A state graph: START leads to an agent node, which either calls the tools node and loops back, or ends. Both nodes read from and write to one shared state. START agent node tool call result tools node no tool call: done END read, then write read, then write State messages, plan, counters: one shared snapshot
Nodes never call each other. They share state, and edges pick the next one.

Three parts

The LangGraph docs define the state like this:

A shared data structure that represents the current snapshot of your application.

PartWhat it isIn LangGraph
StateThe shared snapshot, usually a typed dictclass State(TypedDict)
NodeA function: state in, partial update outadd_node
EdgeWhich node runs next, fixed or chosenadd_edge, add_conditional_edges
Table 1: the parts of a state graph

A node returns only what it changed, and the graph merges that into the state. Several edges leaving one node run those nodes in parallel, in the same super-step. A super-step is one pass over the graph, and nodes that run one after another belong to separate ones.

Shaping the state and the edges so a graph stays readable and certain to stop is graph engineeringGraph engineeringDesigning the graph itself: what lives in state, how big a node is, where it loops and where it stops.Opens in a new tab.

Sources