Anyone who's tried to push a single Claude session through a long, complex task has felt the same wall. The agent starts strong, makes real progress, and then somewhere around hour two the quality slips. Context starts crowding out reasoning. Tool decisions get noisier. The agent forgets what it knew an hour ago. The fix that everyone tries first — bigger context windows, more aggressive compaction — helps at the margin but doesn't change the underlying shape of the problem.

The teams that have actually solved this didn't make their one agent bigger. They split it into many. A planning agent that decides what needs to happen. An exploration agent that scopes the work. Specialized execution agents for each kind of task. A reviewer agent that checks the output. Each one with its own narrow context, its own tools, its own prompt. They coordinate through a parent agent that orchestrates the flow.

What this looks like, structurally, is an org chart. And the analogy is doing real work.

The Specialization Argument

The case for subagents is the same case organizations have always made for specialization: a focused worker outperforms a generalist on the focused worker's domain, because the focused worker isn't paying the cost of carrying everything else around.

Context is the resource being conserved. Every fact the agent knows takes space in its context window. A generalist agent that "knows" your entire codebase, your entire policy document, your entire toolchain, and your current task is using most of its context just holding those facts in mind. A specialist agent that only needs the file it's working on, the function signatures it's calling, and the immediate task uses an order of magnitude less context and reasons more clearly with what's left.

Tools are the resource being focused. A generalist agent with fifty registered tools spends real reasoning effort deciding which tool to use. A specialist agent with five tools makes the tool decision quickly and spends its effort on the actual work. The teams running large agent fleets report that tool-decision overhead is one of the largest invisible costs at scale.

Prompts are the resource being sharpened. A generalist prompt has to handle every kind of task the agent might be given. A specialist prompt can be narrow, opinionated, and aggressive about what good output looks like. The narrower the prompt, the higher the floor on the agent's output quality.

The same logic explains why human organizations specialize. A senior architect who also handles payroll, sales, and customer support isn't a better architect — they're a worse one, because the cognitive load of carrying the other roles erodes the role they're actually good at.

What a Real Subagent Hierarchy Looks Like

The specific shape of an effective subagent hierarchy varies by domain, but a few patterns show up consistently in teams that have been running multi-agent systems for more than a few months.

The orchestrator. A high-level agent whose job is to interpret the user's request, decompose it into pieces, and delegate to the right specialists. The orchestrator does not do the work itself — its tools are mostly "spawn subagent" calls. It reads results from subagents, decides what to do next, and assembles the final output. This is the agent the user actually talks to, and it's typically the only one that needs the broadest context.

Planning specialists. Subagents whose job is to take a fuzzy task and turn it into a concrete plan. The planning agent has tools for reading the codebase, surveying the surrounding context, and producing a structured task breakdown. It does not execute. Its output is a plan that the orchestrator uses to dispatch other subagents.

Exploration specialists. Subagents whose entire purpose is "find me X." They have tools for searching, reading, and summarizing. They read excerpts, not whole files. They burn their context on the search and return a focused answer to the orchestrator. The orchestrator never has to load everything the explorer looked at — it just gets the conclusion.

Execution specialists. Subagents that actually change things. Each one is scoped to a single kind of change — a refactoring specialist, a migration specialist, a test-writing specialist, a documentation specialist. They have the tools they need for their domain and not the tools they don't. They run fast, fail predictably, and return a concrete artifact.

Review specialists. Subagents that check the output of execution agents against an explicit standard. The reviewer has the spec, the diff, and a sharp prompt about what good looks like. It's not allowed to write code — only to approve, request changes, or escalate.

This isn't theoretical. It's the architecture under Claude Code's Plan, Explore, and various task-specific subagents. The same pattern is what makes a multi-agent setup outperform a single-agent one on long-running work.

Where the Org-Chart Analogy Earns Its Keep

The instinct to compare subagent hierarchies to org charts is usually dismissed as cute. But the analogy turns out to predict design decisions that work and design decisions that don't.

Span of control matters. An orchestrator that tries to manage twenty subagents in parallel loses track of what each one is doing — the same way a human manager with twenty direct reports stops being a manager and becomes a bottleneck. Effective orchestrators delegate to a small number of subagents at a time, and the subagents themselves spawn lower-level subagents when needed. This is the same hierarchy organizations have converged on for the same reasons.

Roles need clear boundaries. Subagents whose responsibilities overlap end up doing each other's work badly. The planning agent that "also does a bit of execution" produces worse plans and worse code than the planning agent that strictly outputs plans. The same is true of human roles where the job description sprawls.

Handoffs are where quality dies. When the orchestrator passes a subagent's output to the next subagent, the format of the handoff determines how much quality survives the transfer. Structured outputs survive; unstructured prose loses fidelity at every hop. Mature multi-agent systems define their handoff formats as carefully as a mature company defines its inter-team interfaces.

The hierarchy should be flat when it can be. Multi-layer hierarchies introduce latency and information loss at every level. The best subagent designs use as few layers as the task can tolerate. Three layers — orchestrator, specialist, sub-specialist — is usually the right ceiling. Beyond that, you're paying coordination costs the work doesn't justify.

How to Design Your First Subagent Hierarchy

Teams introducing subagents for the first time tend to over-engineer them. A few principles keep the design tractable.

Start with the tasks that already fail. Identify the work where a single agent reliably runs out of context, gets confused, or produces inconsistent output. That's where a subagent hierarchy will pay back fastest. Don't introduce subagents on tasks the single agent handles well — you'll add complexity for marginal gains.

Define each subagent by what it isn't allowed to do. A planning subagent that can also write code will write code. An explorer subagent that can also edit files will edit files. The constraint is the design. Tool sets, permission policies, and prompt language all need to enforce the boundary.

Make the orchestrator's job small. The orchestrator's prompt should be a few hundred words at most: how to interpret the request, which subagents exist, when to call which one, how to assemble results. If the orchestrator's prompt grows into a thousand-line spec, you've moved the complexity into the wrong place — the work belongs in subagents.

Treat subagent prompts as production artifacts. Version them. Review changes. Test them. A subagent prompt is the most important piece of intellectual property in your agent system — it's the institutional knowledge that makes that specialist good at its job. Teams that treat subagent prompts like throwaway scripts end up with subagent fleets that drift unpredictably as people edit them.

Audit handoffs. Log the input and output of every subagent invocation. When the system fails, the failure is almost always at a handoff — the orchestrator gave a bad brief, the subagent misinterpreted it, or the output format was lossy. Without the audit log, debugging is guesswork.

What This Changes About How Teams Operate

The teams running mature subagent hierarchies have started to talk about their agent systems the way they talk about their actual teams. They have specs for each subagent. They have onboarding documents (system prompts). They have performance reviews (eval runs against historical tasks). They have org-chart redesigns when the work changes.

This isn't a coincidence. The agent system is genuinely doing work that previously required a team of specialists. The design discipline that produces good human teams turns out to produce good agent teams too — same span-of-control, same clarity-of-role, same handoff hygiene. The teams that recognize this and design accordingly end up with agent systems that scale. The teams that keep trying to make one agent do everything end up with brittle workflows and quietly disappointed expectations.

The hardest part of building a great agent system isn't the agents. It's the org chart. Get the structure right and the individual specialists become powerful. Get the structure wrong and even excellent specialists get bottlenecked behind a confused orchestrator. The teams that figure out their org chart first — and refine it the way good organizations refine theirs — are the teams whose AI workforce actually compounds.