Blackboard or Mailbox: How Should Three Agents Share What They Learn?

Three research agents are compiling a supplier brief. One reads filings, one reads news, one reads the support ticket history. Agent A establishes that the vendor moved its primary data center in March. Agent B, forty seconds later, spends eleven tool calls establishing the same thing. Agent C finds a ticket saying the migration was cancelled — and tells nobody, because nobody asked it.

All three failures come from one unmade decision: how the agents share what they learn. There are two basic shapes, and picking the wrong one for your workload is expensive in a way that shows up as "the agents are dumb" rather than "the topology is wrong."

🧩 The two shapes

Mailbox (message passing). Each agent has private state. When it has something another agent needs, it sends it — usually back through a supervisor, sometimes peer-to-peer. Nothing is visible until it is explicitly transmitted.

Blackboard (shared store). There is one structured store all agents can read and write. Agents post findings as they go; anyone can read the current state at any time. Nothing needs to be addressed to anyone.

These are not just implementation details. They change what each agent is capable of noticing.

📬 What the mailbox actually costs

The mailbox is the default in most orchestration frameworks because it maps cleanly onto function calls and it is easy to trace. Its real costs are less obvious:

• Duplicated work is invisible. Agent B cannot know Agent A already did something, because A's intermediate state was never addressed to B. You pay for the same research twice and often get two slightly different answers to the same question.
• Routing becomes a job. Somebody — usually the supervisor — has to know that the ticket agent's finding is relevant to the filings agent. That routing logic is a second, undertested system living in prompt text.
• Contradictions never meet. Agent C's cancelled-migration ticket contradicts Agent A's conclusion, but the two claims are never in the same context window, so no model ever has the chance to reconcile them. The contradiction surfaces in the final report, or worse, doesn't.

What you buy is real, though: isolation. One agent's confused reasoning cannot leak into another's context. Failures stay local, retries are clean, and the trace is a tree you can read top to bottom.

🗂️ What the blackboard actually costs

A blackboard fixes the noticing problem and introduces two of its own.

Context bloat. If every agent reads the whole board every turn, your token cost grows with the square of the work. Ten agents each posting ten findings, each read by everyone, is a hundred reads of a growing document. The fix is not "read less" but structure: typed slots that agents query rather than a transcript they scroll.

Poisoned entries propagate. In a mailbox, one hallucinated fact damages one downstream consumer. On a blackboard, it becomes shared ground truth in seconds, and every agent that reads it afterward reasons on top of it. Isolation was doing work you only appreciate once it's gone.

⚠️ Do not let agents write free-form prose to a shared board. That is a group chat, and it fails the same way group chats fail: volume, no schema, no way to tell a claim from an aside.

💡 The deciding question

Ask one thing: is the work partitioned or overlapping?

Partitioned work — each agent owns a disjoint slice, outputs compose mechanically — wants a mailbox. Three agents writing three independent sections of a document have nothing useful to say to each other mid-flight. Sharing state just adds noise and cost.

Overlapping work — agents investigating the same object from different angles, where one's discovery changes another's next step — wants a blackboard. The supplier brief is overlapping: filings, news, and tickets are three views of one entity, and a finding in any of them should redirect the other two.

Most real systems are mixed, which is why most mature ones end up hybrid: a blackboard for facts, a mailbox for requests.

🔧 What a disciplined blackboard looks like

The version that works has a schema, a claim mechanism, and provenance on every entry.

board.write(
    key="datacenter.migration",       # typed slot, not free text
    value="primary DC moved to eu-west-2",
    confidence=0.7,
    source="10-K filing, p.42",       # provenance is mandatory
    author="filings-agent",
)

# Before starting expensive work, claim it.
if board.claim("datacenter.migration", by="news-agent", ttl=120):
    ...  # nobody else duplicates this for two minutes
else:
    ...  # someone is on it; read their result instead

Three properties make this work where a shared transcript doesn't:

1. Typed slots mean an agent reads the four keys it cares about, not the whole history. Cost stays linear.
2. Claims kill duplicate work directly — the thing the mailbox could never do.
3. Provenance and confidence mean a conflicting write is a detectable event. When Agent C writes to datacenter.migration with a source that disagrees, you have a conflict record, not a silent overwrite. Route conflicts to a reconciler or a human; never let last-write-win decide a fact.

The naive version — one big shared markdown scratchpad everyone appends to — gets all the costs and almost none of the benefits. It bloats, it has no claims, and it has no schema against which to detect a conflict.

🔍 A quick diagnostic

Pull one multi-agent trace and count two numbers: how many tool calls retrieved information another agent had already retrieved, and how many claims in the final output are contradicted somewhere in the intermediate traces. High on the first means your agents can't see each other and want a board. High on the second means they can see each other but nothing arbitrates, and you need conflict detection before you need more agents.

Adding an agent to a system that shares state badly makes both numbers worse. Topology first, headcount second.