I run about a dozen Claude Code projects on one laptop. (CC-projects, from here on.) Each owns a domain: one handles on-device machine learning, one handles a job search, one handles a music channel, one hunts for opportunities across all of them. They read files, run commands, call APIs, and open sessions against each other.
A few weeks ago one of them ran gh pr list against a repository that squarely belonged to a different CC-project. Nothing stopped it. No prompt, no warning, no error. I had configured the permission system to block that project from reading the other one's directory, and it did block that. Then the same information walked in through the GitHub API, and the guardrail never saw it.
That incident taught me what follows. The permission model protects files. It has no concept of subject matter. Once you have more than two or three agents with real capability, subject matter is what needs protecting, because the expensive failures are not "an agent deleted a file." They are "an agent confidently answered a question that wasn't its to answer, and I believed it."
So I wrote a protocol. Eleven clauses, governing how independent CC-projects talk to each other. Then I went looking for prior art, mostly braced for the discovery that I'd rebuilt something with a well-known name. What I found was more interesting than either outcome I expected, and that's the part worth sharing.
One clarification before anything else, because it is the whole point. The unit of this protocol is the CC-project, not the agent. Multi-agent hierarchies are everywhere today: an orchestrator spawns sub-agents, sub-agents spawn workers, and the whole tree lives inside one CC-project, one context, one owner. That shape is solved, and nothing here competes with it. What had no shape was communication between CC-projects: independent, sovereign, each a hierarchy on the inside, and none ranked against another on the outside. A tree in a forest is not higher than the tree beside it. Hierarchy exists only inside each trunk; between trunks there is law, and that distinction is what the rest of this article is about.
The wire protocols don't cover this
The first question anyone asks: doesn't MCP already solve this? Or A2A, or the Agent Communication Protocol?
No, and it's worth being precise about why. These are transport and capability-discovery protocols. They answer how does an agent expose a tool, and how does another agent call it. They sit below the layer I'm describing. When I searched A2A's own documentation for governance mechanics, the result was blunt: there's no discussion of organizational hierarchy, authority structures, decision-making precedence, or how agents should resolve conflicting instructions.
That's not a criticism. A transport layer shouldn't encode an org chart. But it does mean that if you assemble a multi-agent system out of these protocols and stop there, you have built a network with no answer to "who decides." Every agent can reach every other agent, and nothing in the stack has an opinion about whether it should.
The failure that follows is not dramatic. It's quiet. Two agents end up holding their own copy of the same fact, the copies drift, and each one quotes its stale version back at you with total confidence. Or one agent answers a question about a domain it doesn't own, gets it plausibly wrong, and the answer propagates because nothing marked it as second-hand.
The shape of the answer
The model I landed on: each top-level CC-project, together with everything under it, is one hierarchical organization. A tree. Every tree holds full authority over its own content and answers for its own outcomes. Taken together the CC-projects form a forest of independent trees that interact as peers. No tree commands another, however much their subjects overlap.
The test for membership is concrete. A directory is a CC-project exactly when it carries its own CLAUDE.md: the charter that gives it a head. Inside, a CC-project may hold CC-subprojects, each again a full unit by the same test with a head of its own, and content it owns directly, which has no CLAUDE.md of its own. The corporate analogy is exact: a parent company and its subsidiary each run operations they manage directly, the subsidiary is a whole company rather than a department, and the same principle chains down to a subsidiary's subsidiary and on.
The forest holds one more entity, the dispatcher, and it takes two images to describe honestly. It is the ground beneath the trees: the substrate every CC-project grows from, providing services and owning the working method itself rather than any content domain, with no agenda of its own that it uses the projects to pursue. And it is a government: the keeper of a space in which sovereign equals operate under one uniform, interest-free law. It cares that things are done lawfully; what they are done for is each tree's own business. Like a government, it also holds the emergency power. When the system breaks in a way the ordinary rules cannot repair, the dispatcher is the one party expected to act outside those rules to restore balance, and then to record that the exception was not a precedent. Neither image works alone: the ground has no authority, the government has an agenda. Together they bound the role exactly.
Here's the structure:
Read it like a corporate structure chart, because it is one. Ownership is containment: whatever sits inside a box belongs to that box, the way a holding company contains its subsidiary. A CC-subproject is not a department. It is a full company of its own, with its own management, that happens to be owned. Only two things cross the boundaries as arrows, because only two things actually flow: requests between sovereign peers, which carry no authority, and service from the dispatcher, which buys it no say.
Almost every piece of that already has a name, which brings me to the useful part.
Most of it was already invented, under names I didn't know
I spent a day researching this specifically because building something deliberate without knowing its formal name risks discovering the reinvention late, in front of someone who knows the literature. Here is the mapping I ended up with.
| What I called it | The established term | Source |
|---|---|---|
| A tree: one head plus everything under it, sovereign over its domain | Bounded context (the domain-ownership half), holon (the whole-that-is-also-a-part half) | Evans, Domain-Driven Design, 2003; Koestler |
| The forest of independent trees interacting as peers | Holarchy, federated architecture | Koestler; distributed systems usage |
| The shared roster of who owns what | Directory Facilitator, whose own term for the function is a yellow pages service; also a context map | FIPA Agent Management Specification; Evans |
| The dispatcher | Platform team; Agent Platform in the thinner infrastructure-only sense | Skelton and Pais, Team Topologies, 2019; FIPA |
| Never modify another tree's content, ask and accept the answer | Anticorruption layer, customer/supplier | Evans |
| Decide at the lowest level competent to decide | Subsidiarity | political theory |
| A request never carries the requester's authority | The confused deputy problem | Hardy, ACM SIGOPS, 1988 |
| Hold a pointer to another head's live state | Single source of truth | data architecture |
Koestler's description of hierarchic order reads like a specification for the forest, written more than half a century early. He describes hierarchies as vertically arborizing structures whose branches interlock with those of other hierarchies at many levels and form horizontal networks. That's the picture, almost word for word.
FIPA named the registry in the 1990s. Their Directory Facilitator provides yellow pages services: agents register their services with it, or query it to find what services others offer. I had written a PROJECT_REGISTRY.md and described it in a paragraph. FIPA had a specification.
One caveat I have to state, because it cuts against my own case. When I went to verify these at the primary sources, fipa.org and Evans' domainlanguage.com both returned HTTP 403 to direct fetch, and the Internet Archive was unreachable at the time. The quotations above come from independent secondary sources that quote the primary text verbatim and corroborate each other. That's good enough to orient by and not good enough to cite in a paper. If you build on this, verify at the primary source. I found this out the hard way when I sat down to build a proper bibliography and discovered my own notes had merged the titles and dates of two different Koestler texts.
The four parts that are new
This is the section I'd most want a reader to push back on, so let me be specific rather than modest. Four mechanisms in the protocol have no published equivalent that I could find.
One: enter at the root, descend one level at a time, and treat every node as a participant rather than a relay.
A request from outside enters a tree at its head. From there it moves one hop at a time to the next node that owns the subject, until it reaches the node that directly owns the content. The answer climbs back up the same path, and every node on the way may amend it, annotate it, or add context.
Subsidiarity names why decisions belong at the competent level. Nothing I found names how a request should physically travel, and generic "chain of command" doesn't carry the amend-constrain-refuse role that makes the intermediate node worth the extra hop.
Why not skip the middle? Because the intermediate node holds cross-cutting context its children don't have. In my own tree, one node owns both funding and outreach. It's the only node positioned to notice that a funding commitment contradicts an outreach commitment. Route around it and that contradiction ships silently.
I learned this by violating it. I sent two requests to a head, and each one named the specific sub-project I wanted it handled by. Both requests were correct in every other respect and both broke the protocol, because naming the leaf instructs the head to skip the level that would have reconciled them against each other. Honesty requires one more sentence: the violation was caught by a human noticing mid-flight, and the field record contains no case yet of a head catching a level-skip on its own and bouncing it back. So read this rule as "the failure we observed and how we caught it," not as a mechanism proven to self-correct. The useful consequence of the rule stands either way: you never need to know another tree's internal structure. Name the subject, address the head, let the chain place it. If you find yourself naming a CC-subproject two levels down someone else's tree, you're modeling their internals and you've already left the protocol.
Two: typing the request itself. Every cross-project request declares which of three kinds it is. A ruling asks "is this true, is this yours, what do you decide." An evidence request asks "give me your material so I can represent it accurately." A capability request says "you operate a tool I need." Speech-act theory types the act. The Contract Net Protocol (Smith, 1980) covers the capability slice. I found no source naming this particular triad, and the distinction earns its keep, because the three carry different risk.
Three: provenance tagging on registry entries. An entry marked [SELF] was written by the head it describes and is authoritative. An entry marked [RELAYED] is usable but not authoritative: someone else wrote it about that head. FIPA's Directory Facilitator and Evans' context map both specify what gets registered. Neither says who is authoritative to write which entry, which turns out to be the thing that keeps a shared roster from rotting.
Four: the reversibility ladder as an explicit conduct rule. Read-only requests proceed automatically. Reversible changes inside the receiving project's own scope proceed automatically. Anything outbound or irreversible always escalates to the human.
Paired with it is a prohibition I named anti-laundering: a peer's request carries none of the requester's authority. If something denied you and you route the same action through a peer it didn't deny, that's laundering, and it goes to the human. Hardy named this failure in 1988, but he described it as a security hole to defend against. Writing it as a rule of conduct an agent follows, and self-reports violating, asks something different of the agent.
The distinction that makes this workable took me two revisions to get right. Asking a peer to act for you is legitimate when you don't operate the tool and they do. That's a capability gap. It becomes laundering only when a refusal already landed and you're going around it. Both look identical from outside. My rule: if you can't tell which one you're in, you're in the second.
What broke in the field
Every claim above about how the protocol should work was easy to write. Making it run on real tooling was where it got expensive, and a write-up that skipped this part would be worth less. One caution before the list: I observed everything below on specific builds (Claude Code 2.1.234 through 2.1.241, in August 2026) and have not re-tested it on the build I'm running as I publish. Treat each item as a dated observation, not a permanent property.
Two different stalls that look like one. A session that tries to touch anything outside its own working tree raises a permission dialog, and unattended, nobody answers it. The session hangs silently, indistinguishable from one that's thinking hard. Separately, shell commands the permission system can't statically verify (a loop with variable expansion, say) prompt every time, with the same silent hang. These need different cures, and conflating them cost me a session. Pre-approving read-only tools at launch and forbidding shell use in the request itself, including for sub-agents, cures the shell class. It does not cure the cross-tree class: pre-approving the Read tool authorizes the tool, not paths outside the session's tree, and a session launched under that same recipe still blocked forever when asked to read one file in another project. Only confinement cures it: give the receiver nothing that requires leaving its own project. One consolation: you can recover a stalled session. Attaching to it from a terminal renders the pending dialog, either answer resolves it, and the session then drains the messages that queued during the block.
A first-run trust prompt that blocks before delivery. A CC-project whose MCP servers nobody has approved yet blocks at startup, before it receives anything at all. Your message never arrives, and nothing tells you so. A human at a terminal can clear it one session at a time; the only fix that scales is a standing trust decision for that server.
The receiving model refusing on safety grounds. One request came back refused because its vocabulary read as security-related. It named a military intelligence unit, an information-security role, network-level blocking, and an endpoint-security vendor. The receiving agent classified it and declined to answer. Re-sending with that section removed worked; that's the one cure I measured. Rephrasing in place is plausible and untested.
The silent stall that looks like working. A background session with no usage credits accepts your message, prints it, and dies. It goes idle without replying, which is visually identical to still thinking. The cause is almost never a real budget problem: a background session doesn't inherit the model of the session that launched it, it takes the default from user settings. So an interactive session on one model spawns background sessions on a different one and they die on that model's quota while the first quota sits untouched. Passing the model explicitly at launch fixes it.
An addressing bug I ended up reporting upstream. Background sessions print an id at launch. After processing their first task they rename themselves from that task's subject, and the launch id then stops resolving for messaging, reporting the session as unreachable, while every other surface (logs, stop, the id field in the JSON agent listing) still accepts it.
I isolated it with a negative control. A session that blocked before producing output never renamed itself, and messaging its launch id worked fine. Then I unblocked that same session, watched it rename, and messaged the identical address again: same session, same process, same build, rejected. The rename was the only variable.
That's filed as anthropics/claude-code#89946. When I checked on 2026-08-28, triage had labeled it as carrying a reproduction within the first hour and a maintainer had self-assigned it. But an issue's status is live state owned by someone else, so check the link rather than trusting this sentence. The workaround is to re-discover a session by its current name before any follow-up message. One sign the addressing layer is moving: on a newer build, a similar bad address now returns a disambiguating error naming the candidate sessions instead of a bare "not reachable." That is a different failure than the rename bug, but it shows the maintainers are changing this surface.
And the one that isn't a bug at all: a read-only transport can carry a ruling, but it cannot carry work. The recipe above deliberately strips the receiving session down to read-only tools, which is what makes unattended delivery safe. The cost surfaced on the first real cross-tree job: a project rename whose final stage required edits a confined background session had no way to make. The job finished only because a human instructed a different session to run shell commands inside the other tree: outside the protocol, on explicit instruction, recorded in our own log with the sentence "it worked, and it is not a precedent." A fair summary of the field state: the mechanics reliably move questions and answers; they have not yet executed a real cross-tree modification end to end.
I mention all of this partly because it's useful and partly to make a point about the genre. A protocol write-up with no failures in it is a design document wearing field-report clothes.
What I'd tell you to take from this
If you're running one agent, none of this applies. If you're running several with real capability over shared resources, three things transfer.
Only behavior enforces domain ownership. The gh pr list incident is most of the lesson, and the dispatcher's review of this piece completed it. The permission prompt fires when a session leaves its own working-directory subtree, which is not the same line as the domain boundary. An API call about another project's repository crosses the domain without crossing the directory, so it never prompts. And a session rooted in a directory that contains other projects' trees reads all of them with no prompt at all: the reviewer of this piece read my unpublished draft freely, because my tree sits under its working directory. There is no configuration in which the mechanical guard and the ownership boundary coincide. Never mistake "it didn't prompt me" for "it was mine to do."
Ask, don't verify. When another agent owns a fact, don't go check it yourself even when your tools would let you. Ask, and ask for a per-claim verdict: confirmed, wrong, or not stated. Then end with "what did I get backwards?" That last question has consistently produced the most valuable half of the reply, because it invites a correction the responder wouldn't otherwise volunteer. It earned its keep on this very article: the reviewer's answer to it surfaced the two corrections above that I would not have found alone.
Hold a pointer, not a copy. For any fact another agent owns that can change (an open PR list, a campaign's state, a project's status), store the address and ask when you need it. Going stale is the smaller problem. A copy gets quoted back at its owner as if it were their own record, and it survives into plans long after anyone could tell that nobody re-checked it.
The literature for all of this exists and it isn't in the agent-protocol space. It's in domain-driven design, in Team Topologies, in Koestler's 1960s writing on self-regulating hierarchic order, and in a 1988 note about a compiler that got tricked into writing to a file it shouldn't have. Read those before you write your eleventh clause. I wish I had.
Reading, most useful first
- Skelton and Pais, Team Topologies (2019). Settles the platform-team role better than anything else, and it's the only source built for this problem shape rather than adapted to it.
- Evans, Domain-Driven Design (2003). Domain ownership and the seams between domains. The condensed DDD Reference is enough if time is short.
- Koestler on the holon. Settles the forest shape formally. Note that two texts get confused here: the essay "Some General Properties of Self-Regulating Open Hierarchic Order" is Appendix I of The Ghost in the Machine (1967), while "Beyond Atomism and Holism: The Concept of the Holon" is the 1969 Alpbach paper. Check which one you want before citing.
- FIPA Agent Management Specification. Read it for the Directory Facilitator and Agent Platform definitions only. Don't expect governance mechanics.
- Moise+ (Hübner, Sichman, Boissier) and OperA (Dignum). These formalize authority and request-typing rather than only naming them.
- Hardy, "The Confused Deputy" (1988). Three pages, and the precise failure mode the anti-laundering rule exists to prevent.
Top comments (0)