Delegating to Sub-Agents: When a Second Agent Pays for Itself — and When It Just Burns Tokens

Here's a session you've probably lived. Two hours in, one agent has implemented your feature, half-refactored a module you didn't ask about, and is now writing tests — with a context window full of abandoned approaches, corrected mistakes, and three files that no longer look like what it remembers. The output is getting worse, not better, and you can feel it.

The instinct is to push through. The better move is usually to stop treating one agent as an employee who does everything, and start treating it as a lead with a small team — where delegation is a scoping decision, not a magic trick.

This is part three of the series (part one: planning, part two: context). The agent definitions below are real files — they live in 03-subagents/ in the companion repo.

What a sub-agent actually is (and isn't)

A sub-agent is a fresh context window with a narrow brief. In Claude Code it's a markdown file in .claude/agents/; the main agent hands it a task, it works in isolation, and only its result comes back — not its reasoning, not its dead ends, not the twenty files it read to get there.

That last part is the entire value. Don't confuse it with a slash command — a custom command is a saved prompt running in your context; a sub-agent is a separate context. And if you're on Cursor or Copilot without native sub-agents, you can get 80% of the effect manually: open a fresh chat, paste a tight brief, bring back only the conclusion. The principle is portable; the button is not.

Here's a real definition file:

---
name: dependency-auditor
description: Audits a proposed dependency change. Use before accepting
  any new package or version bump.
tools: Read, Grep, Bash, WebSearch
---

You are a supply-chain auditor. For the proposed dependency change:

1. Verify the package exists on the official registry AND has a
   matching tag in its source repository. No matching tag = red flag.
2. Check: last release date, maintainer count, download trend,
   open security advisories.
3. Diff the requested version against the currently pinned one —
   flag any major-version jump or maintainer change.
4. Answer two questions only:
   - Is this package what it claims to be?
   - Does the project actually need it, or does stdlib/an existing
     dependency already cover this?

Report: VERDICT (accept / reject / needs-human), evidence, one-line
rationale. Do not modify any files.

Note what makes it work: one job, named tools, explicit output contract, and no write access. A sub-agent brief is a job description, not a wish.

The three delegations that pay for themselves

1. Parallel recon before you build

Before implementing the rate limiter from part one's plan, I want three questions answered: how auth resolves key tiers, what test conventions the repo uses, and whether any limiter pattern already exists. Sequential, that's three context-polluting detours. Delegated:

Spawn three agents in parallel, read-only:
1. Map how @app/auth.py resolves API keys and where a "tier" would
   attach. Return: the function to extend + its callers.
2. Audit @tests/ conventions: fixtures, naming, how env vars are set.
   Return: a pattern summary I can hand to an implementer.
3. Search the repo and git history for any existing rate-limit or
   throttle logic. Return: file paths or "none".

Three independent read-only tasks, three clean contexts, results in one pass — and my main context stays lean for the actual implementation. This is the delegation with the clearest payoff: independent + read-only + parallelizable.

2. The clean-context skeptic

The second high-value delegation attacks the self-grading problem. An agent that just wrote code is the worst possible judge of that code — it's invested, and it re-reads its own reasoning as evidence. So hand the output to a fresh agent whose only job is to break it:

---
name: refuter
description: Adversarially reviews a finished change. Never sees the
  author-agent's reasoning — only the diff and the claim.
tools: Read, Grep, Bash
---

You receive: a diff and a claim of what it does. You were not involved
in writing it. Try to refute the claim:

- Run the tests. Then check what the tests do NOT assert.
- Trace one unhappy path end-to-end (bad input, missing env var,
  double call).
- Check the diff against its stated scope: list every change that
  was not asked for.

Default to skepticism: if you cannot verify a claim, report it as
unverified — not as fine. Output: CONFIRMED / REFUTED per claim,
with evidence. Style opinions are out of scope.

This is the adversarial-verify idea from the harness, operationalized. The isolation is load-bearing: the refuter never sees the author's justifications, so it can't be argued into agreement by context it inherited.

And now the line that this whole series stands on: the refuter improves what lands on your desk. It does not replace you reading the diff. An agent writing code and another agent approving it is a closed loop with no human in it — that's the exact failure the last-human post describes, automated. The refuter's report is an input to your review, never a substitute. Part five is that review.

3. The big read-only sweep

"Find every endpoint that touches invoice state and list its auth requirements" — a task that means reading fifteen files. Do it in your main session and those fifteen files sit in your context for the rest of the day, crowding out what matters. Delegate it, get back half a page of conclusions, keep the workspace clean. Same logic as part two: the sweep is relevant once; its residue is noise.

When delegation is the wrong call

Honesty section. Sub-agents are the most oversold feature in agentic coding, and the failure modes are predictable.

The economics are real. When I wrote about fixing the harness, I cited Anthropic's own numbers: their multi-agent research setup beat a single agent by 90% — while burning roughly fifteen times the tokens. That's the trade, stated plainly. Fifteen-x is a great price for recon that prevents a wrong architecture. It's an absurd price for renaming a function. Token economics don't disappear because the spend is automated.

Sequential work doesn't parallelize. If task B needs task A's output, two agents give you coordination overhead and an information hand-off loss — not speed. One agent, one context, done.

Shared evolving state breaks isolation. Two agents editing the same module in parallel is a merge conflict you scheduled on purpose. Parallel delegation wants disjoint targets — different files, or better, read-only.

Cascades multiply errors silently. Agent A misreads the schema, hands its summary to agent B, which builds on it confidently. By the time it reaches you, the error is three layers deep, wearing a straight face. This is why my sub-agents return evidence with file paths, not just conclusions — claims you can spot-check beat claims you must trust.

The decision rule I actually use:

What changes at fifty developers

At team scale, sub-agents stop being a productivity trick and become an access-control question — the same "boundaries before capabilities" argument from MLOps to AgentOps.

• Least privilege per agent, enforced in the definition. The tools: line is the permission boundary. My recon agents get Read, Grep — no Bash, no Write, no network. The refuter gets test execution, nothing else. An agent that only needs to read cannot be prompt-injected into writing.
• Caps, not trust. Iteration limits and cost budgets per agent, so a confused loop dies at its cap instead of at your invoice. The same containment thinking as the multi-agent case study: assume an agent will eventually misbehave, and make the blast radius boring.
• Traces or it didn't happen. Every spawned agent logs which agent ran, with which inputs, at what cost. You cannot debug — or audit, and in critical infrastructure audit is the word — a fan-out you can't see.
• Shared definitions are policy. A .claude/agents/ directory in the repo is versioned, reviewed team policy — the same "rules as code" move as the skills post, applied to delegation.

The Bottom Line: A sub-agent is a fresh context with a narrow brief and the minimum tools to do one job — delegate the independent, the read-only, and the adversarial, keep the sequential and the interdependent, and never let one agent's approval stand in for yours. The 90% gain and the fifteen-x bill are the same feature: know which side of that trade your task is on before you spawn.

Next in the series: Rules for the Blast Radius — security and dependency guardrails an agent can't quietly route around.