The blackboard architecture your agents already use

If your agents coordinate by reading and writing one shared place (a plan file, a repo, a message list, a scratchpad table) rather than by calling each other, you have built a blackboard architecture. It has a name, a canonical implementation from 1976, and a body of published work on exactly how it breaks. Most teams get there by accident and stop after the easy third of it.

The easy third is the board. The two parts that get skipped are the control layer that decides who writes next, and the entry structure that lets a reader tell a verified fact from a plausible guess. Skip those and you inherit a specific, well documented set of failures: duplicated work, agents that never stop, agents that stop too early, and confident garbage propagating because nothing on the board records how sure anyone was.

What a blackboard architecture actually is

Three components, and the ratio matters.

The blackboard is a shared, structured workspace holding the problem and every partial solution so far. In Hearsay-II, the speech understanding system built at Carnegie Mellon between 1971 and 1976, the board held hypotheses at explicit levels of abstraction: acoustic segments, syllables, words, phrases. Each entry carried a credibility rating and links to the lower level evidence supporting it.

Knowledge sources are independent specialists. An acoustic analyser, a syntax predictor, a semantic rater. The defining constraint is that they never call each other. A knowledge source reads the board, decides whether it can contribute, writes, and goes quiet. Remove that constraint and you have a call graph wearing a shared cache.

The control component decides which specialist runs next given the current state of the board. This is where the intelligence lives. Hearsay-II scheduled opportunistically: not a fixed pipeline, but whichever contributor could make the strongest contribution given the evidence currently on the board. H. Penny Nii's 1986 survey in AI Magazine calls this out plainly, and Barbara Hayes-Roth's BB1 pushed it further, monitoring whether problem solving was progressing and switching strategy when it stalled.

The metaphor is a room of specialists at a chalkboard. Nobody chairs the meeting by handing out assignments. Whoever can add the most useful next line walks up and adds it.

You have probably already built one

In September 2026, Giles Edwards-Alexander described building an airline irregular operations system with ten engineers in four days, and then noticing that the agents had invented a coordination protocol nobody had specified. He called the writeup An Accidental Blackboard. The monorepo was the board. Numbered plan items tied to spec sections were the entries. Agents marked lines in progress, other agents watched for completion and integrated the finished work. Nothing in the prompts asked for this.

The same week, a practitioner writeup on dev.to reported the mirror image: three agentic loops built without naming any of them, an execution plan loop wrapping a milestone loop wrapping a TDD loop, each with its own exit condition, all arrived at by solving practical problems rather than by design.

Look at production systems and the pattern is everywhere once you know the shape:

• Anthropic's multi-agent research system has subagents write their output to external storage and pass lightweight references back to the lead agent, explicitly to avoid the "game of telephone" of routing everything through conversation.
• In LangGraph's multi-agent patterns, the shared state object is the board and a routing field is the control signal.
• Every AGENTS.md, plan file and task table your agents append to is a board with no schema.

Git is quietly a very good blackboard. It is append-only, versioned, attributable, and it has real conflict semantics. That is more than most purpose-built agent scratchpads offer.

The part that gets dropped

Here is the same architecture across three columns: what the original had, what most agent stacks have, and the gap.

The control column is the expensive one. Without a control rule you get one of two shapes. Either every agent decides it can contribute and they all write at once, which is how Anthropic's early runs ended up with subagents duplicating the same research angle because the task descriptions did not divide the work. Or every agent decides someone else should go first, and the system idles until a timeout.

Both are scheduling problems. Neither is fixed by a better prompt, because the decision belongs outside the agents.

The failure modes are already catalogued

The Berkeley group behind Why Do Multi-Agent LLM Systems Fail? annotated 1,642 execution traces across seven multi-agent frameworks and produced MAST, a taxonomy of 14 failure modes in three categories. The distribution is the interesting part.

Read the individual modes and they map onto the missing components almost one to one. "Unaware of termination conditions" and "step repetition" are the control problem. "Information withholding" and "ignored other agent's input" are what happens when the board has no schema, so a contribution can be written in a form nobody downstream parses. "Premature termination" and "no or incomplete verification" are the stopping criteria the original architecture made explicit.

Roughly 79% of observed failures sit in the two categories that a blackboard design addresses directly, and only 21% in verification. Teams generally spend their effort the other way around.

Entries need credibility, not just content

Hearsay-II attached a credibility rating to every hypothesis and recorded which lower level evidence supported it. That is not decoration. It is what lets a downstream specialist decide whether to build on an entry or to look for a better one, and it is what lets the system back out a whole subtree when the evidence underneath collapses.

Most agent boards store a status and some prose. "Auth module done." Done according to whom, checked how, depending on what? A later agent reads that line and treats it as ground truth, because there is nothing on the board that distinguishes a passing test run from an optimistic summary.

This is the same independence problem we worked through in why maker checker controls break when agents reconcile: a confidence score produced by the doer is the doer's opinion of the doer. The blackboard version is slightly better, because credibility plus support links at least makes the claim auditable by a different reader. It still does not make the writer a checker.

The companion argument on the data side is Making Your Data Ready for Agentic AI, which lands on traceability and explicit context as prerequisites rather than nice to haves, for the same reason: "a human double-checks; an agent confidently acts on it."

Termination is a design decision

Nothing on a board announces that the problem is solved. Somebody has to evaluate a predicate.

Agent systems usually delegate this to the model ("say TERMINATE when finished") or to a budget. The first is self-attestation. The second is not a stopping criterion, it is a circuit breaker that happens to fire at the same place. We wrote about the failure surface this creates in the long-horizon agent problem: the further out the horizon, the more the run depends on something other than the agent deciding when it is done.

A usable termination rule is written outside the agents, reads only the board, and is cheap enough to evaluate after every write. "Every plan item has a status of verified, and every verified item has a linked test run" is a predicate. "The agent thinks it is finished" is not.

Making an accidental blackboard deliberate

Step four is where a lot of teams reach for event sourcing without saying so. An append-only log of contributions with a projected current view is exactly the structure we described in core banking architecture with event sourcing and CQRS, and the reasons transfer intact: you get an audit trail, you can replay, and a bad write is a correcting entry rather than lost history.

Why the name is worth the trouble

Naming the pattern is not academic hygiene. It changes what you search for. "Our agents keep duplicating work" returns prompt engineering advice. "Blackboard control strategy" returns forty years of work on exactly that question, including the parts where it went badly. Blackboard systems were criticised for control overhead and for scaling poorly when too many contributors watched the same board, which is useful to know before you point twenty agents at one plan file.

The gap between an accidental blackboard and a deliberate one is roughly a day of work: a schema, a control rule, a termination predicate. The gap in behaviour is the difference between a system you can debug and a system you can only re-run.

If you are building multi-agent systems and want a second pair of eyes on the coordination layer before it ossifies, that is the kind of thing our AI engineering practice does day to day. Tell us what your agents are arguing about and we will tell you which component is missing.