Skip to content

Multiple Agents

TapanManu edited this page Sep 8, 2026 · 1 revision

Working with 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.


Two different boundaries

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

The order to reach for things

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 pattern that works

  1. The parent writes the shared background to the board once, and hands each helper an address instead of the content.
  2. 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.
  3. Each helper replies to the parent in about three lines: status, the address it wrote, and the headline.
  4. 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.

Where the break-even sits

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.

The instruction sheets

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.

Clone this wiki locally