Chain, Blackboard, or Broadcast? Three Ways Agents Share State

Chains lose the evidence, blackboards fight over it, broadcasts drown in it. Pick by which failure your task can absorb — and log provenance from day one or debugging becomes guesswork.

Once a system has more than one agent, the interesting design decision is not who does what. It's how they see each other's work. Three topologies cover nearly every real system, and each fails in a way you should recognize before choosing.

Chain: output becomes input

The simplest arrangement. Agent A finishes and hands its result to agent B, which never sees A's process — only its conclusion.

Failure mode: compounding loss. Every hop discards the reasoning, the alternatives considered, and the caveats, keeping only the conclusion. By the third hop, agent D is working from a claim several transformations removed from the evidence, with no way to check it. Errors also can't be corrected downstream, because downstream can't see enough to notice one.

Use it when each stage genuinely completes its job and later stages have no legitimate need to revisit earlier evidence. Extraction → validation → formatting is a good chain. Investigation is a bad one.

Blackboard: a shared store everyone reads and writes

Agents work against common state — a document, a task list, a structured record. Each reads what it needs and writes findings back. Nobody holds the whole history in context; the store holds it.

Failure mode: write conflicts and staleness. Two agents read the same state, both act on it, and the second overwrites the first's conclusion without knowing it existed. Agents also re-derive things already recorded, because "check the store first" is a habit that has to be enforced structurally rather than requested in a prompt.

Use it when the work is long-running or resumable, when the shared artifact is the deliverable, or when agents join and leave over time. It's the topology that survives restarts, which alone justifies it for anything long.

Make it work by giving the store structure and rules: append-only findings rather than mutable fields, one owner per section, and a required read-before-write step. ⚠️ A blackboard that's a free-text scratchpad degrades into a transcript nobody can parse — including the agents.

Broadcast: everyone sees everything

All agents share one message stream. Any agent's output is visible to all.

Failure mode: context blowup and echo. Every agent pays for every other agent's tokens, so cost scales with the square of participation. Worse, agents start responding to each other's speculation as though it were established — one agent's hypothesis becomes the group's premise within a few turns, with no step where anyone checked it.

Use it when the number of agents is small, the run is short, and mutual awareness genuinely matters — a debate or adversarial review, where the point is that participants react to each other.

Use it for anything else and you have built the most expensive possible way to run a chain.

Choosing, in one pass

  • Do later stages need earlier evidence, or just earlier conclusions? Evidence → blackboard. Conclusions → chain.
  • Must the work survive a restart, or run for hours? → blackboard, effectively by elimination.
  • Is mutual reaction the actual point (critique, negotiation, debate)? → broadcast, with a hard turn cap.
  • More than about four agents? → not broadcast, whatever else you decide.

Mixed topologies are normal and usually right: a chain of stages where one stage internally uses a blackboard, or a broadcast review panel whose verdict feeds a chain.

🔍 The instrumentation that pays for itself

Whatever you choose, log provenance: for every claim in the final output, which agent produced it and from what input. In a chain this means tagging each hop's output. On a blackboard it means every written finding carries its author and source. Without it, debugging a multi-agent system means guessing which participant invented the wrong detail, and that guessing is most of the cost of running one.

The related metric to watch is derived-claim depth — how many hops separate a statement in the output from an actual tool result. Anything more than two or three hops from ground truth deserves suspicion, and this is measurable rather than a matter of taste.

The takeaway

Multi-agent design is state-sharing design. Chains lose evidence, blackboards fight over it, broadcasts drown in it. Pick the topology whose failure your task can absorb, keep the participant count low, and track provenance from the first day — the alternative is a system whose output nobody can trace and therefore nobody can fix.

Keep reading

Similar posts

Matched on shared tags and category — the more bars, the stronger the overlap with what you just read.