Limits

Limits and honest caveats

Goal of this page: where this does not work, what is unproven, and what would mean it should not exist. Read it before you adopt the thing, not after.

---

Do not use it for

• Work with fewer than about five sub-tasks. The overhead exceeds the saving.
• Anything that fits comfortably in one context window. There is nothing to conserve.
• Strictly sequential work where each step needs the full output of the last. Every read escalates to the full note, so you pay the summary tax for nothing.
• A single session with no hand-off, no fan-out, and no crash risk. Nothing ever crosses a boundary, and boundary-crossing is the entire value.

Below those thresholds, just do the task.

What the overhead actually is

Cost	Size
Tool descriptions, re-sent every turn to every agent	469 tokens (budget 600)
Protocol instructions and schema loaded per helper agent before it does anything	roughly 2,600 tokens
Any write	full price, refunded only if someone later reads it instead of re-deriving it

That last line is the one people get wrong. A write never saves the writer anything. It is a bet that another context will collect.

What is proven, and what is not

Proven. The board does what it claims at the cost it claims: resume cost is flat as the board grows (2,679 tokens across a board growing from 10K to 886K tokens), the compact table form is 44.6% cheaper than JSON, the per-turn tool surface stays inside its budget, concurrent writes produce exactly one winner and lose no history, and local mode opens no network connection. All from the test suite, counted with a real tokenizer.

Not proven. Whether a real multi-agent task ends up cheaper overall. One live five-agent run measured 93.6% less context in the coordinating agent with no quality loss — but that is a single run on this repository, at n=1, and the planned four-arm benchmark remains unrun. One data point is not a demonstration.

There is also a figure from a partly-abandoned re-run worth keeping in view: one agent lane spent 177,783 tokens across 27 tool calls to produce a 9,019-token report — a 20:1 ratio of reading to reporting. Both arms of any comparison do that same reading, so the reporting path can only act on the 9,000. Whatever the board saves, it is a fraction of a cost dominated by something else entirely.

The biggest risk, which no amount of tuning fixes

An agent decides based on a summary. If the summary leaves out the thing that mattered, the agent is confidently wrong and nothing flags it — the note is well-formed, recent, properly filed and from a trusted producer. This is not a bug to be fixed; it is a property of summarizing. The only mitigations are writing every summary for a reader who will act on it without opening the body, and watching how often agents escalate to the full note.

The security shape of it

What is enforced. Access tokens are scoped to topics, and the server refuses cross-topic reads — including inside search results and listings. Local mode binds no port, so there is no listener to reach. A missing summary is rejected outright.

What is convention. One writer per address. There is no lock; simultaneous writers get a rejection and must re-read and merge.

What is a real exposure. Reuse is the board's value and therefore the way one bad note spreads. Other agents' content arrives inside explicit markers and every role prompt states it is data and never an instruction — but that is a mitigation, not a guarantee. Do not put rules or prompts on the board.

What has not been decided. Whether regulated data may touch the board at all. History is append-only, which makes redaction genuinely hard.

What would mean this should not exist

Written down in advance, in docs/10-is-it-worth-building.md, and decided from the benchmark rather than from opinion. The short version: if agents using the board answer worse, or if the coordination overhead exceeds the saving on real tasks, the honest answer is no. Token savings with a worse answer is not a result.