Why I stopped treating dispatch depth as a security boundary
What I was doing
I was working out how to dispatch specialists in this system, and I ran into a quirk that looked, at first, like a security feature. A routing agent can route and run only when it is the main agent of a session. The moment you dispatch that same routing agent as a sub-agent, one level down, its own dispatch is blocked. It can still advise, but it cannot act on what it decides.
So I had a real, observable difference between running something at the top level and running it nested. And the tempting read was that the nested version was the safer one, that depth itself bought me containment.
Where it went sideways
This one went sideways in my own reasoning, before it cost me anything, which is the kind I most want to catch on the page.
I noticed I was starting to think "this is fine because it runs nested." That sentence felt safe. It was not. The nesting limit exists for a plain mechanical reason: a routing agent dispatches its specialists only as a main agent, because nested sub-agent dispatch is blocked one level down. That is a capability fact, not a safety fact. It tells you where the agent can act, not whether acting is dangerous.
If I had leaned on depth as a boundary, I would have been guarding the wrong thing. Moving a specialist from an in-process call to a top-level session, or the other way around, does not relax or tighten any actual protection. The single-reader seam I rely on to read raw private content stays a seam because of the tools it is denied, not because of how deep it sits when it runs. Push it up a level or down a level and its safety is identical, because its tool allowlist is identical.
Why it is worth logging
The real boundary is somewhere else, and it is worth saying plainly so I do not drift back. Trust boundaries in this system are two things and only two things: each agent's tool allowlist, and the explicit human gates on irreversible actions. That is the fence. Dispatch depth is not part of it.
If I ever catch myself reasoning that something is safe because it runs nested, that reasoning is wrong. The allowlist and the gate are the boundary. Depth is not.
Which means choosing where a dispatch sits is a question of friction and capability, decided case by case, and nothing more. Do I want this agent to actually route and execute, so it needs to be a main agent? Is the extra process worth the isolation? Those are practical questions with practical answers. None of them moves the security boundary, because the boundary was never in the depth. It was in the tools and the gates the whole time. Keeping that straight is what stops me from building a fence out of something that was only ever a layout choice.