From be196b00fcde3ad90d741550b524d4e394a1d081 Mon Sep 17 00:00:00 2001 From: Alex Clarke Date: Thu, 10 Sep 2026 14:09:38 -0600 Subject: [PATCH] docs: Improved the formatting of a few of the new graph agent docs --- Graph-Agents.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/Graph-Agents.md b/Graph-Agents.md index 26e7c10..ca4f3a6 100644 --- a/Graph-Agents.md +++ b/Graph-Agents.md @@ -322,8 +322,8 @@ resolved strictly (a missing key fails the node before the child starts, with **Two things are rejected**, both at load time by the validator and again at runtime for graphs running with `validate_before_run: false`. The validator messages below name the node; the runtime guards name the agent instead -(`agent '' has no graph.yaml; …` / `agent '': `inputs.initial_prompt` -is reserved …`) and arrive wrapped in the usual `at node '': Agent '' +(`agent '' has no graph.yaml; ...` / `agent '': `inputs.initial_prompt` +is reserved ...`) and arrive wrapped in the usual `at node '': Agent '' failed:` context, so the node is still recoverable from the error chain. - `inputs:` on a node whose `agent` has a `config.yaml` but no `graph.yaml` @@ -848,7 +848,7 @@ fan_out_subjects: type: map over: "{{subjects}}" # required; template must resolve to a JSON array as: subject # required; bound name inside each sub-branch - branch: research_subject # required; ENTRY node of the per-item chain + branch: research_subject # required; entry node of the per-item chain output_key: finding # optional; state key the chain writes (default "output") collect_into: research_results # required; state key to receive the array of results max_concurrency: 5 # optional; integer or "{{key}}" template @@ -1447,7 +1447,7 @@ validator does not model. The most important of these is the implicit (the raw text, or the extracted object when `output_schema` is set). The binding is **transient**: the executor sets `output` to the completion, renders every `state_updates` template, then puts `output` back to whatever -it was before the node ran — or to `null` if the key did not exist. An +it was before the node ran, or to `null` if the key did not exist. An LLM/agent/rag node therefore **never persists its completion under `output`** on its own. If you want the completion to survive, name a key: @@ -1456,8 +1456,8 @@ state_updates: finding: "{{output}}" ``` -Writing `output` explicitly also works — `state_updates: { output: -"{{output}}" }` leaves `output` equal to the completion — but a named key +Writing `output` explicitly also works (`state_updates: { output: +"{{output}}" }` leaves `output` equal to the completion), but a named key is the recommended pattern, especially for map branches (pair it with the map's `output_key`, see [`map` nodes](#map)). @@ -1469,8 +1469,8 @@ Two consequences of the restore step that bite in parallel super-steps: 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. + `output_key: output` collects `null`. This is yet another 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 @@ -1516,7 +1516,7 @@ merges them via the reducer pipeline. This means: - Branches can freely mutate state **during** the super-step without - stepping on siblings — but every key a branch wrote participates in the + stepping on siblings. But every key a branch wrote participates in the join, including the `output: null` residual an LLM/agent/rag node with `state_updates` leaves behind when `output` was previously absent, so any key written by 2+ branches needs a declared reducer (see @@ -1921,7 +1921,7 @@ This is the developer-facing channel and includes: - Graph start / completion / failure - Per-node entry and routing decisions (`debug`) -- A **performance summary** at completion — every node's visit count, +- A **performance summary** at completion. Every node's visit count, total/avg/max wall-clock time, slowest first: ``` [graph:my-agent] performance summary (slowest first):