What Is the Blackboard Pattern?
The blackboard pattern is an architecture in which independent specialist components, called knowledge sources, cooperate on a problem by reading from and writing to one shared data structure, the blackboard, instead of messaging each other directly. A control component watches the blackboard and decides which knowledge source acts next, based on its current contents. The solution builds up incrementally on the blackboard as each specialist contributes a partial result.
Updated
What is the blackboard pattern?
The pattern comes from speech recognition research in the 1970s. The Hearsay-II system at Carnegie Mellon, described by Erman, Hayes-Roth, Lesser and Reddy in ACM Computing Surveys (1980), had independent knowledge sources that read and wrote hypotheses on a shared blackboard at levels from phones and phonemes up to syllables, words and phrases. None could understand an utterance alone; each posted hypotheses at its own level, and others built on them. H. Penny Nii's two-part survey in AI Magazine (1986) generalized the design into the blackboard model of problem solving, calling Hearsay-II, which evolved between 1971 and 1976, the first blackboard system.
The problem it addresses is coordination among specialists whose order of work cannot be fixed in advance. A pipeline hard-codes the sequence. A blackboard lets whichever specialist has something useful to add act next, so the sequence emerges from the data.
The pattern has returned with LLM agents. Han and Zhang proposed a blackboard architecture for LLM multi-agent systems (2025) in which agents with different roles share all information on the blackboard and are selected to act based on its contents. Salemi et al. used a blackboard for data discovery: a central agent posts requests, and subordinate agents volunteer to respond based on their capabilities, so the central agent doesn't need to know each one's expertise.
How the blackboard pattern works
Three parts:
- 1.Blackboard. Shared state, often organized into levels or regions (raw input, hypotheses, partial solutions).
- 2.Knowledge sources. Independent specialists. Each has a condition ("I can contribute when X is present") and an action (read, compute, write).
- 3.Control. A scheduler that picks which eligible knowledge source runs next, and decides when the problem is solved.
A minimal loop in pseudocode:
while not control.solved(board):
eligible = [ks for ks in sources if ks.condition(board)]
ks = control.choose(eligible, board)
snapshot = board.read(ks.inputs)
result = ks.act(snapshot) # an LLM call can take seconds
board.write(result)In the classic designs, a central control component chose which knowledge source ran next. Many LLM multi-agent systems run agents in parallel instead, and each act step is a model call that can take seconds. That changes the risk.
Why the blackboard pattern matters in real-time systems
Once agents run concurrently, the blackboard is shared mutable state with slow writers. Agent A reads a value, spends several seconds reasoning, and writes a result based on what it read. Meanwhile Agent B read the same value and wrote first. A's write is now built on a value that is no longer true: a lost update or a stale read, the classic database anomalies. Yang et al. (2026) argue that many multi-agent failures are concurrency control problems of exactly this kind, and that frameworks need conflict detection and isolation as first-class features.
Two design choices decide whether a blackboard survives concurrency:
- What a write is conditioned on. A write should commit only if what the agent read is still current, through a version check or a serializable transaction. Otherwise reject and let the agent re-read.
- Whether contributions merge. Appending hypotheses merges naturally. Decrementing a shared budget, claiming a task or reserving inventory does not merge, so those writes must be serialized.
Where the blackboard holds unmergeable state such as budgets, claims or quotas, it has to provide transactions, not just storage. That design problem is covered in multi-agent coordination.
FAQ
Related terms
Shared context means every service and agent in a decision system reads one internally coherent snapshot of state, instead of private copies that diverge.
A race condition occurs when a system's outcome depends on the timing of concurrent operations, letting interleaved reads and writes corrupt shared state.
Isolation levels control how database transactions see each other's concurrent changes, from READ UNCOMMITTED to SERIALIZABLE. Anomalies, defaults, examples.
Event sourcing stores application state as an append-only log of immutable events; current state is derived by replaying them. Covers mechanics and trade-offs.
Decision coherence is the property that concurrent automated decisions act on the same version of shared state, instead of contradicting each other.
A decision ledger is an append-only record of automated decisions: what was decided, on what inputs, under which policy and authority, and what changed.
Unmergeable state is shared mutable state whose concurrent updates can't be combined afterward without breaking a rule, such as a budget, quota or balance.
An agentic mesh runs many AI agents as one governed network, with shared discovery, identity, observability and policy. Origins, McKinsey's model and limits.