WORKFLOW AGENTS · SHARED STATE
Workflow inspection: states, workers and intermediate data
Two parallel researchers write findings into shared session state; see which findings survive to the report step.
Your experiment
Researcher A finds three issues in a supplier’s filings and researcher B two in news coverage; a report step then reads session state. Start with both branches writing the same key, then try distinct keys, read-append-write, sequential execution and the other finishing order.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Teaching model of shared session state in a parallel workflow, in the spirit of ADK workflow agents with output keys; it is not the ADK API. In parallel mode both branches read state when they start and write when they finish; there is no locking or compare-and-set. No model runs.
Two branches, one key
A parallel step runs two researchers. A finds three issues in a supplier’s filings and B finds two in news coverage; a report step then reads session state. In the opening run both write state["findings"] and replace its value. A finishes first, then B overwrites A’s list, so the report has 2 of 5 findings: FINDINGS LOST. Choose B as the branch that finishes first and A’s three survive instead: the result depends on timing, which is worse than a consistent error.
Read, append, write back
Set How a branch writes to Read the list, append, write back. In parallel both branches read the empty list when they start, so the second write still replaces the first: 2 of 5. Execution applies to this append mode: run the branches Sequential and B reads A’s list before appending, so all 5 findings survive, at the cost of the parallelism. A read-modify-write without a compare-and-set is a lost-update race.
Give each branch its own key
Set State keys to findings_a and findings_b. Each branch owns its output, nothing is overwritten, and the report step merges both: ALL FINDINGS KEPT, 5 of 5, in parallel and in either order. This is the pattern of giving each parallel sub-agent its own output key and combining results in the next step.
Inspect intermediate data, not only status
Every run on this page succeeds; only the contents of state show the loss. Inspecting a workflow means looking at the intermediate values each step wrote and read, which is why the trace records every read and write with the key and the number of items.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the start, each read and write, the merge and the report across sixty seconds; the report lane marks every finding that survived. The model follows the spirit of ADK workflow agents and output keys but is not the ADK API; parallel branches read at start and write at finish, with no locking. No model runs.