-
Notifications
You must be signed in to change notification settings - Fork 0
Multiple Agents
Goal of this page: what the board does and does not help with when one session fans out into helper agents, background commands and monitors — and the order in which to reach for fixes.
The flat resume figure on the home page is about crossing a session boundary: a new agent, later, picking up where the last one stopped.
A single session that fans out has a second, separate problem: everything its helpers say back lands in its history and is re-sent on every later turn. A helper that replies with a 9,000-token report has not just cost 9,000 tokens once — it costs them again on every turn for the rest of the session.
The board helps with part of that and not all of it. Being clear about which part is the difference between saving context and adding overhead.
| What produced the output | Does the board help? | What actually helps |
|---|---|---|
| A helper agent's findings | Yes — this is the real win | the worker writes a summary to its own address; the parent reads ~200 tokens instead of a full report that then persists all session |
| A background command's log | Only if it never entered the context | cap tool output at the client level so long output spills to a file automatically, or redirect it and file it with source_path
|
| A monitor notification | No | make the condition return a count, one line, or an exit code, then read only the matching lines |
| A tool result already in the context | No | nothing. It is paid for. Filing it afterwards is bookkeeping, not a saving |
client output caps → condition hygiene → hooks → the board
Hooks sit third because they can prevent a flood — deny a call, rewrite its input, or run a check on a smaller model so the main context never reads the evidence — but they cannot shrink a result that has already arrived. The board sits last because it addresses only the case where a helper's output is about to enter the parent's context and can be replaced by an address plus a summary.
- The parent writes the shared background to the board once, and hands each helper an address instead of the content.
- Each helper writes its result to its own address — one writer per address,
so no two helpers collide. Give each a distinct lane, for example
bb://ws/tasks.coverage/result/exp1. - Each helper replies to the parent in about three lines: status, the address it wrote, and the headline.
- The parent reads the summaries. Full bodies stay on the board, addressable if a decision actually needs them.
Measured on one live five-agent run of this shape: parent context 36,766 → 2,357 tokens (−93.6%), total spend across all agents −38.7%, wall clock on the slowest agent −22.2%, and 20,895 tokens of full findings still kept on the board for the 1,400 tokens it cost to read five summaries. One run, n=1 — Measured results states plainly what that does and does not establish.
Every helper loads roughly 2,600 tokens of protocol instructions and tool descriptions before it does anything, and every agent pays 469 tokens of tool descriptions per turn whether or not it uses the board. Below roughly five sub-tasks that overhead exceeds the saving.
A single session does benefit as soon as it fans out to helper agents — the boundary that matters is agent-to-parent, not session-to-session. It does not benefit from monitors or hooks, whose output reaches the parent as ordinary tool results the board never sees.
| File in the repository | Covers |
|---|---|
skills/blackboard-parallel/SKILL.md |
this page as an instruction sheet for an agent, with the specific client settings, lane naming for concurrent writers, and the break-even |
skills/session-handoff/SKILL.md |
parking a task and resuming it in a fresh session |
integrations/claude-code/SETUP.md |
the deterministic plumbing: a contract stated on every spawn, and a worker whose tools are scoped to the board |
The adapter matters because it makes the contract automatic. Without it, whether a helper follows the protocol is decided by the model each time.
Every number in this wiki is either measured and cited, or labelled a target — the same rule the repository's documentation standard applies to itself. Source, tests and design notes: TapanManu/blackboard.
Start here
Understanding it
Evidence
Direction