Why do LangGraph state fields need reducers?

Flashcard·Easy·4.0 · 0·~30s·Asked atMicrosoft Cursor Perplexity

Attempt it

The rule: any state field that should ACCUMULATE across nodes, or that two nodes might write in the same superstep, needs a reducer. The reducer tells LangGraph how to merge the new value into the existing one (e.g. add_messages appends, operator.add concatenates lists, a custom reducer can merge dicts). Fields with no reducer use last write wins overwrite semantics. What goes wrong if you skip it: (1) on a chat history list, every node that returns {'messages': [new_msg]} REPLACES the entire history with just [new_msg]. Past turns are lost; (2) on parallel nodes (two branches running in the same superstep), the writes race and only one survives silently. The reducer is what turns 'state' from a mutable slot into a CRDT-style accumulator that survives branching and parallelism.

Your answer

A LangGraph state schema is a TypedDict that declares the fields shared across all nodes in the graph. Each node reads the current state and returns a partial update. A dict containing only the fields it wants to change. LangGraph needs a rule for how to merge that partial update into the running state. The default rule is overwrite: the returned value replaces whatever was there. That works fine for fields like a flag (`is_done: bool`) or the latest user query. It does not work for fields that should accumulate. The canonical example is chat history. If you declare `messages: list[BaseMessage]` and a node returns `{'messages': [new_msg]}`, the overwrite rule replaces the entire history with just `[new_msg]`. Every previous turn is lost. The fix is to declare the field with a reducer using Python's `Annotated` type: `messages: Annotated[list[BaseMessage], add_messages]`. The `add_messages` reducer appends the new message to the existing list instead of replacing it. Other reducers exist: `operator.add` concatenates lists, and you can write a custom function to merge dicts or do any other accumulation logic. Reducers are also what make parallel nodes safe. When two branches return updates for the same field in the same superstep, the reducer merges both writes instead of letting one silently win.

LangGraph state updates use last write wins overwrite semantics by default. A reducer overrides that with custom merge logic, declared via Python's `Annotated` type on the field. **The rule.** Any state field that should accumulate across nodes, or that two parallel nodes might write in the same superstep, needs a reducer. Fields that legitimately represent the latest value (a current step name, a cached prediction, a boolean flag) can use the default overwrite. **The canonical example.** `messages: Annotated[list[BaseMessage], add_messages]` tells LangGraph to append rather than overwrite. The built-in `add_messages` reducer also de-duplicates by message ID and handles message-updates intelligently. Without the annotation, `messages: list[BaseMessage]` would overwrite on every node return, destroying chat history. **What goes wrong without one.** Two failure modes. First, on sequential nodes, every node that touches the field replaces the running value. You debug a chat where the model only ever sees the latest message because everything before was wiped. Second, on parallel nodes (two branches running in the same superstep), the writes race and one wins silently. No error, just lost work. Reducers are what turn LangGraph state from a mutable slot into a CRDT-style accumulator that survives branching, parallelism, and checkpoint replay.

Quick reference

TL;DR

Any LangGraph state field that should accumulate or that parallel nodes might write in one superstep needs a reducer; without one, last write wins overwrite silently drops history.

Memory aid

Easy to grasp

Picture a shared whiteboard during a brainstorming meeting. By default, when someone walks up and writes on a section, they wipe whatever was there and write their own line. That works for a status field that just shows the latest temperature. It fails badly for the section where everyone is supposed to add an idea. You would end up with only the last person's idea on the board. The fix is a rule per section that says 'add to this section, do not replace it.' That rule is the reducer.

Key concepts

LLM frameworks Agents

Detailed answer & concept explanation

~5 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Quick scan · 2–4 min

Everything important, quickly.

5 minutes: the default overwrite rule, the Annotated reducer syntax, what add_messages actually does, and why parallel branches break without reducers.

Code example

python

from typing import Annotated
from typing_extensions import TypedDict
from langgraph.graph.message import add_messages
from langchain_core.messages import BaseMessage
import operator

class State(TypedDict):
    # Chat history: needs append-semantics, de-duplication by ID
    messages: Annotated[list[BaseMessage], add_messages]

    # Retrieved docs accumulated across parallel retriever nodes
    docs: Annotated[list[dict], operator.add]

    # Latest value wins: no reducer needed
    current_step: str

    # Custom reducer for merging partial worker outputs
    worker_results: Annotated[dict, lambda a, b: {**a, **b}]

Side-by-side

Field shape	Reducer	Why
Chat history	`add_messages`	Append + de-dup by message ID
Accumulating list	`operator.add`	Concatenate lists across nodes
Merging dicts	Custom lambda or function	Spread-merge keys from parallel writers
Latest status / flag	No reducer (overwrite)	Last write reflects current truth
Counter	Custom `lambda a, b: a + b`	Sum increments from parallel branches

Real-world examples

Real products, models, and research that use this idea.

LangGraph's official chat tutorial uses `Annotated[list, add_messages]` as the canonical pattern; every LangGraph chat example you read uses this shape.
LangChain's `create_react_agent` builds its state on top of `MessagesState`, which is a pre-built TypedDict with the `add_messages` reducer baked in.
Production LangGraph deployments commonly write custom reducers to merge structured outputs from parallel worker branches. E.g. accumulating retrieval results from three retriever nodes that all run in the same superstep.
The Send API for dynamic fan-out (`Send('worker', payload)`) is one of the most common sources of parallel writes and depends on reducers to merge worker results into shared state.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you write a custom reducer to merge ranked retrieval results from three parallel retriever nodes?

QWhat does `add_messages` do that `operator.add` does not?

QHow do reducers interact with LangGraph's checkpointer when a superstep is replayed?

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Declaring `messages: list[BaseMessage]` without `Annotated[..., add_messages]` and then debugging why chat history disappears after every node return.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.