Blackboard

Also known as: shared workspace, shared state board, stigmergy

Agents read and write a shared workspace and contribute when they can.

TrackAgentic systems FamilyMulti-agent Maturity Established ChangesCoordinationContext

Problem

Some problems are solved by many partial contributions that build on each other, in an order nobody can plan. An investigation, a diagnosis or a complex document grows as each finding unlocks the next. A fixed pipeline or a central planner can’t anticipate which specialist will be useful next.

The order of useful contributions depends on what has been found so far.
Specialists should be able to join or leave without rewiring the system.
A shared space can fill with noise and conflicting entries.
Several agents writing at once can overwrite each other.

Solution

Keep a shared, structured workspace, the blackboard, that holds the current state of the problem: facts, hypotheses, open questions and decisions, each with its author and evidence. Specialist agents watch the board and each acts when it sees something it can contribute to, such as a new fact in its domain or an open question it can answer. A lightweight controller decides which ready agent goes next and when the problem is solved. Agents never call each other; they coordinate only through the board.

Diagram

Agents never call each other. The board is the only channel, so every contribution is visible, attributed and auditable.

When to use

Use it when

Investigations or diagnoses where findings unlock each other unpredictably
Many specialists may contribute, and the set changes over time
You want a full, attributed record of how the answer was reached
Agents run at different speeds or on different schedules

Avoid it when

The steps are known in advance; use a pipeline or Plan-and-Execute
Only two or three agents with a fixed order are involved
Strict latency budgets; board-driven progress is hard to predict

Trade-offs

Latency

Progress depends on which contributions arrive when

Cost

Agents only act when relevant, but may check often

Complexity

Board schema, write conflicts and a stop rule

Reliability

Full record; evidence attached to each entry

Gains

Specialists can be added or removed without rewiring the others
A complete, attributed record of how the conclusion formed
Handles problems where the next step can't be planned

Costs

The board schema needs careful design up front
Noise builds up without pruning and confidence rules
Concurrent writes need locking or versioning

Worked example

Scenario
An incident-response system investigates why checkout latency jumped from 300 ms to 2.4 seconds.

Metrics agentPosts a fact: latency spike began at 14:02 and affects only the EU region. It attaches the dashboard link.
Deploy agentSees the timestamp and posts that a payment-service release went to EU at 14:00. It adds a hypothesis: the release caused the spike.
Logs agentPicks up the hypothesis and posts that payment-service timeout errors rose 40× after 14:01, all calling a fraud-check API.
Dependencies agentSees the fraud-check API mentioned and posts that its config changed in the release, with the timeout raised from 500 ms to 2 s.
ControllerMarks the problem solved with high confidence and every link backed by evidence. It drafts the incident summary and proposes rolling back the config. A human approves the rollback.

Failure modes

Failure	Symptom	Mitigation
Board noise	Weak hypotheses pile up and distract other agents	Confidence scores, evidence requirements and pruning of stale entries
Write conflicts	Two agents overwrite or contradict each other's entries	Append-only entries with versions; resolve conflicts explicitly
Stalled board	No agent sees anything it can act on	Controller posts targeted open questions or asks a human
Never-ending investigation	Agents keep adding detail after the answer is clear	Explicit stop criteria checked by the controller