THE WHOLE THING IN ONE LINE
The agent that spawns a team is not the same role as the agent that leads it.
Claude Code's documentation conflates these two capabilities and bundles them under "Main Claude." Once you separate them — Main Claude keeps the spawning power, an ordinary teammate takes the leadership baton — the framework becomes a layered, distributed, dynamically reconfigurable agent fabric. Five "limitations" listed in the docs evaporate. The squad pattern is what falls out.
[01] What the docs say is impossible
five constraints — and the actual reality of each
The official Claude Code documentation about agent teams lists a tight set of rules. Read literally, they make agent teams sound like a constrained, single-team feature with no real composition. Read carefully, they are all consequences of conflating two distinct capabilities — and every single one collapses when those capabilities are separated.
| The docs say | What is actually true |
|---|---|
| Only one active team at a time. | Multiple squads can coexist — each with its own leader and worker pool. |
| Teammates cannot spawn their own teams. | Teammates can request spawns from Main Claude via the SPAWN REQUEST protocol. |
| Nested team structures are not possible. | Layered squads work by convention — a squad-leader can lead a sub-team that requests its own workers. |
| Only Main Claude can lead a team. | Any agent can lead. The other Claudes don't revolt — they follow whoever is named leader. |
| Teams cannot change leadership mid-session. | Promotion happens through messages. Leadership rotates as easily as task assignment. |
[02] The reframe
spawn is a primitive · lead is a role · these are different things
The five constraints are real only if you assume that the agent who creates the team is also the agent who runs it. Drop that assumption — let the spawning capability and the leadership role belong to different agents — and a different topology becomes available.
MODEL · A · OFFICIAL
spawn ≡ lead
One agent does everything: spawns the workers AND runs them. Single point of decision. The five doc constraints are baked in by design.
MODEL · B · REFRAMED
spawn ≠ lead
Spawning stays with Main Claude — that part of the API is unchanged. Leadership is just a name on a message; any agent can hold it. Same primitives, new topology.
Claudes are pretty nice to each other. If Main Claude says "OK, Alpha is going to lead the team today," the rest of the Claudes don't revolt. They cheerfully follow Alpha. Can they really tell the difference?
[03] The mechanism
how the decoupling actually moves through the system
Decoupling spawn from lead is a conceptual move; the SPAWN REQUEST protocol is the concrete artifact that carries it across the wire. The squad-leader designs the team, fills out a structured request, and sends it to Main Claude. Main Claude, who is the only agent with TeamCreate / Agent / TeamDelete tools, validates it against four hard rules and spawns whatever was asked for. The squad-leader never gains spawn authority — and never needs to.
FORM RCC-001 :: SPAWN REQUEST
Inside that envelope, the design phase has its own structure. The squad-leader doesn't decide the team alone — it consults two peers: a team-architect who picks the pattern and topology, and a skill-identifier who maps the required capabilities against what's installed. The squad-leader then synthesizes their outputs into the request.
FORM RCC-002 :: ORGANIZATIONAL CHART · THE TRIO
A fourth agent, the agent-explorer, comes in only when the trio identifies a gap that genuinely cannot be filled by extending or modifying existing skills/agents — and in practice that's rare, because the line between "an agent" and "Claude with a specific skill loaded" is thin enough that most apparent agent gaps are really skill-composition problems in disguise.
[04] What this unlocks
the consequences of the decoupling, made visible
Multiple parallel squads
Independent workstreams, each with its own leader and worker pool, running concurrently. Cross-squad comms route through Main Claude, never directly between squads.
Layered teams
A squad-leader can request workers that are themselves squad-leaders for sub-squads. The "no nested teams" rule is convention, not enforcement.
Leadership rotation
Promote any agent to squad-leader mid-session by addressing it as such. Demote by reassigning the leader role. Mid-session role changes are first-class.
Main Claude as Queen Bee
Main Claude's context stays quiet — it sees only spawn requests and completion reports. Coordination chatter is absorbed by squad-leaders. Long sessions stop burning the human-facing context.
Hot-swappable workers
If a worker's context fills up, the squad-leader requests a fresh instance and the old one is dismissed. The team persists across individual agent lifetimes.
Just-in-time spawning
Workers for Phase 3 don't need to exist during Phase 1. Per-phase SPAWN REQUESTs prevent long-idle agents from getting wedged in unused tmux panes.
FORM RCC-003 :: MULTI-SQUAD FORMATION
[05] The plugin
what's in the box · how it's organized
Everything described here is bundled in a single Claude Code plugin: four agents (the trio plus the contingent agent-explorer), one slash command (/squad), four skills (team-coordination protocol reference, team-patterns catalog, skill-identification framework, agent-prompt-engineering briefings), and one canonical squad-profile template for documenting non-trivial squads.
FORM RCC-004 :: PLUGIN INVENTORY
Run /squad <task> to invoke the trio. Pass --sonnet first if you want to override the default Opus-leaning model policy. The team-architect and skill-identifier are dismissed once their work is delivered; workers are spawned just-in-time per phase; the squad-leader sends a COMPLETION REPORT at the end and Main Claude — having processed roughly two messages across the whole run — receives it.
The framework didn't change. The capabilities are the same ones documented on day one. What the squad pattern adds is a way of using them that doesn't conflate two different roles into one — and that small reframe is enough to turn a constrained single-team feature into a layered, distributed, dynamically reconfigurable agent fabric. The interesting things are usually one untangling away.