What is LangGraph state and how do reducers work?

State in LangGraph is a TypedDict that every node reads and updates. A reducer decides how updates combine: add_messages appends to the message list, a merge reducer combines dicts key by key, and a field with no reducer is overwritten wholesale by every node that returns it. We measured the failure: a results dict with no reducer lost every key except the last write, the workers re-ran, and the handoff cap stopped the loop at 6. Every field needs an explicit reducer decision.

What is the difference between a LangGraph checkpointer and a Store?

A checkpointer saves the graph state at every super-step, organised by thread id, so it holds short-term memory for one conversation or task. A Store is namespaced key-value storage that lives across threads, so it holds long-term memory like user preferences and facts. We stored two facts in an InMemoryStore under one user namespace and read both back from a different thread with no thread config. The checkpointer never sees the Store and the Store never sees the checkpointer.

Does MemorySaver persist state across restarts?

No. MemorySaver keeps checkpoints in process memory and loses everything when the process dies. We verified it: after rebuilding the graph with a fresh MemorySaver, the same thread id returned zero messages. The same test with SqliteSaver on a file returned 4 messages and the full results dict after restart. MemorySaver is for development and tests only; SqliteSaver is the minimum for a single server and PostgresSaver is the production choice.

How do you stop a supervisor loop or handoff ping-pong in LangGraph?

Enforce a handoff cap in the router itself, for example stop after 6 handoffs, and set recursion_limit explicitly on every invoke. In LangGraph 1.2.16 the default recursion limit is 10,007 super-steps, not 25 as older advice says, so an unguarded self-loop ran until our sandbox ran out of 6 GB of memory. With an explicit limit of 25 the same graph raised GraphRecursionError after exactly 25 hops, and with a cap of 5 in the router it finished cleanly in 5 hops.

When should you use a supervisor instead of a single agent?

Use a supervisor when a task splits into independent directions, when workers need different tools or permissions, or when one worker failing should not poison the rest. A single agent with many tools is cheaper and easier to debug and is usually enough. The price of a supervisor is real: Anthropic reports multi-agent systems use roughly 15 times the tokens of a chat interaction, against about 4 times for a single agent, and their Research system gained 90.2% over single-agent Opus 4 on an internal eval, so the pattern pays only when the task genuinely splits.

How do you run LangGraph workers in parallel?

Use Send objects returned from a conditional edge, not from a node: a node returning a list of Send raises InvalidUpdateError in LangGraph 1.2.16. We fanned three workers out with Send and measured a median of 0.306 seconds against 0.904 seconds sequential, about 3 times faster for three 0.3 second workers, with roughly 6 milliseconds of framework overhead. Workers must not write to the same state field without a reducer or their updates collide.

LangGraph Deep: State, Memory, and Multi-Agent Patterns