Don't Talk to One Claude. Spawn a Team Instead.

I asked Claude to help me write this guide, and the way I described what I wanted was: spawn a couple of subagents, have them look into this from different angles, then come back to me with something synthesized. That instruction is the actual subject of the guide, not just the topic. So before going further: this is what happened. One Claude read this brief, decided which angles were worth covering, sent parts of the research off to run on their own, and brought back a draft. I didn’t watch each step. I read the result and asked for changes.

If you’ve used Claude Code for more than a few weeks, you’ve probably felt the limits of the version most people stop at: one continuous conversation where you ask, it does something, you read the result, you ask again. That works. It also means every search result, every file it opened to understand your question, every dead end it explored sits in the same conversation as everything else, getting larger, slower, and noisier the longer the session runs. I’ve written before about why a full context window quietly makes the AI worse, not just slower. Subagents are the fix for the specific case where the work itself, not just the conversation, is what’s filling that window.

What a subagent actually is

Picture Claude Code as a project lead sitting at a desk. A subagent is a second copy of Claude the lead can send out on an errand, something like “go read every file that touches the checkout flow and tell me what changed.” It works from its own blank desk, with its own copy of the instructions and none of the clutter from the lead’s desk. It does the digging. It doesn’t show its work. It comes back with a short report, and its desk, all the files it opened, all the false leads it followed, gets cleared the moment it’s done.

That’s the whole mechanism. Three things make it different from just asking the same Claude to do three things in a row.

Isolation. The subagent starts with nothing from the main conversation except what it’s explicitly told. It can’t see what you said five minutes ago, and it doesn’t need to. It has one job and exactly the context required to do it.

Parallelism. Each subagent is its own separate run, so several can go at once. The lead isn’t waiting on subagent one to finish reading file A before it can ask subagent two to read file B.

Compression. A subagent might read ten files and run twenty searches to answer one question. What comes back to the main thread is one paragraph, the answer, not the search history. The lead’s own context window stays clean for the part of the job that actually needs continuity: deciding what to do with the answer.

In Claude Code, this is built in. Ask it in plain language, something like “research this using a few different angles in parallel” or “check each of these five files for the same bug, in parallel,” and it can decide on its own to spin up subagents for the pieces that are genuinely independent. A few specialists ship by default too, one built for searching a codebase and one built for drafting a plan before any code gets touched, and you can write your own with a short brief saved to the project for anything you find yourself delegating the same way more than once.

This isn’t a Claude Code exclusive, and it’s worth being precise about where the real line falls. It isn’t Anthropic versus everyone else, it’s agentic harness versus reactive chat. Claude.ai’s regular chat doesn’t do this: a single back-and-forth conversation has no ongoing task to delegate from, and the same is true of the regular ChatGPT and Gemini apps. OpenAI’s Codex ships its own subagent setup, and Google’s Gemini CLI (folding into Antigravity) added subagent support in April 2026, both running the same lead-delegates-to-specialists shape described here. Claude Cowork, Anthropic’s agent for non-coding office work, runs on the same underlying engine as Claude Code, so the architecture is very likely there too, though I haven’t confirmed the feature is exposed in Cowork’s interface the same explicit way it is in Claude Code.

Can you make a subagent that thinks like your CTO?

Yes, and it’s worth understanding exactly what you’re buying when you do.

Every subagent runs from a system prompt: standing instructions that stay the same every time it’s called, no matter what triggered it. The specialists Claude Code ships with by default work this way. You can write your own the same way: a short saved brief that says, in effect, “when you’re called, weigh things the way a CTO would. Favor maintainability and hiring cost over the elegant solution, flag anything that adds a single point of failure, ask what breaks at ten times the current scale before agreeing it should ship.” Save that once and you can call on a CTO-shaped subagent by name from then on. My notes on running parallel sessions describe doing the same thing mid-conversation, asking AI to play a behavioural economist or a first-principles thinker on the spot. The difference here is that the persona is saved, not retyped.

A saved subagent can go further than the persona prompt, too. You can pin it to a specific model (the CTO subagent on your strongest reasoning model, because judgment calls are exactly where a cheaper model gets shallow) and restrict its tools (a reviewer subagent that can read code but has no ability to edit it, so it structurally can’t “fix” the thing it’s supposed to be critiquing rather than just being told not to). You don’t need a saved subagent to make the model choice, either: spawning one in the moment, you can name a model in the same breath, something like “run the competitor research as a cheaper, faster subagent, but put the final synthesis on your strongest model.” The same logic from thinking expensive, executing cheap applies subagent by subagent: one doing simple lookups doesn’t need your priciest model, one making a judgment call does.

Where this earns its cost over telling the orchestrator “look at this like a CTO would” in the moment: reuse, restriction, and accumulated specifics. If you only need that lens once, typing the sentence is cheaper than maintaining a file, and the model already knows broadly what a CTO weighs. Naming the persona doesn’t unlock hidden knowledge by itself. A saved subagent pays off once you call on the same lens repeatedly and want it applied the same way each time, once you actually need the tool or model restriction, or once the persona starts holding context that’s specific to you rather than generic. A bare “CTO subagent” gives you the same generic CTO judgment an ad hoc instruction already gets you, because that’s all the model has to draw on. A CTO subagent whose standing instructions also say “always flag anything that increases our compliance surface, because we operate in a regulated industry” gives you something the model didn’t already know going in. The model supplies the general knowledge either way. What you save into a standing subagent is the part that’s actually yours: the specifics that turn a generic expert into your expert.

Why people actually do this

The clearest public account of why this pattern earns its cost is Anthropic’s own writeup of how they built Claude’s research feature, which runs exactly this way. One lead agent plans the question and breaks it into pieces, and a set of subagents investigate those pieces at the same time, each with its own search budget, before the lead stitches the findings into one answer. Internally, the multi-agent version beat a single, very capable agent working alone by 90.2% on their research evaluation. Simon Willison, who writes one of the more widely read engineering blogs on AI tooling and had been openly skeptical that running several agents in parallel was worth the trouble, called the piece the thing that “cured me of that skepticism.” His prior question had been why bother running multiple prompts in parallel when one well-crafted prompt against a frontier model usually does the job. Anthropic’s own numbers were the answer: it doesn’t, for the kind of question that genuinely branches into independent sub-questions.

It isn’t free. Anthropic also reports that the multi-agent version burns through roughly 15 times the tokens of a single chat reply, and that token usage alone explains most of the performance gap. The lead is covering more ground, because the work was split up and run at once instead of one thing at a time. It isn’t a smarter lead, just a busier team. That’s the trade in one sentence: you’re buying coverage and speed with tokens.

The same shape shows up at a much smaller scale in ordinary coding workflows. One developer, writing on his blog at hamy.xyz, described setting up nine subagents to review every pull request, one each for things like security, performance, and test coverage, instead of one pass trying to hold all of those concerns in its head at once. His own comparison put the share of genuinely actionable suggestions noticeably higher than a single reviewer pass, on the logic that an agent looking only for SQL injection misses less than an agent trying to think about SQL injection, performance, and naming conventions at the same time. The same idea, scaled down: a subagent that only knows about your database layer writes better database code than one juggling your whole project at once, for the same reason a specialist catches things a generalist skims past.

A lot of what I do on this site is naturally this shape without me planning it that way. When I drop a batch of new tools into the content inbox and tell Claude to process it, that’s not one task. It’s a handful of independent ones: research pricing and positioning for tool A, check whether tool B already exists on the site, find a logo for tool C. None of those depend on each other. If Claude works through six tools one after another in the same conversation, that’s six rounds of pricing pages and search results stacked on top of each other, and by tool six the context is full of details about tools one through five that no longer matter. Send six subagents instead, one per tool. They go at once, each one starting clean and forgetting the irrelevant tool’s pricing page the second it’s done, and what comes back to me is six short write-ups instead of six tools’ worth of raw research I’d otherwise have to wade through myself.

Where it costs more than it’s worth

The 15x token number is the headline, but the subtler cost is coordination. A subagent can’t ask you a clarifying question mid-task the way a normal conversation can. It works from the brief it was given and reports back once, so a vague instruction produces a vague result with no chance to course-correct until it’s already done. The more subagents running at once, the more ways that can go sideways, and the more the lead has to actually read and reconcile what comes back instead of assuming it’s all consistent.

That reconciliation step is also where the real value sits, and it’s easy to skip. Anthropic’s writeup makes the same point about their own lead agent: it’s the one place that sees all the answers together, so it can catch a connection none of the individual subagents could, a finding from one angle that only matters in light of a finding from another. Spawn five subagents and paste their five reports back to back without anyone actually synthesizing them, and you’ve paid the token cost and skipped the part that made it worth paying.

There’s one kind of task where I deliberately don’t reach for this, on this exact site: writing. I don’t get Claude to draft a guide by splitting it across three subagents writing different sections in parallel. Voice has to come from one continuous thread that can see the whole piece end to end, where a sentence two paragraphs back rules out a phrase you’re about to reach for, where the rhythm of the last section sets up the next one. Three subagents who can’t see each other’s work will each reach for their own rhythm, and stitching that back together reads like three different writers, because it was. Research for the piece is a different matter. That’s exactly the kind of independent, parallel digging subagents are good at. The actual writing stays in one thread.

The general rule underneath both examples: reach for subagents when the work itself splits cleanly into pieces that don’t need to talk to each other while they’re happening, like research, parallel file checks, or independent reviews. Skip it for anything short enough that the coordination overhead outweighs the work, and skip it for anything where the value is in one continuous thread of judgment that the pieces would lose by being apart.

Trying it

You don’t need to set anything up to start, and you don’t need a developer’s task to try it on. Take a real business decision you’re sitting on and ask for it the way you’d ask a small team to look into it before you decide:

“I’m deciding whether to raise the price of our Pro plan from $29 to $39 a month. Spawn three subagents to look into this in parallel: one that only looks at what this does to customer churn and retention, one that only compares it to what competitors charge for something similar, and one that only runs the revenue math assuming we lose a meaningful share of customers at the new price. Have each come back with a short verdict, then give me your own synthesis of whether this is worth doing.”

Three independent angles, three subagents, one synthesis you actually read. That’s the whole pattern, on a question that has nothing to do with code. Watch what comes back against what you’d have gotten from asking the same thing in one long thread, where the churn analysis, the competitor research, and the revenue math blur into the same paragraph instead of standing on their own.

If you find yourself asking for the same kind of delegated task more than once or twice, the same review checklist, the same research shape, that’s the point where it’s worth saving as a named subagent you can call on instead of re-explaining the brief each time.

---

This is a different shift from the one in The Orchestrator’s High, which is about you personally running several separate Claude Code sessions in parallel across windows and desktops. Subagents are one session doing that delegation internally, without you having to be the one switching screens. For the mechanics of running Claude Code day to day, see Claude Code: When AI Stops Talking and Starts Doing. And if context windows filling up is the part you actually came here for, What the Context Window Is, and What to Do About It is the piece this one builds on.