The Code Agent Orchestra
Modules 05-08 taught you to run one loop well. This is the other axis: what changes when you're not running one agent anymore, but a small team of them — each with a scope, a file to own, and a way to check each other's work.
One agent has a ceiling. Here's where it is.
A single agent working alone runs into the same three walls no matter how good the underlying model gets:
A real codebase doesn't fit in one context window. Past a certain size, the agent is working from a blurry partial picture of your system, not the whole thing.
One generalist agent trying to be your database designer, your test writer, and your API author at once is worse at each of those than a few agents each given one job and a tight brief.
Just opening three terminal tabs and running three agents doesn't fix anything if they can't message each other, don't know what the others already did, and might edit the same file at once.
You used to pair with one agent. Past a certain size of work, the job changes to managing a small team of them — which means the skill that matters shifts too: less "write the code," more "write the spec, divide the work, and verify the result." (Addy Osmani, The Code Agent Orchestra)
Subagents: delegate by file ownership
The entry point — zero setup, works today — is what this environment already calls a subagent: you, the orchestrator, break one task into independent pieces and hand each piece to a child agent with a scoped brief and a clear file to own. This is exactly the Task tool with subagent_type already available in every Claude Code session.
# One brief, no ownership, no file scope
"Build the link-shelf feature."
# Three agents, same files, no coordination
# → merge conflicts, duplicated work,
# nobody knows what's already doneAgent A — data layer. Owns the schema + CRUD operations. Reports back what it built.
Agent B — business logic. Owns validation rules. Independent of A — runs in parallel.
Agent C — API routes (dependent). Reads A's and B's reports, then wires the Express routes. Only starts once A and B report done.
A subagent can spawn its own specialists — a "feature lead" that breaks its slice into smaller pieces and delegates those too. That gives you deeper decomposition without dumping all of it into your own context, the same way a real engineering org has leads who manage their own reports instead of everyone reporting to one person.
The trade-off: you're still the one holding the dependency graph in your head. Subagents can't message each other directly, there's no shared task list, and if you don't give each one an explicit file to own, two of them can edit the same file without knowing it.
Teams: agents that coordinate with each other
The pattern one level up isn't parent calling child — it's independent agents running side by side, coordinating through shared state instead of through you relaying every message. Three parts make it work:
Decomposes the work, writes the task list, and synthesizes the result at the end. Doesn't relay every message between teammates — that would make it the bottleneck.
Tracks each task's status — pending, in progress, completed, blocked — encodes which tasks depend on which, and locks files so two agents can't edit the same one at once.
Independent agent instances that self-claim the next unblocked task and message each other directly — peer to peer — when one needs something from another.
A dependent task auto-unblocks the moment its prerequisite finishes. Watch three teammates — Backend, Frontend, Test — build one search feature at the same time:
3-5 teammates is the sweet spot — cost scales roughly linearly with headcount, and a few focused agents consistently beat a crowd of scattered ones. Add a dedicated reviewer teammate — read-only, only given lint/test/security-scan tools, triggered on every task completion — at roughly one reviewer per 3-4 builders. The lead only ever sees reviewed, green work.
Trust but verify: the gates that make a fleet safe
As agents get faster at generating code, the bottleneck stops being generation and becomes verification — knowing with confidence that what a fleet of agents produced is actually correct. Three gates carry most of that weight:
A teammate writes an implementation plan first; the lead approves or rejects it before any code gets written. Cheaper to fix a bad plan than to fix bad code built on it.
A hook fires automatically on events like a task completing or an agent going idle: block the agent from stopping until its tests pass, or rerun lint on every completion and keep it going if something fails.
Every agent reads it at session start; every session is expected to add discovered patterns and gotchas to it. In this stack that's CLAUDE.md and the auto-loaded MEMORY.md — the same idea the source article calls AGENTS.md.
Cited research (Gloaguen et al., ETH Zurich) found a machine-generated version of this shared file gave no real benefit — roughly a 3% drop in task success, plus 20%+ higher inference cost — while a human-curated version showed a genuine ~4% improvement. Treat every line an agent proposes for CLAUDE.md or MEMORY.md as a suggestion for you to approve, never a direct write.
Ambiguity is the other multiplier to watch. A vague spec run through one agent slows you down; the same vague spec run in parallel across a fleet produces several different wrong answers at once, each burning its own budget. Precise specs are what let a fleet add leverage instead of multiplying mistakes — which is also why architecture, "what NOT to build," and full-context review stay jobs for a human, not a delegation.
The lasting idea here is role separation plus verification-as-the-bottleneck — that will still be true regardless of which vendor wins. The named products (specific local-orchestrator and cloud-agent tools, an experimental team-mode flag) are 2026-era branded tools, several marked experimental by their own makers, and will likely look different within a year or two. Treat this module's tool names as illustrations of a pattern, not a fixed toolchain to chase.
Check yourself
Three questions on subagents, teams, and the gates that keep a fleet honest.
You spawn three subagents via the Task tool for a feature — one owns the schema, one owns validation, one (dependent on both) owns the API routes.
What's the real limitation of this pattern compared to an agent team?
In a three-teammate build (Backend, Frontend, Test), Backend finishes the API endpoint. Seconds later, Test's blocked task starts running and Frontend already has the API contract.
What made that happen?
Your team's shared memory file (CLAUDE.md / MEMORY.md) has been getting long, and an agent offers to "clean it up and add today's learnings" on its own.
What does the cited research say you should actually do?
Next time a task splits cleanly into pieces, don't run it as one long session — spawn subagents with a file each, and write the dependent one's brief to explicitly read the others' reports first. That's the whole pattern, no experimental flags required.