How does message passing relate to how nodes update shared state?

What you need to know

1. Plan — decide which nodes run in this super-step, from the edges of the nodes that just finished.
2. Execute — run them, in parallel if several; each sees the same state snapshot.
3. Update — apply all returned updates through each key's reducer.
4. Checkpoint — save the new state and what runs next.
5. Repeat — until no node is scheduled, or an interrupt.

Consequences

• Order is data flow. If B needs A's output, draw an edge A → B. Two nodes in the same step cannot see each other's results.
• messages is not special. It is a channel with add_messages. You can have other message-like channels, such as a private scratchpad for one agent.
• Private channels. A node can have its own input_schema, and graphs can hold keys that only some nodes read, which keeps agents from seeing each other's scratch work.
• Send is the exception. Send("node", payload) starts a node with a custom input instead of the shared state — still delivered by the runtime, not by a direct call.

A real-life example

In an insurance claim graph, check_documents and fraud_score run in parallel after intake. A developer made fraud_score read state["documents_ok"], which check_documents writes. In tests it always saw the old value None, because both ran in the same super-step. The fix was not a sleep or a lock: an edge check_documents → fraud_score, or a join node that runs after both. Thinking "channels and rounds" instead of "function calls" makes this bug obvious.

Follow-up questions to expect

• "Is this like an actor model?" — No. Actors have mailboxes and call each other at any time. LangGraph runs in synchronised rounds over shared, versioned state.
• "How do agents talk in a multi-agent graph?" — Through state keys (a shared messages list or structured artifacts) and Command(goto=...) handoffs; there is still no direct call.
• "Can you watch the messages between nodes?" — Stream with stream_mode="updates": each event is the update one node wrote.