---
slug: blackboard
type: pattern
summary: "Coordinate several agents through one shared, structured workspace they all read and write, with an explicit rule for who acts next and when the work is done."
created: 2026-10-19
updated: 2026-10-19
related:
  externalized-state:
    relation: depends-on
    note: "A blackboard is externalized state that several agents share, so the single-agent version comes first."
  parallelization:
    relation: depends-on
    note: "Blackboard is one way to coordinate agents running in parallel once there are too many to direct by hand."
  orchestrator-workers:
    relation: contrasts-with
    note: "Orchestrator-Workers puts a coordinator in charge of every dispatch; a blackboard lets agents pick up work by reading shared state."
  agent-teams:
    relation: contrasts-with
    note: "Agent Teams combine a lead agent, a shared task list, and direct messaging; a pure blackboard has no lead and no messages, only the board."
  concurrency:
    relation: uses
    note: "Claiming an entry on a shared board is a concurrency problem and needs an atomic claim or lock rule."
  source-of-truth:
    relation: uses
    note: "The board is the single authoritative record of what is claimed, done, and still open."
  verification-loop:
    relation: uses
    note: "A verifier agent that checks entries against evidence stops one agent's mistake from spreading to every reader."
  subagent:
    relation: uses
    note: "The specialists that watch the board are often subagents with narrow scopes."
  worktree-isolation:
    relation: uses
    note: "Agents can keep their code changes in separate worktrees while the board carries only coordination."
---
# Blackboard

> **Pattern:** A named solution to a recurring problem.

*Coordinate several agents through one shared, structured workspace that they all read and write, so no agent needs to know who the others are, and let an explicit rule decide who acts next and when the work is done.*

*Also known as: Blackboard Architecture, Blackboard System*

> **📝 Where the name comes from:** Picture a room of specialists gathered around a blackboard. Nobody runs the meeting. Each expert watches what's written there, and when they see something they can extend (a half-finished proof, an unchecked figure), they walk up and add to it. Allen Newell used this image in 1962 to describe how separate parts of a problem-solving program might cooperate, and the Hearsay-II speech-understanding system turned it into a working architecture in the 1970s. The name stuck because the picture is exact: the board is the only channel, and the specialists never talk to each other directly.

## Understand This First

- [Externalized State](externalized-state.md) — the single-agent habit of keeping plans and progress in files, which a blackboard extends to many agents.
- [Parallelization](parallelization.md) — running agents side by side, the situation that creates the coordination problem.

## Context

At the **agentic** level, this pattern shows up as soon as you run more than two or three agents against one codebase. Someone has to decide who works on what, and that decision has to be visible to everyone. Teams often start by making the human the coordinator, then try a coordinator agent, then notice that their agents are already coordinating through something shared: a `PLAN.md` with "in progress" lines that other agents skip, a task file with checkboxes, a tracker that agents read before they start.

That shared thing is a blackboard, usually a partial one. The classical pattern has three parts, and teams that arrive at it by accident tend to build one of them well and leave the other two implicit. This entry names all three so you can build them on purpose.

## Problem

How do several agents cooperate on work whose shape you can't know in advance, without a central coordinator that has to understand every specialist and without a web of agent-to-agent messages that nobody else can see?

A coordinator works when one look at the goal tells it what the subtasks are. Many coding problems aren't like that. A migration turns up a hidden dependency halfway through; a debugging session produces three competing hypotheses, each suggesting different next steps. The work reveals itself as it's done, and the agent best placed to take the next step is often the one that notices it, not the one a coordinator would have picked.

## Forces

- What needs doing emerges during the work, so a plan written up front goes stale.
- A coordinator has to model every worker's competence, and that burden grows with each specialist you add.
- Messages passed from one agent to another are lossy: each handoff is a summary, and agents outside the exchange never see it.
- Shared writable state invites races, with two agents claiming the same item or one overwriting another's result.
- Reading the whole shared record costs every agent context and tokens, so the record can't grow without limit.

## Solution

**Give the agents one shared, structured workspace as their only coordination channel, let each agent act when the workspace shows something it can advance, and write down the rule for who acts next and what "done" means.** The pattern has three parts, and it fails in predictable ways when any of them is missing.

**The board.** A single store that every agent can read and write: a coordination file, a small database, an issue tracker, or a coordination service exposed to agents as a [tool](tool.md). What makes it a blackboard rather than a scratch file is structure. Each entry has a kind (open question, hypothesis, claim, finding, decision), a status, an owner when claimed, and links to evidence such as a file path, a test run, or a commit. Structure lets an agent read only the entries it acts on instead of the whole history. Prefer append-only writes: a correction is a new entry that supersedes the old one, so the history stays intact and readable.

Here is what a few entries might look like in a board kept as structured text:

```yaml
- id: 41
  kind: claim
  section: "spec 3.2 refund endpoint"
  owner: impl-agent-2
  lease_expires: "14:40"
- id: 42
  kind: finding
  section: "spec 3.2 refund endpoint"
  text: "Contract tests fail on partial refunds; currency rounding differs."
  evidence: "ci run 8812, tests/contract/test_refunds.py"
- id: 43
  kind: decision
  supersedes: 39
  text: "Round half-even in the ledger service, not the API layer."
```

The details don't matter much. What matters is that every agent can tell, from the board alone, what is taken, what is known, and what that knowledge rests on.

**The knowledge sources.** These are the agents, often [subagents](subagent.md) with narrow scopes. Each one has a trigger condition on the board: an unclaimed failing test, a decision with no review entry, a hypothesis with no experiment attached. When its condition holds, the agent contributes. Agents don't call each other or wait on each other's replies. Adding a new specialist means adding an agent with a new trigger, not rewiring a coordinator.

**The control.** This is the part teams most often skip, and it answers three questions. First, when several agents' triggers fire at once, which one acts? A fixed priority is often enough: reviews before new implementation, oldest open question first. Second, how does an agent claim an entry so no one else takes it? The claim has to be atomic, meaning two agents racing for the same entry can't both win (the general problem is [Concurrency](concurrency.md)). It should also carry a lease, an expiry time after which the claim lapses, so a crashed agent can't hold an item forever.

Third, what board state counts as finished? Write the stopping rule as a condition on the board, such as "every spec section has an accepted implementation entry with passing test evidence, and no open questions remain." Without it, agents either keep finding things to do or each decide on their own that the job is over.

Keep the board separate from source control. A repository is a good place for code and a poor coordination channel, because push frequency is set by CI cost and review habits, not by how fast agents need to see each other's claims. When pushes slow down, the coordination signal goes quiet with them. Keep the artifacts in the repository, with each agent's changes in its own [worktree](worktree-isolation.md) if you like, and put the claims and findings in a dedicated store.

Choose a blackboard over [Orchestrator-Workers](orchestrator-workers.md) when the decomposition emerges during the work and the specialists can judge their own relevance. Choose Orchestrator-Workers when one look at the goal is enough to plan it and a single agent needs to synthesize the results. [Agent Teams](agent-teams.md) sit between the two: a lead agent and a shared task list, with direct messages layered on top.

> **💡 Tip:** Write the control rule before you add the third agent. "Claims expire after 20 minutes," "a reviewer must accept an entry before anyone builds on it," and "done means no open questions" are three lines in an instruction file, and they head off failures that teams otherwise blame on the agents.

## How It Plays Out

A team migrating a payments API to a new schema numbers the sections of its specification and stands up a board as a small coordination service that its agents reach as a tool. A test-writing agent watches for spec sections with no contract tests and posts failing tests as findings. Three implementation agents watch for sections with failing tests and no live claim, claim one, and post their result with a CI link. A review agent watches for implementation entries and posts acceptance or rejection with a reason.

Midway through, one implementation agent posts a finding that the legacy refund endpoint is deprecated and can be dropped. The review agent checks the evidence link, finds it points at an unrelated file, and posts a rejection before the other agents act on the claim. Nobody assigned the review; the review agent saw an entry matching its trigger.

A different team gets there by accident. Five agents building an inventory service keep a `TODO.md` checklist in the repository, mark items "taken" with their session name, and rebase often to pick up each other's edits. For a few days it works: agents skip taken items, notes left beside finished items tell the next agent how to call the new code, and nobody needs a coordinator. Then the integration suite grows to forty minutes, the team asks agents to push only when a feature is complete, and a "taken" mark can sit unpushed on one machine for an hour. Two agents build the same stock-reservation endpoint, and a third codes against an interface another agent had already changed locally. The fix is to move claims and findings out of the repository into a store that every agent sees the moment it's written, and to give every claim a lease.

An on-call engineer uses the same shape for a production incident with no obvious cause. A log-reading agent, a code-search agent, and a metrics agent each post hypotheses to a shared incident board at three levels: observed symptom, candidate cause, confirmed cause. The control rule says the hypothesis with the most independent supporting evidence gets tested next, and only the engineer may mark a cause confirmed. Nobody could have written the investigation plan in advance; the board let the plan form as the evidence arrived.

## Consequences

**Benefits.** You can add or remove a specialist without touching any other agent, because agents depend on the board rather than on each other. The board is a full-fidelity [source of truth](source-of-truth.md): every agent sees the same finding in the same words, which removes a class of lossy-handoff errors and gives humans one place to read the state of the work. A human can also steer by writing to the board, posting a decision or a question, instead of messaging each agent. The decomposition can change as the work reveals itself, which a fixed plan can't do.

**Liabilities.** Concurrent writes need a claim or locking rule, and leases need a clock that every agent agrees on. Boards bloat: as entries pile up, agents spend more context reading them, so you need levels like the incident board's, filtered views, or archival of settled entries. Errors propagate: one agent's hallucinated entry is visible to every reader at once, so evidence links, append-only history, and a verifier agent running a [Verification Loop](verification-loop.md) stop being optional. Without explicit control, every agent that matches a trigger acts at once, or none of them is sure the work is done. Debugging is harder because there is no call stack; the board's history is the only trace of why things happened in the order they did, so keep it.

The evidence for this shape in coding work is still thin. Research on blackboard-based LLM agent systems reports large gains on data-discovery benchmarks and comparable accuracy at lower token cost on reasoning and math sets. Practitioner reports from teams running many coding agents on one repository describe the same arrangement emerging without anyone designing it. Neither yet amounts to a controlled comparison against a well-run coordinator on software tasks.

## Sources

- Allen Newell's RAND memorandum "Some Problems of Basic Organization in Problem-Solving Programs" (1962) is the usual credit for the blackboard image itself: independent specialists cooperating through a shared surface rather than by calling one another.
- L. D. Erman, F. Hayes-Roth, V. R. Lesser, and D. R. Reddy's *[The Hearsay-II Speech-Understanding System: Integrating Knowledge to Resolve Uncertainty](https://doi.org/10.1145/356810.356816)* (1980) described the first full blackboard architecture: a board organized in levels from sound segments up to phrases, independent knowledge sources triggered by changes on the board, and a priority scheduler that chose the most promising next action. That scheduler is the ancestor of the control part described here.
- H. Penny Nii's two-part survey in *AI Magazine*, *[The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures](https://ojs.aaai.org/index.php/aimagazine/article/view/537)* and *[Blackboard Application Systems, Blackboard Systems and a Knowledge Engineering Perspective](https://ojs.aaai.org/index.php/aimagazine/article/view/550)* (1986), set out the three-part model of board, knowledge sources, and control that this entry follows.
- David Gelernter's *[Generative Communication in Linda](https://doi.org/10.1145/2363.2433)* (1985) carried the idea into parallel programming as the tuple space, where processes coordinate only by writing entries to a shared space and taking them out, never by addressing each other.
- Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal catalogued Blackboard as an architectural pattern in *[Pattern-Oriented Software Architecture, Volume 1: A System of Patterns](https://openlibrary.org/works/OL19228941W)* (1996), recommending it for problems with no known deterministic solution strategy.
- Two research groups have rebuilt the architecture with LLM agents. Bochen Han and Songmao Zhang's *[Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture](https://arxiv.org/abs/2507.01701)* (2025) selects the next acting agent from the board's contents and repeats until the board reaches consensus. Alireza Salemi and colleagues at the University of Massachusetts Amherst and Google Cloud AI Research, in *[LLM-Based Multi-Agent Blackboard System for Information Discovery in Data Science](https://arxiv.org/abs/2510.01285)* (2025), replace a master-worker coordinator with a board where subordinate agents volunteer for posted requests, and report 13 to 57 percent relative gains in end-to-end success on data-discovery benchmarks.
- Mert Cemri and colleagues' *[Why Do Multi-Agent LLM Systems Fail?](https://arxiv.org/abs/2503.13657)* (2025) named inter-agent misalignment as one of three top-level failure categories in multi-agent LLM systems, which is the failure class a shared full-fidelity record is meant to reduce.
- The return of the blackboard as a named pattern for coding agents came from the agentic coding practitioner community in 2026, as teams running many agents on one repository recognized the shape they had built by accident.

---

- [Next: Generator-Evaluator](generator-evaluator.md)
- [Previous: Agent Teams](agent-teams.md)