Claude Code Subagents: How I Run a Team of AI Agents Across 14 Products

I run about 14 launched products by myself. Not a team, not contractors, just me and Claude Code. The single feature that made that number possible instead of insane is subagents: the ability to hand a slice of work to a separate agent, let it grind away in its own context, and get back a clean summary instead of a wall of file dumps.

Most guides I read on this topic make subagents sound either magical or trivial. They are neither. They save me hours some days and burn tokens for nothing on others, and the difference comes down to a few rules I learned the expensive way. This is the practitioner version: what subagents actually are, when they earn their keep, how to build one, what they really cost, and the exact setups I run across a portfolio of live products.

What are Claude Code subagents, exactly?

A subagent is a delegated worker that Claude Code spawns to handle one side task. The important part is that it runs in its own context window, with its own system prompt and its own scoped set of tools, and when it finishes it returns only a summary to your main conversation.

Think of it as a coworker you hand a single job. You do not want them to walk back into your office and read you every file they opened. You want the one paragraph that answers your question. That is the whole mental model, and it is why the official Claude Code subagents documentation frames the core benefit as preserving context: exploration and research happen somewhere else, and your main session stays focused on the decision you actually care about.

Everything good about subagents flows from that isolation. Because a subagent has a separate context, a research task that would have flooded your session with a hundred files instead comes back as a tight brief. Because it has its own tool list, you can build one that can read but never write. Because it has its own system prompt, you can make it a specialist that only reviews code, or only checks copy against brand rules.

When subagents actually help (and when they just burn tokens)

I have wasted real money spawning subagents for jobs that did not need them. Here is the honest split.

Where they earn their keep

Research fan-out. When I need to understand something before I change it, one subagent reads the relevant files or searches the web and hands back a synthesis. My main session never sees the raw noise. This is the single highest-value use, and it is exactly what Anthropic recommends in its own writeup on when to use subagents: if gathering context means reading dozens of files, delegate it.

Genuinely independent parallel work. When I have four product landing pages to audit and none depends on the others, four subagents running at once finish in roughly the time one would take sequentially. The keyword is independent. If one task needs another's output, parallelism buys you nothing.

A second opinion. A fresh subagent that never saw my conversation reviews a change without inheriting my assumptions or my blind spots. I use this before shipping anything I am nervous about. It catches the thing familiarity hides.

When NOT to use them

• Sequential dependent work. If step two needs the full output of step one, a subagent handoff just adds overhead. Do it inline.

• Same-file edits in parallel. Two subagents editing one file will collide. If parallel work touches shared files, isolate each in its own git worktree, which I cover below.

• Tiny tasks. Spawning a subagent to rename a variable costs more in setup than it saves. The overhead is real.

• Too many specialists. When I defined a dozen niche subagents, Claude got worse at picking the right one automatically. A handful of well-described agents beats a drawer full of them.

If you take one thing from this section: subagents are for work that is either noisy (so you want it out of your context) or independent (so you want it in parallel). Everything else is better done in the main thread.

Subagents vs agent view vs agent teams vs dynamic workflows

Here is the confusion almost every other guide creates: they use "subagents" to mean every kind of parallel work. Claude Code actually gives you four different surfaces, and picking the wrong one is why people get burned. The official run agents in parallel guide lays out the distinction, and this is the table I wish I had on day one.

• Subagents: delegated workers inside one session that do a side task and return a summary. Reach for them when a side task would flood your main conversation with output you will not reference again.

• Agent view: one screen to dispatch and monitor separate sessions running in the background. Reach for it when you have several independent tasks, want to hand them off, and step in only when one needs you.

• Agent teams: multiple coordinated sessions with a shared task list and messaging (experimental, off by default). Reach for them when you want Claude to split a project, assign pieces, and keep workers in sync.

• Dynamic workflows: a script that runs many subagents and cross-checks their results. Reach for one when a job outgrows a handful of subagents, or you want findings verified against each other.

The tell is coordination. Subagents report back to the one conversation that spawned them and do not talk to each other. If your workers need to communicate, that is agent teams, not subagents. If the job is a codebase-wide audit or a large migration you want cross-checked, that is a workflow. Most of what I do day to day is plain subagents, because most of my tasks are noisy-but-solo, not coordinated group projects.

How to create a custom subagent (the file that actually runs)

You do not need to create anything to start. You can just tell Claude to use a subagent for a task in plain language, and it will. Custom subagents are for when you keep spawning the same kind of worker with the same instructions and you are tired of repeating yourself.

A custom subagent is a markdown file with YAML frontmatter. Project-level agents live in .claude/agents/ in the repo; user-level agents that follow you everywhere live in ~/.claude/agents/. The file looks like this:

• name: a short slug like brand-copy-reviewer

• description: one line telling Claude when to hand work to this agent

• tools: the specific tools it may use (leave it read-only if it should never edit)

• model: set this to a cheaper model like Haiku for routine work

• the system prompt: the body of the file, the focused instructions for this specialist

The field that matters most is the description. It is the trigger. Claude reads it to decide whether a task matches this agent, so "reviews marketing copy against the brand voice rules before publishing" delegates reliably, while "copy helper" does not. I have fixed more misfiring subagents by rewriting one sentence of description than by any other change. The fastest way to build one is to ask Claude to scaffold the file for you and then tighten that description yourself.

If you want the guided version of all of this, plus the rest of the systems I run, that is what the Reinventing AI Accelerator is for. The live sessions walk through these builds end to end.

The part nobody mentions: what parallel subagents actually cost

Every subagent has its own context window, which means it burns its own tokens. Three subagents running in parallel cost roughly three times what doing the work once would. Anthropic says this plainly in the docs: running several subagents at once multiplies token usage. Nobody selling you a "run 10 agents at once" thread mentions the invoice.

Two habits keep this sane. First, route routine work to a cheaper model. Set model: haiku in the subagent's frontmatter for anything that is reading, summarizing, or checking, and save the expensive model for the reasoning you actually need it for. A research fan-out on Haiku costs a fraction of the same work on a frontier model and is usually just as good at "read these and tell me what matters."

Second, do not run parallel agents on shared files. When I need real parallel edits, each subagent gets its own git worktree, a separate checkout so two agents never touch the same file at once. That is the safe way to actually parallelize writes instead of creating merge chaos. For pure reading and research, worktrees are overkill; a plain fan-out is fine.

The blunt version: parallelism is a spend, not a free speedup. I use it when wall-clock time matters more than token cost, and I stay sequential when it does not.

How I actually use subagents across 14 products

Concrete beats abstract, so here are the real setups.

The marketing team. My daily marketing routine spawns specialists: one drafts, one checks every line against my brand voice files, one that can read but never send handles the risky steps. It runs as a scheduled system, and the whole build is in my Claude Code marketing automation writeup. This exact "team of agents" pattern is what I covered live in the Turn Claude Code Into Your Marketing Team session, and the full replay is available instantly if you want to watch me build it.

SEO research fan-out. My blog engine sends a subagent to pull and analyze the current top-ranking pages for a keyword before I write a word. It comes back with word counts, headings, and gaps, and my main session never drowns in scraped HTML. The full self-driving loop is in how I publish a ranking post every weekday.

The portfolio sweep. Once in a while I fan out one read-only subagent per product to check for a broken link, a stale price, or a dead CTA. Fourteen independent checks, run at once, reported back as one list. This is the textbook independent-parallel case, and it is the only time I regularly run that many agents together.

The skeptic. Before anything customer-facing ships, a fresh reviewer subagent with no memory of my reasoning tries to poke holes in it. Half the time it finds nothing. The other half it saves me from myself.

Try it on one real task this week

If you are running even two or three projects, subagents are the difference between drowning and shipping. Start small: next time you catch yourself about to read a pile of files just to understand something, hand it to a subagent instead and ask for the summary. That one habit is where the leverage begins.

If you want the whole system rather than the pieces, the Reinventing AI Accelerator gives you the live training sessions plus the growing vault of AI apps, tools, and agents I actually run. One membership, the real builds, no fluff. That is the one ask I will make here.

Frequently asked questions

Do Claude Code subagents run in parallel or sequentially?

Both, depending on the work. Subagents can run in parallel when the tasks are genuinely independent, which is where the speedup comes from. But when they need to modify the same files, or when one task depends on another's output, they effectively run in sequence. Parallelism only helps for independent work.

Can a subagent spawn its own subagents?

Treat the answer as no for planning purposes. Subagents report their results back to the single conversation that spawned them and do not coordinate with each other. If you need workers that talk to each other or a lead that assigns and supervises tasks, that is Claude Code's agent teams feature, not subagents.

How much do subagents cost compared to one session?

Each subagent has its own context window and burns tokens independently, so running several at once multiplies your usage roughly by the number of agents. Route routine reading and summarizing work to a cheaper model like Haiku in the subagent's frontmatter, and reserve parallel runs for when finishing faster is worth the extra spend.

What is the difference between subagents and agent teams?

Subagents are delegated workers inside one session that return a summary and do not talk to each other. Agent teams are multiple coordinated sessions with a shared task list and direct messaging, managed by a lead agent. Subagents are for delegating side tasks; agent teams are for splitting a project across workers that need to stay in sync. Agent teams are experimental and off by default.

Do I need to create custom subagents to use them?

No. You can just ask Claude to use a subagent for a task in plain language and it will spawn one. Custom subagents defined as markdown files in .claude/agents/ are only worth it when you keep spawning the same kind of worker with the same instructions and want it to trigger automatically.