What is Blackboard Architecture?
Also called blackboard system.
A blackboard architecture is a coordination pattern in which independent components read from and write to a shared, structured data store rather than calling one another directly. Each component watches the store for conditions it can act on, contributes its result, and lets other components build on that contribution, with a control mechanism deciding who acts next.
The pattern comes from 1970s and 1980s artificial intelligence research, notably speech understanding systems, where specialists at different levels of analysis contributed partial results to a common workspace. It has been revived for language model agents because it decouples participants: an agent needs to understand the format of the blackboard, not the identity or interface of every other agent.
Three parts define it. The blackboard holds the evolving solution state. The knowledge sources are the independent components that can each recognize when they have something to add. The control component decides which knowledge source runs next, since several may be eligible at once, and it is where scheduling policy and priority live.
For agent systems the advantage is incremental, order independent progress. Agents can be added or removed without rewiring message paths, and partial results remain visible to everyone, which reduces the duplicated context that direct handoffs cause. It suits problems where the path to a solution is not known in advance.
The weaknesses are concurrency and growth. Concurrent writes need locking or append only entries to avoid lost updates, and an unbounded blackboard eventually exceeds what any agent can read, forcing summarization or scoped views. Contention on the control component can also reintroduce the bottleneck the pattern was meant to remove.
Key points
- Agents coordinate through a shared store, not direct calls
- Three parts: blackboard, knowledge sources, control component
- Participants can be added without rewiring message paths
- Concurrent writes require locking or append only entries
- Unbounded growth forces summarization or scoped views
In practice
An incident response system keeps a shared record for each outage. A log reading agent appends error clusters, a metrics agent appends anomalous time ranges, and a deploy agent appends recent releases. A summarizing agent triggers only once all three sections are populated, then writes a root cause hypothesis. None of the four agents calls another, and each reads only the sections it needs.