Claude Code: A Practitioner's ApproachHow Product Builders Use Claude Code to Ship Faster Than Engineers
Chapter 5 · Claude Code: A Practitioner's Approach

A Small Army You Never Hired

Spin Up Specialist Sub-Agents, One for Each Kind of Work

The Night Watch, Rembrandt van Rijn, 1642
The Night Watch, Rembrandt van Rijn, 1642. Rijksmuseum, Amsterdam. Public domain. A whole company caught mid-mobilization, each figure already doing its one job.

On the cover: Rembrandt's The Night Watch (1642), paired with Whitman on containing multitudes. Picked because a sub-agent bench is exactly this: a company of specialists you assemble from a single seat, each one already in motion on its own job, none of them on your payroll.

"I am large, I contain multitudes." Walt Whitman, Song of Myself

Claude Code Sub Agents: What They Are and When to Use Them, TechWithDavid
Watch first (or come back to it): Claude Code Sub Agents: What They Are and When to Use Them, TechWithDavid. Nine minutes on what a sub-agent is and, more usefully, when reaching for one actually pays off. The distinction between a skill and a sub-agent lands faster after you have seen both in motion once.

Rembrandt's largest painting is not a battle and, despite the name, not even a night scene. The dark was varnish; a later cleaning found daylight underneath. What it actually shows is a civic militia company, ordinary Amsterdam citizens who took turns guarding the city, stepping out of a shadowed archway into the sun. The captain, in black with a red sash, gives the order to march. His lieutenant, in pale buff and gold, listens for it. Around them the company does not stand in a tidy row the way group portraits of the period usually did. One man loads his musket. Another fires his. A third blows the spent powder from the pan. A drummer starts up on the right. A small girl in gold, the company mascot, threads through the crowd with a dead fowl at her belt, its claws the old emblem of the militia. Rembrandt took what should have been a stiff lineup of men who each paid to be in the picture and turned it into a single organism catching itself into motion, every figure already busy with the one thing it does.

That is the mental image for this chapter. Up to now you have worked alone with Claude Code. You brief it, it works, you review, you brief it again. It is one very capable generalist sitting in your chat panel. This chapter is about the moment you stop working with one of it and start working with a company: a researcher who only researches, a reviewer who only pokes holes, a code auditor who only reads and never writes. Each one is a specialist. Each one steps forward when its name is called, does its job in its own corner, and reports back. You never filed a job requisition. You never approved a salary. You spun the whole company up from the same seat you have been sitting in.

Whitman gave the feeling its line a century and a half before there was anything to point it at. "I am large, I contain multitudes." One operator, many selves, each good at a different thing. By the end of this chapter you will have a small bench of them, a researcher, a PRD reviewer, a code reviewer, that you can call by name the way you called a skill in the last chapter, and you will have chained three of them into a pipeline that turns a vague question into a reviewed spec in a single prompt. The company is small. You never hired it. It still gets more done in an afternoon than you used to get done in a sprint.

In This Chapter

5.1 What a Sub-Agent Is (and Why You Want One)

In the last chapter you built a skill. A skill is a named workflow that loads into your current conversation. When you type /prd-generator, the instructions in that SKILL.md become part of the same session you are already in. It shares your context, your tools, your model, and your chat history. It is a recipe you follow yourself, out loud, in the room you are already standing in.

A sub-agent is different in one structural way, and the difference is the whole point. A sub-agent runs in its own room. It gets a fresh, separate context window, its own set of tools, and optionally its own model. You hand it a job, it goes off and does that job in private, and it hands back a result, not the whole mess it made getting there. The recipe metaphor becomes a kitchen metaphor: a skill is you cooking; a sub-agent is a line cook you hand a ticket to, who returns the finished plate while you never see the pans.

Three things follow from that separation, and each one is a reason you want it.

The first is context isolation. When you ask Claude Code to research six competitors, it reads a lot of pages, most of which you will never care about. If it does that in your main session, all of it piles up in your context window, crowding out the actual work and slowly making the model dumber about the thing you are really doing. A research sub-agent reads those same six pages in its own window and hands you back three paragraphs of findings. You keep the conclusion. You never see the file dump. Your main thread stays clean.

The second is specialization. A sub-agent has its own system prompt, so you can give it a personality your main session should not have. A PRD reviewer that is told to be relentlessly adversarial, to assume the spec is wrong and go looking for how, would be exhausting to work with as your default Claude. As a sub-agent you summon only when you want a spec torn apart, it is exactly right. You are not adjusting one assistant's mood all day; you are keeping a bench of specialists, each locked into the job it is good at.

The third is parallelism, and it is the one that changes the math. Because each sub-agent runs independently, you can run several at once. Five competitors, five researchers, all working at the same time, is not five times the wall-clock cost; it is roughly the cost of the slowest one. That is the subject of the next chapter, so hold it lightly for now. In this chapter we build the specialists and chain them in a line. In the next one we let them work in parallel.

Deeper read: Sub-agents, Claude Code documentation

The official reference for how agent files are structured, where they live, and how Claude decides which one to hand a task to. Short, and worth skimming once before you write your first one.

5.2 The Five Agents Every PM Needs

You do not have to invent your bench from nothing. The course repo ships with five sub-agents already written, and they happen to be the five that cover most of a product manager's week. They live in the starter repo at .claude/agents/, one Markdown file each.

AgentWhat it doesGood default model
research-agentSearches the web and returns structured findings with sourcesSonnet
prd-reviewerReads a PRD and returns exactly 3 risks, 3 edge cases, 1 scope-creep flagOpus
code-reviewerRead-only audit of a change before it goes to engineeringSonnet
copy-writerDrafts and tightens user-facing copy in a consistent voiceSonnet
data-analystReads a CSV or export and surfaces the stats and anomalies that matterSonnet or Haiku

An agent file has the same two-part shape a skill does: a frontmatter block that tells Claude Code what the agent is, and a body that tells the agent how to behave. The frontmatter is where the structural differences from a skill show up.

---
name: research-agent
description: Researches competitors, market trends, or background context. Use when asked to research, analyze competitors, or gather market information.
tools: WebSearch, WebFetch, Read
model: sonnet
---

You are a research specialist. Given a topic, you search the web,
read the most relevant sources, and return a structured briefing:
what you found, who the players are, where the gaps are, and a short
list of sources. You never pad. If the evidence is thin, you say so.

Two fields do the heavy lifting. description is the most important line in the file, exactly as it was for skills, because Claude reads it to decide when to hand this agent a job on its own. Write it as "use when," in the words you would actually use. tools is new and it matters: it is the specific set of tools this agent is allowed to touch. A research agent gets web tools. A code reviewer, as you will see, gets read-only tools and nothing that can write. Narrowing the tool list is not just tidiness; it is a guardrail that makes the agent safer to run without you watching.

Personal agents live in ~/.claude/agents/ and follow you across every project. Project agents live in .claude/agents/ inside a repo and travel with that repo, so your teammates get the same bench when they clone it. Same split as skills, same reasoning.

Community signal, r/ClaudeAI: Subagents in Claude Code aren't a speed trick

A practitioner argues the real win from sub-agents is not doing things faster, it is keeping each job in its own clean context so the quality holds up. The comments are a good tour of how people actually structure their benches.

5.3 Building the Research Agent

Start with the researcher, because it is the one whose payoff you feel first. Open Claude Code in the starter repo and, instead of writing the file by hand, let Claude write it with you:

Create a sub-agent called research-agent. It should search the web and
read sources, then return a structured competitive briefing: the main
players, how they position, pricing where it is public, and the gaps
nobody is filling. Give it only web and read tools. Use Sonnet. Write it
to .claude/agents/research-agent.md.

Claude will scaffold the frontmatter and a system prompt, and drop the file in place. Read what it wrote before you use it. The two things to check are the description (does it say "use when" in language you would really type?) and the tools line (web and read only, nothing that writes). If either is off, edit it in plain English and save.

Then use it. You do not run a sub-agent with a slash command the way you run a skill. You ask for it in a sentence, and Claude delegates:

Use the research-agent to compare the top four AI meeting-notes tools.

Claude spins up the agent in its own context, the agent does its searching and reading off to the side, and what comes back to you is the briefing, not the forty pages it read to write it. That is the isolation from 5.1 doing its job.

Code companion: the finished research-agent.md lives at .claude/agents/research-agent.md. For a fuller example, the repo also ships demos/competitor-research-agent/, a working project that uses two smaller sub-agents, a pricing-fetcher and a review-miner, to do the research in pieces. Clone it, open it, and run it against a market you actually care about.

5.4 Building the PRD Reviewer

The research agent gathers. The PRD reviewer attacks. This is the one where a separate context earns its keep most obviously, because you want fresh eyes on your spec, and the model that just helped you write the PRD does not have fresh eyes. It is proud of the thing. It helped make it. A reviewer summoned into its own clean room, told nothing except "assume this spec is flawed and find out how," is far more useful than the same model grading its own homework.

The behavior to build in is a fixed shape for the output, so the review is comparable every time:

---
name: prd-reviewer
description: Reviews a PRD and flags what is missing or risky. Use when asked to review, critique, or audit a product spec.
tools: Read, Grep, Glob
model: opus
---

You are a skeptical staff product manager reviewing a peer's PRD.
Return exactly:

- 3 risks (what could make this fail in the real world)
- 3 edge cases the spec does not handle
- 1 scope-creep flag (the thing that should be cut from v1)
  Be specific. Cite the section. Do not soften. If the PRD is genuinely
  solid, say which single change would most improve it.

The fixed count is deliberate. "Give me feedback" produces a shapeless list you skim and forget. "Give me exactly three risks, three edge cases, and one thing to cut" forces the model to prioritize, and it forces you to confront the same three questions on every spec you write. Over a quarter that consistency is worth more than any single review.

Give it read-only tools. A reviewer that could edit your PRD would be tempted to fix things instead of naming them, and you want the naming.

5.5 Building the Code Reviewer

The last of the three you will build in this chapter is the one that most changes how engineering sees you. When Claude Code builds you a prototype, you can ship it to a few users without an engineer ever looking at it. But the moment you want to hand that prototype toward the real codebase, or even just show it to your engineering partner, a quiet read-only audit first saves you from the two or three obvious things that make a reviewer stop trusting the whole thing.

---
name: code-reviewer
description: Read-only review of code changes for bugs, security issues, and missing tests. Use before committing or sharing a prototype with engineering.
tools: Read, Grep, Glob
model: sonnet
---

You review code changes and report problems. You never edit files.
For each finding give: the file and line, what is wrong, and the concrete
failure it causes. Rank by severity. Cover correctness, obvious security
holes (hardcoded secrets, unvalidated input), and missing error handling.
End with the single most important thing to fix before this is shared.

The tools line is the whole safety story here: Read, Grep, Glob and nothing that writes. This agent physically cannot change your code, so you can run it on anything without watching it. It reads, it reports, it stops. You stay the one who decides what to do about what it found.

For a PM this is less about catching bugs and more about credibility. Walking into a conversation with engineering already knowing where the hardcoded key is, or that there are no tests around the payment path, changes the conversation from "the PM threw code over the wall" to "the PM did the first pass." That is a cheap reputation to buy.

5.6 The Three-Stage PM Pipeline: Research to PRD to Review

Three specialists on a bench are useful one at a time. They become a different kind of thing when you put them in a line. The most common product-management shape is exactly three stages long: understand the landscape, write the spec, stress-test the spec. You now have an agent for the first and the third, and either the prd-generator skill from the last chapter or your own hand for the middle.

Chained, it reads as one instruction:

Use the research-agent to survey the top competitors for a lightweight
async standup tool. Then draft a one-page PRD for our version. Then use
the prd-reviewer to critique that PRD and list what to fix before v1.

Claude runs the research agent first, in its own context, and keeps the briefing. It drafts the PRD using that briefing. Then it hands the draft to the reviewer, in a second clean context, and returns you the critique. What lands in your lap is a researched spec plus a list of its own weak points, produced from one sentence, in the time it used to take to schedule the kickoff meeting.

For now this pipeline is a straight line: each stage waits for the one before it, because each genuinely needs the previous stage's output. That is the right default, and it is where most PM pipelines live. The next chapter, Everything Now Passes Through Other Hands, is about the other case, the work that does not have to happen in order, where you fan five agents out at once and collect the results together. Getting the sequential version solid first is the whole preparation for it.

Code companion: the starter repo ships demos/skill-sub-multi-agent/, an interactive visualization that walks up four levels, a single skill, one sub-agent, a sequential pipeline, and a parallel fan-out, so you can see the shape of each before you build it. Open it once. The picture makes the next chapter land faster.

5.7 Choosing a Model for Each Agent

You may have noticed the model field in every agent file above, and that they were not all set the same. That field is where you decide how much horsepower each specialist gets, and the short version is that not every job needs the biggest model.

The practical rule for a bench like this: use Sonnet as the default for most agents, reach for Opus on the one or two agents whose job is hard judgment, and drop to Haiku for agents doing fast, mechanical, high-volume work. The PRD reviewer is the clearest case for Opus, because catching the subtle risk in a spec is exactly the kind of reasoning the strongest model is worth paying for. A data analyst doing a quick first pass over a CSV can often run on Haiku and hand the interesting bits up for a closer look. The researcher and the copy writer sit comfortably on Sonnet.

That is as far as we will take model selection here, because it deserves its own treatment and gets one. Chapter 7, The Models We Reach For at 2am, is entirely about the Opus-Sonnet-Haiku tradeoff, when each is worth it, what each costs, and how to route work between them without thinking about it every time. For now, set model per agent using the rule above and move on. You can always change one line later.

5.8 Chapter Assignments

Exercise 5.1: Build and run your research agent.

Create a research-agent in your own .claude/agents/ folder, either by hand or by asking Claude to scaffold it. Give it web and read tools only. Then run it on a real question from your actual job, a competitor you are genuinely unsure about. Read the briefing it returns and ask yourself one thing: did keeping the research in its own context give you a cleaner answer than asking your main session would have? Write down the difference.

Exercise 5.2: Build the PRD reviewer and turn it on your own spec.

Create the prd-reviewer with the fixed output shape, three risks, three edge cases, one thing to cut, and run it against a PRD you wrote recently and were happy with. The point of the exercise is discomfort. A reviewer that only ever agrees with you is not doing its job. If it hands back three risks you had genuinely not considered, the agent is working. If it flatters you, sharpen the system prompt and run it again.

Exercise 5.3: Chain a three-stage pipeline.

In one prompt, have the research agent survey a small market, draft a one-page PRD from what it finds, and hand that draft to the PRD reviewer. Do not intervene between stages. Read only what comes out the end. Time it. Compare that number to how long the same three steps would have taken you as three separate sittings. That number is the reason this chapter exists.

5.9 Prompts Worth Saving

Scaffold an agent:

Create a sub-agent called [name]. Its job is [one job]. Give it only
[these tools]. Use [model]. Write a "use when" description in plain
language, and write it to .claude/agents/[name].md.

Invoke one specialist:

Use the [name] agent to [task].

Run the three-stage pipeline:

Use the research-agent to survey [market]. Then draft a one-page PRD for
[our version]. Then use the prd-reviewer to critique it and tell me what
to fix before v1.

Audit before sharing with engineering:

Use the code-reviewer to audit this prototype before I show it to
engineering. Read only. Rank findings by severity and tell me the one
thing to fix first.

Summary

  • A skill loads into your current conversation and shares its context, tools, model, and history. A sub-agent runs in its own room, with a fresh context window, its own tools, and optionally its own model, and it hands back a result rather than the whole mess it made getting there.
  • Sub-agents earn their place for three reasons. Context isolation keeps your main thread clean, specialization lets each agent carry a personality your default session should not have, and parallelism lets several agents work at once for roughly the cost of the slowest one.
  • An agent file has the same two-part shape as a skill: frontmatter that says what the agent is, and a body that says how it behaves. The description field decides when Claude hands the agent a job, so write it as "use when" in your own words. The tools field is a guardrail that limits what the agent can touch.
  • Five agents cover most of a product manager's week: research-agent, prd-reviewer, code-reviewer, copy-writer, and data-analyst. Project agents live in .claude/agents/ and travel with the repo, and personal agents live in ~/.claude/agents/ and follow you across projects.
  • You do not run a sub-agent with a slash command. You ask for it in a sentence, Claude delegates, and the research agent returns a briefing instead of the pages it read to write it.
  • A PRD reviewer in its own clean context gives you fresh eyes that the model that helped write the spec cannot. A fixed output of three risks, three edge cases, and one scope-creep flag forces prioritization and makes every review comparable.
  • A code reviewer limited to Read, Grep, Glob cannot change your code, so you can run it on anything without watching it. Its real value for a PM is credibility: you walk into the conversation with engineering having already done the first pass.
  • Chaining the research agent, a PRD draft, and the PRD reviewer turns one prompt into a researched spec plus a list of its own weak points. In this chapter the pipeline is sequential because each stage needs the previous stage's output, and that is the right default for most PM work.
  • Set model per agent: Sonnet as the default, Opus for hard judgment such as PRD review, and Haiku for fast, mechanical, high-volume work. Changing that later is a one-line edit.

What's Next

You started this chapter working with one generalist and you are ending it with a bench. A researcher, a reviewer, a code auditor, each in its own room, each summoned by name, none of them on your payroll. That is the small army the title promised, and you never hired a single one of them.

They still work in a line, though, one after another, each waiting on the last. The next chapter is about what happens when they stop waiting. Everything Now Passes Through Other Hands is about pipelines and parallelism, the point where you stop calling specialists one at a time and start handing the same work to five of them at once. The bench you just built is the thing that makes that possible.

More:

Sources used in this chapter: