The Blackboard Pattern

The blackboard pattern is a foundational design in Yukkai's multi-agent architecture. It enables agents operating in parallel to communicate and coordinate through a shared information space, rather than through direct message passing.

Why a Blackboard?

In a swarm of 10–100+ agents, direct peer-to-peer communication is impractical:

• Agents run in isolated conversations — they cannot see each other's messages.
• The number of pairwise connections grows quadratically (N²).
• Agents finish at different times, making synchronous coordination impossible.

The blackboard solves this by providing a central shared space where agents can publish and consume information asynchronously.

How It Works in Yukkai

Plan-Level Coordination

When a swarm plan is created, the plan itself acts as a blackboard:

1. Architecture phase — An "Architect" agent analyzes the codebase and publishes its proposed structure.
2. Development phase — "Developer" agents read the architecture output from the plan results and implement accordingly.
3. Review phase — A "Tester" or "Reviewer" agent reads all developer outputs and checks for consistency.

This sequential-parallel hybrid is orchestrated through the plan's task ordering and results aggregation.

Results as Shared State

After each agent completes, its output is written back to the plan's shared results. Subsequent agents (or the wrap_up synthesis) can access these results. This is the blackboard in action — each agent contributes its piece to the shared board.

Practical Example

swarm(action: "create_plan", name: "Full Code Review", tasks: [
  { agentRoleName: "Researcher", prompt: "Analyze src/auth/ and document all authentication flows..." },
  { agentRoleName: "Researcher", prompt: "Analyze src/api/ and document all API endpoints..." },
  { agentRoleName: "SecurityReviewer", prompt: "Read the plan results for auth and api analysis, then identify security risks..." },
  { agentRoleName: "Architect", prompt: "Based on all prior results, propose a refactored architecture..." }
])

Here, the SecurityReviewer and Architect agents consume the shared results (blackboard) from the Researcher agents.

Limitations

• No real-time updates — Agents cannot see another agent's output until that agent has completed and results are aggregated.
• Prompt must reference shared state explicitly — Since agents can't browse the blackboard freely, later-phase prompts must instruct the agent to consult prior results.
• Sequential phases — If task B depends on task A's output, they must be in separate swarm plans or ordered sequentially, since a single plan's tasks run in parallel.

When to Use the Blackboard Pattern

• Large refactors — Architect defines structure → Developers implement per-file → Tester validates.
• Multi-perspective analysis — Multiple researchers investigate different aspects → Synthesizer combines findings.
• Pipeline workflows — Each stage consumes the previous stage's output.

For more complex multi-stage coordination with explicit dependencies, consider using Yukkai's Workflow system, which supports topological sorting via dependsOn and an AI-in-the-Middle supervisor for autonomous error handling.