This is a chapter from The Agentic Coding Kit - 34 ready-to-use files that package a senior engineer's AI coding setup: CLAUDE.md templates, permission guardrails, git hooks, and subagent playbooks. $19, instant download.
Claude Code and other agentic coding tools can spawn subagents: separate agent instances that get a slice of the work, their own context window, and a narrow job description. Used well, subagents are how you get parallel speed without the main agent losing the plot. Used badly, they are how you get five half-finished refactors that don't compile together.
After running subagent-heavy workflows on real codebases for months, here are the patterns that hold up.
Pattern 1: Scout agents for read-only exploration
The cheapest, safest subagent is one that can only read. Send it to answer a question like "where is authentication enforced in this repo?" or "what breaks if I change this interface?"
Why it works: the scout burns its own context on the boring traversal - opening 30 files, tracing imports - and returns a 10-line answer. Your main agent's context stays clean for the actual work.
Rules that keep scouts useful:
- Give it a question, not a task. "Map the billing flow" not "refactor billing."
- Cap the output. "Return the file paths, the key functions, and a 5-sentence summary."
- Forbid writes entirely. A scout that edits is no longer a scout.
Pattern 2: Worker agents with a definition of done
A worker subagent gets a concrete, verifiable task: "add input validation to these three endpoints, with tests that fail before and pass after." The key is that the task must be checkable without judgment.
If you can't write the done-condition in one sentence, the task isn't ready to delegate. Split it further or do it yourself.
The playbook version I use:
- Scope: exact files or directories it may touch.
-
Done condition: the command that must pass (e.g.
npm test -- billing). - Budget: stop and report after N minutes or M failed attempts, instead of spiraling.
That third one is the one everyone skips. An unbounded worker will confidently produce 800 lines of wrong. A bounded one reports "stuck, here's what I tried" and costs you two minutes.
Pattern 3: The reviewer is not the author
Never let the agent that wrote code be the agent that reviews it. Same context, same blind spots. A fresh reviewer subagent, given only the diff and the requirements, catches things the author agent sailed past - because it has no sunk cost in the approach.
This mirrors human teams for a reason. The kit's review checklist templates exist to give the reviewer agent the same bar every time: error handling, injection surface, migration safety, test quality.
What to never delegate
Some work should stay with the main agent (or with you):
- Deciding what to build. Subagents execute judgment; they shouldn't create it.
- Cross-cutting design. Anything that changes contracts between modules needs one coherent mind.
- Final review before merge. Delegated review is a filter, not a gate. The last pass belongs to whoever owns the outcome.
- Secrets and destructive ops. Permission guardrails should make this impossible, not just discouraged.
The coordination tax
Every subagent adds overhead: you write a brief, wait, and integrate the result. If the task takes less time than the brief, do it inline. My rule of thumb: delegate when the subtask needs more than ~10 minutes of focused work or a separate context window's worth of reading.
The win isn't parallelism for its own sake. It's keeping the main agent's attention on the decisions while the grunt work happens in quarantined contexts.
The full subagent playbooks - scout, worker, reviewer templates with done-conditions, budgets, and integration checklists - are in The Agentic Coding Kit, along with the CLAUDE.md template and permission guardrails that make delegation safe. One-time $19, lifetime updates.
Top comments (1)
The ~10-minute delegation threshold and the explicit failed-attempt budget make the coordination tax concrete instead of treating parallelism as automatically valuable. I'd extend the worker definition of done beyond "its test command passes" to include the expected base commit, owned files, and an integration check after the result lands, because individually correct changes can still collide at module boundaries. Keeping cross-cutting design with one owner, while a fresh reviewer sees only the diff and requirements, is a sensible balance between context isolation and coherent delivery.