From 846c634cb5ffd5f98ef822df022c94a684c10a8d Mon Sep 17 00:00:00 2001 From: Alex Clarke Date: Wed, 9 Sep 2026 20:18:56 -0600 Subject: [PATCH] docs: clarify the null residual for map chains with unrelated state_updates --- Graph-Agents.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Graph-Agents.md b/Graph-Agents.md index c2d2771..5b92a2e 100644 --- a/Graph-Agents.md +++ b/Graph-Agents.md @@ -1345,10 +1345,13 @@ map's `output_key`, see [`map` nodes](#map)). Two consequences of the restore step that bite in parallel super-steps: - A node with **no `state_updates`** writes nothing at all. A map branch - chain that never declares a write to the map's `output_key` therefore - fails the map at run time (the key is removed from each item's fork - before the chain starts, so nothing is inherited), and the validator - warns about it at load time. Always declare what the branch writes. + chain whose nodes declare no `state_updates`/`output_schema` at all + therefore fails the map at run time (the key is removed from each item's + fork before the chain starts, so nothing is inherited), and the validator + warns about it at load time. A chain node whose `state_updates` name + *other* keys leaves `output: null` instead, so a map with the default + `output_key: output` collects `null` — one more reason to always declare + a named `output_key` and write it explicitly. - When `output` was **absent** from state before the super-step, every LLM/agent/rag branch that has `state_updates` leaves `output: null` behind (the restore falls back to `null`). Two or more such branches