Part 2 of 4 — Multi-agent systems are a graph
A path cannot do two jobs at once.
Part 1 left you a map. A chain moves through it one step at a time. When work needs two specialists at the same time, it splits into branches (fan-out), and then one node has to combine the results (merge).
┌─ specialist B ─┐
A ─────────┤ ├──► D (merge) ──► reply
└─ specialist C ─┘
│
who saw both writes?The merge node produces the final answer, so it must see every branch’s results. If B got a 403 and wrote nothing, D invents a clean story. Who answers after the merge is a separate question: either the merge node writes the reply, or a manager agent writes it and treats B and C as helpers. Keep that question separate from running branches in parallel. Part 3 is when not to split at all.
Example
LangGraph’s Graph API guide calls this pattern fan-out and fan-in. Their published walkthrough fans out from node A to B and C in the same step, then fans in to D. D runs only after both B and C finish. Branches running in parallel save their results to shared state, and a reducer says how two updates combine instead of silently overwriting each other.
That is what the source shows; this is not a tutorial. The lesson matches the diagram above: the merge waits, and it must be able to read both results. Memory still covers how results are saved, and Orchestration still covers how each branch runs.
If the researcher hides a 403 error and the reviewer approves the result as “looks fine,” the failure is in the connection between them, not in the prompts. Why AI Agents Fail covers how such errors spread, so we will not repeat it here.
Takeaway: Splitting work into branches is easy. The hard part is a merge that sees the results of every branch.