---
title: "Use Claude Code Subagents for PM Work"
description: "Subagents split a long product job across isolated context windows and return only the findings. Here is how to scope them, and when one agent beats four."
canonical_url: "https://builderscamp.com/guides/tools/claude-code-subagents-for-pm-workflows"
date_published: "2026-09-18"
date_modified: "2026-09-18"
author: "Andre Albuquerque, Guilherme Salgueiro"
publisher: "Builders Camp"
guide_class: "tools"
---

# How to use Claude Code subagents for PM workflows

**TL;DR:** A subagent runs one slice of a job in its own context window and hands back only the summary, which is why a four-hour planning sweep fits in one session instead of flooding it. Split a product job into subagents when the branches are independent and each generates output you will never reread. Keep a single agent when the second half of the thinking depends on the first.

## What does a subagent actually change about a long product job?

It changes what survives. A subagent works in its own context window with its own system prompt and its own tool access, and what comes back to your session is the summary, not the 40 files it opened to write that summary. That is the entire mechanism, and it is why the quarterly planning sweep that used to eat a whole session now fits inside one with room left to think.

The glossary entry on [multi-agent orchestration](https://builderscamp.com/guides/glossary/multi-agent-orchestration) covers the pattern at the concept level. This page is about the split decision: which product jobs come apart cleanly, and which get worse when you pull them apart.

## Where does a subagent live, and what goes in one?

A subagent is a markdown file. Put it in `.claude/agents/` and it ships with the repository, so the whole team gets the same one. Put it in `~/.claude/agents/` and it follows you into every project on your machine. The file opens with front matter and continues with the system prompt that agent runs under.

```markdown
---
name: support-themes
description: Reads support tickets and returns ranked themes with counts and quotes. Use for quarterly planning input and for any question about what customers keep reporting.
tools: Read, Grep, Glob
model: sonnet
---

Read the ticket exports in the path given to you. Cluster tickets by the
problem the customer describes, not by the product area the ticket was
filed under. Return at most eight themes. For each: a one-line problem
statement, the ticket count, and two verbatim quotes. Name the date range
you actually covered. Do not propose solutions.
```

Two lines in there are doing more work than they look like they are. `tools: Read, Grep, Glob` means this agent physically cannot write a file or run a shell command, which turns "please do not change anything" from a hope into a constraint. And "do not propose solutions" keeps the agent inside its job, because an agent that arrives with recommendations has already made the prioritisation call you were planning to make yourself.

## What does a real split look like?

Take the input pack for quarterly planning: what customers have been reporting, what competitors shipped, and which funnel steps moved. Three branches, no overlap, each one generating a pile of raw material you will read once and never again. That is the shape that splits well.

| Subagent | Reads | Returns |
|---|---|---|
| support-themes | 90 days of ticket exports | 8 ranked themes with counts and quotes |
| competitor-watch | Changelogs and pricing pages you name | What shipped, with dates and links |
| funnel-movement | Analytics exports | Steps that moved more than your stated threshold |

Each returns something on the order of a page. Your main session ends up holding three pages instead of several hundred file reads, and you still have the context budget to argue with the result. Then you do the part that does not delegate: deciding which of those three signals is the same problem wearing three costumes.

Ask for the agents by name rather than describing the work and hoping. Claude selects a subagent by matching your request against `description` fields, which is a reasonable guess and still a guess. Naming them costs four words and removes the ambiguity.

## Why three agents, and not eight?

Builders Camp's Building with Claude Code practical challenge caps its agent architecture exercise at exactly three, and the cap is the lesson: forcing yourself to three means drawing real boundaries instead of decomposing forever. The challenge asks for each agent's role, its responsibilities, and, pointedly, what it is explicitly not allowed to do.

The reason specialisation helps at all is the reason it stops helping past a point. The bootcamp's certification material puts it as context pollution: a single general-purpose agent that wrote the code carries its own implementation decisions into the review, so it never catches its own blind spots. Separating the writer from the reviewer fixes that. Separating the reviewer from the reviewer's note-taker fixes nothing and adds a handoff.

## How do you stop two agents editing the same file?

The planning example above is read-only, which is the easy case. The moment two agents can write, isolation stops being optional: two processes editing the same file in the same directory produce a result neither of them intended, and neither reports a problem. Adding `isolation: worktree` to a subagent's front matter gives that agent its own git worktree, a separate checkout of the same repository on its own branch, so its edits land somewhere the other agent cannot see until you merge them deliberately. The glossary entry on [parallel worktrees](https://builderscamp.com/guides/glossary/parallel-worktrees) covers what that isolation is and is not.

Two smaller front matter fields earn their keep here as well. `disallowedTools` removes specific tools from an agent that would otherwise inherit them, which is the fast way to make a research agent read-only without listing every tool it may use. And `memory` gives a subagent its own persistent notes across sessions, separate from your main conversation's, so a recurring agent stops relearning the same thing every Monday.

## When is a single agent genuinely better?

When the second half of the thinking depends on the first. A positioning memo, a build-versus-buy argument, a pricing recommendation: these are one continuous chain where paragraph six only makes sense because of what you concluded in paragraph two. Split that across agents and you get four confident fragments that do not reconcile, and you spend longer stitching them than you would have spent writing it once.

Three other cases where one agent wins:

- The setup cost exceeds the work. A subagent starts cold, so everything it needs has to be in the delegation prompt. If explaining the task takes longer than doing it, do it.
- You expect to iterate. Subagents return a result, not a conversation. If your real workflow is five rounds of "no, closer to this," stay in the main session.
- The branches read the same files. Three agents each opening the same PRD is three times the work for one set of facts.

## What the split costs you

Latency, mostly, and it is not free. A fresh subagent has to find its own footing before it produces anything, so a three-way split on a small job finishes slower than not splitting at all. There is a second cost that shows up later: you did not read what the agent read. The summary is the only artifact, and if the agent mis-clustered a theme or quietly skipped a date range, nothing in your session will tell you. That is why the example agent above is told to name the range it actually covered. Make the agent report its own boundaries and you get one checkable line instead of a silent gap.

Builders Camp's AI Agents bootcamp works this problem from the design side rather than the tooling side: autonomy levels, tool and guardrail definition, human-in-the-loop approvals, and the evaluation loop that tells you whether an agent is doing what you think it is doing. It runs 2 weeks with 3 live sessions and 9 microlessons. The mechanics of running several at once, including parallel worktrees and background execution, sit inside Building with Claude Code, and both bootcamps belong to the AI Agentic Builders Expert Track.

## The delegation prompt is the deliverable

The habit worth building is not "use more agents." It is writing a delegation prompt that would make sense to a competent stranger who has never seen your product, because that is exactly who receives it. Scope, inputs, the format you want back, and one line naming what the agent must not do. Product managers who get good at subagents tend to report that the prompts got sharper first and the speed came second, which is the same order of operations that makes a good brief work on a human team.

[See the Building with Claude Code bootcamp](https://builderscamp.com/bootcamps/building-with-claude-code?utm_source=guide&utm_medium=organic&utm_campaign=claude-code-subagents-for-pm-workflows) for the orchestration module, or [the AI Agents bootcamp](https://builderscamp.com/bootcamps/ai-agents) if the agent design question is the one you are actually stuck on. For the layer underneath both, [how to design an AI agent](https://builderscamp.com/guides/tools/how-to-design-an-ai-agent) covers scoping before tooling.

## Frequently asked questions

### Where does a subagent definition live?

In a markdown file under .claude/agents/ for a subagent the whole team gets through version control, or ~/.claude/agents/ for one that follows you across every project on your machine. The file is YAML front matter plus a system prompt.

### Which front matter fields are required?

name and description. name is lowercase with hyphens and is how the subagent is called. description tells Claude when to delegate to it. tools and model are optional: tools is an allowlist, and leaving it out means the subagent inherits what is available.

### Does a subagent see my conversation so far?

No. It starts with its own system prompt, the delegation message, your CLAUDE.md files and a git status snapshot. Conversation history, files already read and skills already invoked do not transfer, so the delegation prompt has to stand on its own.

### How do I make sure a specific subagent runs?

Mention it explicitly rather than relying on automatic delegation. Claude picks a subagent by matching the task against description fields, which is a guess. Naming the agent in your message removes the guess.

### Can I run a cheaper model for the boring subagent?

Yes. The model field accepts a tier such as sonnet, opus or haiku, or a full model ID, and defaults to whatever the main conversation is using. Routing a high-volume search job to a cheaper tier is a normal reason to set it.

### Can subagents edit files at the same time without colliding?

Only if you isolate them. Adding isolation: worktree to a subagent's front matter gives it its own git worktree, so its edits never touch the files another agent is working on.

### Is more subagents always better?

No. Each one starts cold and has to gather its own context, so a job you could finish in one pass gets slower, not faster, when it is split. Split when the branches are genuinely independent and each produces a lot of output you will never reread.

## Sources

- [Claude Code docs: Subagents](https://code.claude.com/docs/en/sub-agents)
- [Claude Code docs: Common workflows](https://code.claude.com/docs/en/common-workflows)
- [Claude Code docs: Best practices for agentic coding](https://code.claude.com/docs/en/best-practices)

## How this guide was made

Researched from Builders Camp's bootcamp, track and masterclass material and the sources listed on this page, drafted with AI, and fact-checked against every source cited.