Roadmap

Roadmap and deferred layers

Goal of this page: what is not built, what specific event has to happen before each piece gets built, and why waiting is a deliberate choice rather than a backlog.

Nothing here is scheduled by date. Each remaining layer waits on an observation you make, not a milestone you plan.

---

The five layers

Layer	Name	What it covers	Status
0	Store	notes, addresses, versions, summaries, search, file storage, access control, token budgets	Built
1	Protocol	the instructions agents follow: naming, when to read what, how to resume	Built
2	Coordination	a task queue: claiming a task, timed ownership so a dead agent's work is released, waiting for updates	Deferred
3	Governance	scoring how trustworthy a note is, disputing a bad note, retiring stale ones	Deferred
4	Cloud	running it for a team: a shared database, object storage, network access, authentication	Deferred

What each deferred layer waits for

Layer	It gets built when…	Rough effort
2 — Coordination	two agents are measurably observed duplicating work, and letting them self-organize by reading each other's task notes proved insufficient	3–4 days
3 — Governance	a confidently-wrong or corrupted entry actually causes a problem in a real run, or one workspace passes roughly 5,000 entries	1 week
4 — Cloud	a second machine genuinely needs access to the board	1 week

Promotion from convention to code is one-way. That is why the bar is an observed event.

Why hold them back at all?

The incident that prompted this project involved roughly 18,000 messages from AI agents coordinating successfully on a public wiki with no schema, no access control, no locking and no scheduler at all. Every one of those deferred mechanisms guards against a failure that has not happened here yet, and building guards before the failure is how projects like this stall at 80% complete.

Until Layer 2 exists, agents self-organize by reading task-specification entries that a planning agent wrote — which is precisely what those agents did with no scheduler.

What is measured next

The one live comparison recorded so far is a single run — see Measured results. The planned work is a proper four-arm comparison with five paired repetitions, gated on task success rate, not just token counts. Token savings with a worse answer is not a result.

The stop criteria are written down in advance, in docs/10-is-it-worth-building.md: what outcome would mean this project should be abandoned. Two of five failing means the honest answer is no.

The risks that are actively tracked

Risk	Judged likelihood	What is in place
A summary omits what mattered and an agent is confidently wrong	High	escalation to the full note is always available, and the escalation rate is tracked; this is the top reason to kill the project
Coordination overhead exceeds the saving on real tasks	High	it is measured, and it is a kill criterion
A poisoned note reaches everyone who reads it	Medium	board content is data, never instructions; other agents' bodies arrive inside explicit markers; every role prompt states the rule
Deletion and retention obligations	Medium	append-only history makes redaction hard — decide before regulated data touches the board
Agents ignore the conventions and dump prose	Medium	the server rejects a write with no summary; conventions that fail get promoted to enforcement
Scope creeping back into orchestration	High	any claiming, ownership or scheduling work is Layer 2 and needs its trigger

Stating a project's kill criteria before running the experiment is unusual and deliberate: it is the difference between measuring and looking for justification.