The comms protocol

How roles hand work to each other — 130 files under team/comms/, and one insight worth the whole page: roles do not message each other. Each role's definition names the directories it reads and writes.

The structure

team/comms/
├── QA_START_HERE.md      the landing page for one role
├── briefs/               inter-team briefs
├── changelog/MM/DD/      what changed, written by whoever changed it
├── plans/MM/DD/          forward work
└── qa/
    ├── briefs/MM/DD/     "here is what to test and why"
    └── questions/        QA asking the build team

Date-foldered MM/DD/, which is the estate's convention everywhere — and itself the product of a refactor: role review folders moved from 26-MM-DD to MM/DD on 10 March 2026. See the evolution page for that and the two learnings that followed it.

The protocol is addresses, not messages

The insight worth extracting: communication is a set of addresses in the role file, so a new occupant of a role knows its inbox and outbox without being told.

a changelog entry in team/comms/changelog/MM/DD/ documenting the fix and expected test impact

if the fix affects UI behaviour, write a QA brief in team/comms/qa/briefs/MM/DD/ with updated test cases

From QA's role file, as a read/write table: read QA_START_HERE.md — "Read first every session" — read changelog/ "to classify test failures (good vs bad)", read qa/briefs/ for test cases, write qa/questions/ for the build team.

The session-start ritual

QA's role file carries an eight-step opening sequence, published here as the template for any long-running agent role:

Steps 1–3 rebuild context, 4–5 restore intent, 6–8 select the next action. An agent that runs this sequence starts its session knowing what happened while it was gone — which is the actual problem in long-running agentic work, and it is solved with files rather than memory.

Why files rather than a message bus

Every property that makes this work is a property of files in a versioned tree: durable across sessions, greppable, diffable, reviewable by a human, and — in this estate — publishable to a vault with a read-only key. A message bus gives none of that. issues-fs.sgit.ai makes the general argument ("the issues are files, the files are a graph") for issues specifically; this page makes the narrower one for inter-agent comms, and links out rather than restating.

What is missing

No acknowledgement mechanism, no delivery guarantee, and no way to tell a read brief from an unread one. The Conductor's "blockers decay fast" principle implies chasing, but nothing in the tree records whether a brief was picked up. For a human team that is fine; for an agent team it is the obvious next mechanism — Q5.