The three multi-agent patterns differ on one question: who holds the goal. A supervisor holds it centrally, a swarm distributes it across peers, and a blackboard has no owner at all — the workspace itself carries the state. That single difference decides how easy each pattern is to debug.
Teams choosing a multi-agent architecture usually compare frameworks, token costs, or how many agents to run. Those are secondary. The decision that actually determines whether the system is operable in production is where the goal lives and who can be held accountable when a run goes wrong.
- 1component holds the goal in a supervisor pattern
- 0components hold the goal in a pure blackboard system
- 3+independent points of failure attribution in an unmanaged swarm
- 1980year the blackboard architecture was formally published
What actually distinguishes the three patterns?
| Criterion | Supervisor | Swarm | Blackboard |
|---|---|---|---|
| Who holds the goal | One central coordinator | No one; distributed across peers | No one; implicit in shared state |
| Control flow | Explicit delegation and return | Peer-to-peer, locally decided | Opportunistic, triggered by state changes |
| Failure attribution | Straightforward; one component to inspect | Hard; the failure emerges from interaction | Hard; any contributor could be the cause |
| Debuggability | High | Low without heavy instrumentation | Low without a full state history |
| Scales to how many agents | Modest; the coordinator becomes a bottleneck | Large; no central chokepoint | Moderate; bounded by contention on shared state |
| Best fit | Well-defined sub-tasks with clear ownership | Exploratory search over a large space | Incremental problem-solving from partial evidence |
| Operational risk | Coordinator is a single point of failure | Emergent behaviour nobody explicitly designed | Race conditions on the shared workspace |
Every other difference between these patterns follows from the first row. A system with one component holding the goal can always answer “what was this run trying to do.” A system without one can only answer that by reconstructing intent from the interaction — which is precisely the extra work that makes swarm and blackboard systems harder to operate.
How does the supervisor pattern actually work?
One coordinating agent receives the task, decides how to decompose it, delegates sub-tasks to specialised worker agents, and integrates their results. Workers do not talk to each other; every path runs through the coordinator.
This is the closest multi-agent pattern to a conventional function call tree, which is exactly why it debugs like one. A stack trace through a supervisor system reads top to bottom: coordinator decided X, delegated to worker A, worker A returned Y, coordinator decided Z based on Y.
At a glance
- The coordinator is the only component that ever holds the full goal
- Workers are interchangeable and individually simple to specify
- Adding a worker type does not change the control-flow shape
- The coordinator itself becomes the bottleneck and the single point of failure
- Nesting supervisors more than two levels deep usually adds latency without adding clarity
The failure mode is specific and well understood: the coordinator makes a bad decomposition decision, or misinterprets a worker’s result, and the error is entirely inside one component. That is inconvenient but tractable — you know exactly where to look.
How does a swarm actually coordinate without a center?
In a swarm, agents are structurally equal. Each one observes local information, makes its own decision, and takes action without a coordinator approving it first. Coordination, where it exists, happens through the agents seeing each other’s outputs or through simple shared signals, not through a chain of command.
The appeal is real: no chokepoint, no component that has to understand the whole task, and a shape that adds more agents without redesigning control flow. The cost is equally real. Nothing in the architecture holds the goal, which means nothing in the architecture can tell you, after a bad outcome, which agent’s decision actually caused it.
Figure 1 — Same failure, two architectures
Supervisor
A worker returns a wrong result. The coordinator logged the delegation and the result it received.
You read one log, find the worker that produced the bad output, and fix that worker or its inputs.
One log, one cause
Swarm
The wrong outcome emerged from several agents each making a locally reasonable decision that combined badly.
No single log shows the failure, because no single agent held enough of the picture to be “the” cause. You reconstruct the interaction from many partial logs and often cannot agree on where it went wrong.
Many logs, no single cause
The coordinator in a supervisor pattern is not just control flow — it is also the point where debugging attaches. Remove it, and you have not just removed a bottleneck. You have also removed the one place a failure could be pinned down.
None of this means swarms are a bad choice. It means the debugging cost has to be paid somewhere, usually through much heavier tracing than a supervisor system needs, and that cost should be weighed against the concurrency benefit before choosing the pattern.
What is the blackboard pattern, and where does it come from?
The blackboard architecture predates modern LLM agents by more than four decades. It was formalised in the Hearsay-II speech-understanding system, published in 1980, where independent “knowledge sources” each watched a shared data structure — the blackboard — and contributed partial hypotheses whenever they recognised something they could act on.
No component owned the overall goal of “understand this sentence.” The blackboard held partial hypotheses at multiple levels — phonetic, lexical, syntactic — and any knowledge source could read or write to any level once triggered by a relevant state change. A control component decided which triggered contribution to act on next, but it never held the sentence’s meaning itself, only a queue of candidate next steps.
Watch for this
A blackboard’s shared workspace is the same thing as shared mutable state between agents, and it inherits the same risk: two contributors writing to overlapping regions produce races that are difficult to reproduce given any non-determinism in ordering. The original architecture handled this with an explicit control component arbitrating access. Skipping that arbitration and letting agents write freely is the most common way modern blackboard-style systems become unreliable.
The modern equivalent is a shared document, task board, or state object that several agents read from and write to independently — one agent adds a finding, another builds on it, a third flags a contradiction — with no agent responsible for the whole task. It fits problems where evidence accumulates incrementally and no single agent can see enough at any one moment to own the goal outright.
Which pattern fits which problem?
| If the work looks like | Choose | Because |
|---|---|---|
| A task that decomposes cleanly into known sub-tasks | Supervisor | Delegation matches the structure of the work exactly |
| Searching a large space where paths do not depend on each other | Swarm | Independent exploration in parallel beats a coordinator serialising it |
| Assembling a conclusion from many partial, uncertain clues | Blackboard | No single contributor can see enough to hold the goal alone |
| Anything with financial or safety consequences | Supervisor, or a supervisor wrapping the other two | You need one place to attach an approval gate and an audit log |
| A team that has never operated a multi-agent system before | Supervisor | It is the pattern that debugs like the tools they already know |
The last row matters more than it looks. Swarm and blackboard patterns are frequently chosen for their elegance before a team has built the observability a decentralised system requires. A supervisor is the conservative default for exactly that reason — not because it is more capable, but because its failures are legible from day one.
Can you combine the patterns?
Routinely, and the combinations are often better than any pure form.
- Supervisor of swarms. A coordinator delegates an exploratory sub-problem to a swarm, then integrates whatever the swarm converges on. The goal is held centrally at the top level; only the exploration is decentralised.
- Blackboard with a scheduler. The original Hearsay-II design already does this — a lightweight control component decides which contribution to act on next, without holding the task’s meaning itself. It restores a debuggable point of arbitration without collapsing the pattern into a full supervisor.
- Supervisor with a shared scratchpad. Workers report to a coordinator as usual, but also write intermediate findings to a shared blackboard-style space other workers can read, cutting redundant work without giving up centralised accountability.
The pattern to avoid is a pure, unscheduled swarm on anything with real consequences. It is the only combination in this list with no component anywhere that can be asked “why did the system do that” and given a direct answer.
Where do teams go wrong?
Choosing swarm for its scalability story, ignoring its debugging cost
A swarm’s lack of a chokepoint is a genuine advantage for throughput. Teams frequently adopt it for that reason alone, without budgeting for the tracing infrastructure needed to reconstruct a failure after the fact, then discover the gap during an incident rather than during design.
Building a blackboard with no arbitration
Letting every agent write to shared state whenever it wants recreates exactly the race conditions the original 1980 design used a control component to prevent. Skipping that component is not a simplification; it is dropping the part of the architecture that made it reliable.
Assuming pattern choice is purely a performance decision
Throughput, latency, and cost are real considerations, but the pattern also decides how the system will be debugged, audited, and trusted in production. A faster swarm that nobody can explain after an incident is often a worse deployment than a slower supervisor that can always answer for itself.
What do experienced teams do differently?
They pick the pattern based on where accountability needs to live, then optimise for throughput inside that constraint — not the other way round.
Concretely: they default to a supervisor for anything customer-facing or consequential, and reserve swarm and blackboard patterns for sub-problems nested inside a supervised run, where a coordinator still holds the top-level goal even if the interior is decentralised. This gets most of the concurrency benefit of the decentralised patterns while keeping exactly one place to attach logging, budget limits, and human approval.
They also instrument before they need to, not after. A swarm or blackboard system without full per-agent tracing from the first production run is a system whose first real incident will be undiagnosable, because the information needed to diagnose it was never captured.
A short glossary
- Supervisor pattern
- A multi-agent architecture where one coordinating agent holds the goal, delegates sub-tasks, and integrates results.
- Swarm
- A multi-agent architecture of structurally equal peers making local decisions without a central coordinator.
- Blackboard architecture
- A shared workspace that independent contributors read from and write to, with no single component holding the overall goal.
- Knowledge source
- In blackboard terminology, an independent contributor that acts when it recognises a relevant state on the shared workspace.
- Failure attribution
- The ability to identify which specific component of a system caused an observed bad outcome.
Key takeaways
- The three patterns differ fundamentally on who holds the goal, and that decides everything else.
- Supervisor centralises the goal, making failures attributable to one component.
- Swarm distributes decisions across peers, trading a chokepoint for debugging difficulty.
- Blackboard has no owner of the goal at all; state itself carries the task forward.
- The blackboard pattern predates LLM agents by over four decades, formalised in Hearsay-II in 1980.
- Combining patterns — a supervisor wrapping a swarm or a scheduled blackboard — often beats any pure form.
- Default to supervisor for consequential work; reserve decentralised patterns for sub-problems nested inside it.
Frequently asked questions
Which multi-agent pattern is easiest to debug?
Supervisor, because one component always holds the full goal and every delegation and result passes through it. A failure can almost always be traced to a single worker or a single coordinator decision, which is not true of swarm or blackboard systems.
Is a swarm architecture just a supervisor without a coordinator?
No — removing the coordinator does not just remove a bottleneck, it removes the one place a failure could be pinned down. A swarm needs its own investment in per-agent tracing to reach anything close to the debuggability a supervisor gets for free.
Where does the blackboard pattern come from?
It was formalised in the Hearsay-II speech-understanding system, published in 1980, where independent knowledge sources read and wrote partial hypotheses to a shared blackboard. It predates LLM-based agents by more than four decades and the coordination problem it solves is unchanged.
Can these patterns be combined?
Yes, and combinations are common in practice. A supervisor can delegate an exploratory sub-problem to a swarm, or a blackboard can run under a lightweight scheduler that decides which contribution to act on next without holding the task’s meaning itself.
Which pattern scales to the most agents?
Swarm, because there is no central coordinator to become a bottleneck as agent count grows. Supervisor is limited by how much delegation and result-integration one coordinator can manage, and blackboard is limited by contention on the shared workspace.
What is the biggest risk in a blackboard-style system?
Uncoordinated writes to the shared workspace. Without an arbitration component deciding which contribution proceeds, multiple agents writing to overlapping state produce races that are difficult to reproduce, which is exactly what the original 1980 design used a control component to prevent.
Should a customer-facing agent system use a swarm?
Usually not as the top-level pattern. Reserve swarm for a sub-problem nested inside a supervised run, so a coordinator still holds the top-level goal, can attach an approval gate, and can answer for the outcome even while the interior exploration runs decentralised.
How do I choose between these three patterns?
Ask where accountability needs to live before asking about throughput. If the work decomposes cleanly, use a supervisor. If it is unconstrained parallel search, use a swarm. If it is incremental assembly from partial evidence with no single owner, use a blackboard — then optimise for performance inside that constraint.
References
- Erman, L. D., Hayes-Roth, F., Lesser, V. R., and Reddy, D. R. The Hearsay-II Speech-Understanding System: Integrating Knowledge to Resolve Uncertainty. ACM Computing Surveys, Vol. 12, No. 2, 1980. The original formal description of the blackboard architecture.
- Anthropic. Model Context Protocol documentation, covering how individual agents in any of these patterns expose and discover tools.
- OpenTelemetry. Traces and spans, the instrumentation model needed to reconstruct failures in swarm and blackboard systems.
- NIST. AI Risk Management Framework, relevant to accountability and audit requirements that favour supervisor patterns for consequential work.
