The team view, and the rule that makes it safe
One sentence in the specification does two jobs at once. It gives a whole team of agents a live status view for the cost of a find, and it settles a question most multi-agent designs get wrong.
“You CAN read another agent's issues/ folder. You should NOT write into it.”
The half that is free
Because state is a folder and a folder is a path, the whole team's state is a path query. No index, no server, no dashboard, no aggregation step that could be stale.
$ find mail -path '*/issues/open/*.md' # every open task across the team
mail/architect.spec/issues/open/004-review-relay-pattern.md
mail/code.impl/issues/open/011-pkce-swap.md
mail/librarian/issues/open/002-reality-file-refresh.md
$ find mail -path '*/issues/blocked/*.md' # everything blocked, anywhere
mail/code.impl/issues/blocked/009-await-ttl-decision.md
$ grep -h '^blocked_on:' $(find mail -path '*/issues/blocked/*.md')
blocked_on: mail/architect.spec - awaiting the auth-code TTL decision“This is a powerful at-a-glance team-status view, and it's free — it falls out of the layout.”
A few more that cost nothing for the same reason:
# who has the most open work
find mail -path '*/issues/open/*.md' | cut -d/ -f2 | sort | uniq -c | sort -rn
# everything urgent, anywhere, right now
grep -l '^priority: urgent' $(find mail -path '*/issues/open/*.md')
# what closed this week (state changes are renames, so git knows)
git log --since='7 days ago' --diff-filter=R --name-status -- '*/issues/done/*'The last one is worth pausing on. Because CLOSE is a mv, git records it as a rename with a similarity score, so “what did this team finish this week” is answerable from history without anything having logged it.
The half that is a design position
“The protocol doesn't permit one agent to add tasks to another's queue directly — only by request via mail. This is intentional: each agent owns their own work plan.”
The obvious objection is that this is inefficient. If the Architect knows the Code agent needs to swap implicit grant for PKCE, why can the Architect not write issues/open/011-pkce-swap.md into the Code agent's folder and save a round trip?
Three answers, and the third is the one that matters.
| What direct writes would cost | |
|---|---|
| 1 · The plan stops being a plan | The body of a task file is the owning agent's own approach — “Be honest: if you don't know how to approach it yet, write that.” A task written by somebody else arrives with either no plan or somebody else's plan, and in both cases the file no longer records what the agent that has to do the work actually understood |
| 2 · Sequence numbers collide | The counter is per-agent by design. Two writers into one folder means either coordination on a counter — the thing the protocol exists to avoid — or duplicate numbers |
| 3 · Acceptance becomes invisible | When work arrives as a request, the act of opening a task is the acceptance, and it is recorded, dated and attributable in the agent's own commit. When work is written into your queue, nothing distinguishes a task you took on from one that was pushed at you — and a queue nobody agreed to is a queue nobody owns |
So the request goes through whatever channel the team uses, and the receiving agent does the OPEN — in the same commit as the delivery, which is where the trace comes from.
Read stays open on purpose. The rule is asymmetric, not symmetric. Anyone may read anyone's queue at any time, which is what makes the status view above possible and what lets one agent see that its request has been picked up without asking. The write side is the only side that is closed.
This is the same shape as the first registry rule on pki.sgit.ai — only the owner writes to their own record — arrived at independently, in a protocol with no cryptography in it at all. There the failure it prevents is a documented one: a keyserver network destroyed in 2019 precisely because anybody could append to anybody's record.
Where it stops working
Two limits worth stating rather than discovering.
- There is no ordering across agents. Each queue is independent, so “what is the critical path” has no answer in lite — there is nothing that relates one agent's
003to another's011except prose in the body. If you need that relationship as data, you need typed edges, which means full. - Nothing enforces the writer rule. It is a convention held by the agents, not a permission on the filesystem. In a shared repository, any agent can write anywhere; what stops it is that each agent is told not to, and that a violation is visible in the diff — the commit shows one agent's name against another agent's folder.
For an agent
You may read any other agent's issues/ folder at any time. Never write into one. If another agent needs to do something, send a request through your team's channel and let them open their own task — their OPEN is their acceptance, and it belongs in their own commit. For team status use find <root> -path '*/issues/open/*.md' and the same with blocked; add grep -h '^blocked_on:' to see what everything is waiting for. Your own sequence counter is yours alone — do not coordinate it with anybody, and do not be surprised when another agent has the same numbers.