Subagents and Delegation

18.1 The Mechanism #

A subagent is a separate model execution possessing its own context window. The parent invokes it with a task; the subagent works; only its final message returns to the parent. Intermediate tool calls and reasoning stay inside the subagent’s window and never enter the parent’s.⁴³

That isolation is the legitimate reason to use delegation at all. A search task that reads twenty files and produces a three-paragraph answer costs the parent three paragraphs instead of twenty files.

The mechanics: a non-fork subagent starts with a fresh context window; a tool omitted from its definition is not in its session at all; and governance controls exist for spawn depth, concurrency, and budget caps that terminate background subagents.

18.2 It Protects the Window and Raises the Bill #

Both halves are true, but any material presenting only the first half of that sentence is selling something.

Delegation adds a full model invocation carrying its own system prompt and its own tool definitions, and the parent still pays for the returned summary. Whether the prefix is cache-cold depends on which kind of subagent it is: a fresh subagent starts from nothing and pays a cold prefix, while a Claude Code fork inherits the parent conversation and reuses its cache, so the write is one the parent already paid for.⁴⁸ For a task the parent could have done in three turns, a fresh subagent is usually more expensive—but not as a matter of arithmetic that holds everywhere. A cheaper model on the delegated leg, parent work the delegation avoids, and a large parent context the subagent does not carry can each reverse the ordering, so establish it for your own workload rather than assuming it.

The break-even runs roughly as follows: delegate when the subagent’s context consumption would have exceeded the parent’s window pressure budget, and when the returned summary is genuinely much smaller than the work. Reading twenty files to answer one question qualifies. Reading one file does not.

18.3 The Evidence Is Weak #

Multi-agent orchestration is heavily marketed, while the published evidence does not support it as a default for software engineering.

The most-cited positive result reports a 90.2 percent improvement over a single agent on an internal research evaluation, and in the same publication notes that multi-agent systems use about fifteen times more tokens than chat, that single agents use about four times more than chat, that token usage alone explained 80 percent of performance variance on the relevant benchmark, and that most coding tasks involve fewer truly parallelizable subtasks than research.⁴⁴ Keep both denominators, because the fifteen is against chat and not against an agent: the matched comparison is roughly fifteen against four. The gain is substantially a token-spend gain, and the vendor with the strongest published result explicitly carves coding out of it.

The counterevidence, moreover, is stronger than the case:

• A peer-reviewed study of over 1,600 annotated execution traces across seven multi-agent frameworks produced a fourteen-mode failure taxonomy in three categories—system design, inter-agent misalignment, and task verification—with inter-annotator agreement at κ = 0.88, and found that obvious interventions such as better prompts and added structure produce partial gains only.⁴⁵ Multi-agent failure sits in the architecture, beyond the reach of prompt changes.
• Under matched thinking-token budgets, single-agent systems were the best performer or statistically indistinguishable from it at every budget except the lowest, across five multi-agent variants and three models. Sequential multi-agent closes the gap as the context degrades: it is already level at 50 percent corruption in the study’s masking and deletion arms—0.223 against 0.223, and 0.216 against 0.219, on overlapping intervals—and clearly ahead in some 70 percent settings, though not all, since single agents still lead at 70 percent deletion.⁴⁶ The regime where the switch pays is the one good context engineering exists to prevent. That study covers multi-hop question answering rather than software engineering, which should be stated.
• The useful architectural discriminator from a third vendor: read actions parallelize and write actions do not. Multi-agent fits breadth-first read-heavy exploration and misfits shared context and coordinated writes.⁴⁷

And there is no published measurement that sub-agent context isolation improves task success on software engineering work. The mechanism is documented; the benefit is asserted.

18.4 The Defensible Position #

Use parallelism for read-heavy exploration, candidate generation, and independent work streams carrying partitioned scope. Concentrate writing and synthesis in one place. Treat multi-agent orchestration for a single coherent change as unproven and expensive.

---
name: dependency-auditor
description: >
  Use to audit third-party dependencies for a specific package or lockfile.
  Reads manifests, checks advisories, and returns a ranked risk summary.
  Read-only — cannot modify files.
tools:
  - read_file
  - grep
  - run_command:npm audit
model: claude-haiku-4-5
---

You audit dependencies. You do not fix them.

For the target given to you:
1. Read the manifest and lockfile.
2. Run `npm audit --json` and parse the result.
3. For each advisory, determine whether the vulnerable path is actually
   reachable from application code. Grep for the importing module.
4. Return at most 10 findings, ranked by reachable severity.

Return format: a numbered list. For each finding — package, advisory ID,
whether reachable (yes/no/unknown), and one sentence of evidence.

Do not return the raw audit output. Do not propose upgrades.

Four design decisions appear in that definition, and each reduces risk:

• The tools list is explicit and minimal. Three entries, one of them a single named command rather than a general shell. Omitting tools on most surfaces grants everything, including every MCP tool. This is the line that matters.
• A cheap model is specified. Delegated work is often mechanical and does not need the frontier tier.
• The output is bounded. “At most 10 findings” and “one sentence of evidence” cap what returns to the parent, which is the entire point of delegation.
• Scope is stated negatively twice. “You do not fix them” and “Do not propose upgrades” prevent scope creep in a context the parent cannot see.

The tool names above are host-neutral, and translating the shape matters more than copying the strings. Claude Code’s built-ins are Read, Grep, Glob and Bash, and a single-command restriction is written as a Bash permission pattern rather than as a run_command: entry.⁴⁸ Note also what this definition is and is not: it grants one named command because its job requires running one, so it is a narrow grant rather than a read-only one.

18.5 The Tools Contract #

The persona prose in a subagent definition is advisory. The rest of the frontmatter is not: alongside tools and disallowedTools, Claude Code honors maxTurns as a hard execution limit, permissionMode as the mode the subagent runs under, hooks scoped to that subagent, isolation: "worktree" for checkout separation, and omitClaudeMd to withhold the instruction files.⁴⁸ Those are runtime controls the model cannot talk its way past, and the tool list is the widest of them rather than the only one.

# Grants everything the parent has, including MCP servers. Almost never correct.
---
name: helper
description: General purpose helper
---

# Grants exactly three capabilities. Correct.
---
name: helper
description: General purpose helper
tools: [read_file, grep, glob]
---

The first definition above grants every tool the parent holds, including every MCP tool connected to the session; the second grants exactly three. Omission is no neutral default. It is a maximal grant. Treat a committed subagent definition as a standing permission grant in the repository because that is what it is.

There is a second reason the tool list matters more for a subagent than for the parent, and it is easy to miss. A subagent has no interactive surface of its own, so what happens at an approval-required call is a property of the host and the execution mode rather than of delegation as such. Claude Code passes a foreground subagent’s permission prompts through to the user, and surfaces a background subagent’s prompts in the main session, naming which subagent is asking.⁴⁸ Under an auto-deny permission mode—or any genuinely unattended run—the same call resolves as a denial instead, and a permission tier reading as “check with the user” at the parent reads as “fail” wherever nobody is present to answer. Establish which mode your delegation actually runs in before relying on either behavior.

The pattern that follows holds under either mode: bound the subagent’s tool list to what its job actually needs, and keep actions you want a human to see at the parent, where the prompt is unambiguous.⁴⁸ The dependency auditor above is bounded that way—read, grep, and one named command, with no write tool and no general shell—which is a scope decision first and a prompt-handling decision second. Delegation interacts with verification in a way that has to be stated carefully (§18.6), because the distinction is what supplies the evidence, not which agent runs. A subagent asked to review the work and give an opinion is self-critique by another name, and §10.3’s critic measurements apply to it whatever the permission model does. A subagent that executes the existing test suite, the compiler or the type checker and returns what actually came back is an oracle check (§10.4), and moving that execution into a subagent does not convert it into the model’s own judgment—isolating verbose test output is one of the documented reasons to delegate at all.⁴⁸ What you must not accept is the middle case: a subagent’s claim that the tests passed is model output, not an oracle result, and it sits in the same position as any other summary crossing back to the parent. Require the run’s actual evidence—the exit status, the failing-test names, the diagnostics—rather than the assurance, and remember that an oracle is only as good as its coverage.

18.6 Failure Modes #

• Delegating trivial work. Strictly more expensive with no isolation benefit.
• Omitting the tools list. Grants everything, silently.
• Unbounded return. A subagent that returns its full transcript has defeated its own purpose.
• Multi-agent for a single coherent change. Roughly fifteen times a chat interaction’s tokens against a single agent’s four (§18.3), an architectural failure taxonomy, no software-engineering evidence, and, at repository scale, a merge-conflict rate from concurrent work that reasoning alone says is higher.
• Treating a subagent’s judgment as verification. Self-critique by another name (§10.3), and the critic measurements apply.³⁰ Delegating an oracle—running the suite, returning its actual output—is a different thing and a documented use of subagents; accept the evidence, not the assurance (§18.5).