Agent A edits one thing. Agent B edits the same thing. Outputs conflict, shared files drift, and you burn the time parallelization saved on untangling the mess.
Most multi-agent failures are not intelligence failures. They are ownership failures. The system never decided who owns what.
I avoid this with one prompt rule: if any two tasks touch the same work, do not spawn separate sub-agents. The coordinator handles that territory itself.
I call it Territorial Agent Orchestration - TAO.
The failure mode
Once agents get capable enough to spawn other agents, the naive move is obvious: parallelize everything. Sounds efficient. It usually is not.
Raw generation quality is usually fine. What breaks is ownership. The common failure mode:
- one agent edits shared types
- another agent edits the same shared types indirectly
- a third agent builds integration against stale assumptions
- the coordinator now has to reconcile inconsistent slices
That is where the token burn starts - in the cleanup, not in the work itself.
The pattern
TAO is one rule plus one role.
The rule:
If any two tasks touch the same work, do not parallelize them into separate agents.
The role:
The main agent is the coordinator. It owns shared territory and all integration points.
So before spawning anything, the coordinator has to reason about the task graph first:
- map what each task touches
- identify overlap
- isolate exclusive slices
- keep shared territory for itself
- spawn sub-agents only for clean, non-overlapping slices
A real run
I gave an agent a fairly complex project. Multiple moving parts, shared types, integration points. Plenty of places for a naive swarm to step on itself.
The agent reasoned about structure first:
Clean separation: each module depends only on shared types, enabling parallel development.
Then it made the right call:
I am the coordinator. I will handle the integration points after agents finish their isolated slices.
Then it spawned seven sub-agents in parallel on isolated slices.
7 task agents launched
├─ Agent 1: Slice A
├─ Agent 2: Slice B
├─ Agent 3: Slice C
├─ Agent 4: Slice D
├─ Agent 5: Slice E
├─ Agent 6: Slice F
└─ Agent 7: Slice GWhile those ran, the main agent kept the shared work: shared types and validation, integration logic, wiring everything together.
The output was exactly what you want from a multi-agent session:
- seven agents working in parallel on isolated pieces
- main agent handling seams and shared state
- zero conflicts by construction
Zero conflicts. By construction, not by cleanup.
Why it works
Each sub-agent gets exclusive ownership of one slice. No overlapping write surface. No shared mutable state between sibling agents.
The coordinator owns the seams: shared types, integration logic, connection points, final assembly.
When territories do not overlap, conflict resolution stops being a runtime problem. It becomes a design property.
The standard multi-agent mindset is to let agents run, detect collisions later, and resolve conflicts after the fact. TAO flips the order: design ownership first, spawn only on isolated slices, make collisions structurally impossible.
The best systems do not rely on heroic cleanup. They make the right outcome easier than the wrong one.
The three rules
TAO reduces to three rules.
1. Territory Rule
One agent per non-overlapping slice.
If a slice is isolated, it can be delegated safely.
2. Overlap Rule
If two tasks touch the same work, they should not be split across independent sub-agents.
Either the coordinator handles both, or one agent owns both.
3. Coordinator Rule
The main agent owns all shared context and all integration points.
Sub-agents can read shared context. They should not own or mutate the seams.
So the hierarchy stays simple: the coordinator owns shared state and final integration, sub-agents own isolated slices, and overlap stays centralized.
The prompt pattern
The whole thing as a prompt:
You can spawn sub-agents for parallel work. Before spawning:
1. Map what each task touches
2. Identify overlapping territories
3. For isolated slices: spawn a sub-agent with exclusive ownership
4. For overlapping work: handle it yourself
5. You own all integration points and shared context
Rule: If any two tasks touch the same work, do not spawn
separate agents. Either handle both yourself, or spawn
one agent to handle both.
You are the coordinator. Sub-agents own slices.
You own the seams.It works because it forces architectural reasoning before delegation. The model stops asking “what can I parallelize?” and starts asking “what can I safely parallelize without creating ownership ambiguity?”
Beyond agents
This idea is bigger than AI agents. You see the same structure everywhere:
- database sharding works because each shard owns exclusive data
- Kubernetes controllers work because ownership is explicit
- good team design works because boundaries are clear
If autonomous systems are going to coordinate other autonomous systems, they need an ownership model. TAO is one, and it fits in a single prompt. Instead of trying to make agents smarter after the fact, it gives them a principle for self-organization up front.
One rule. Much less chaos.