Everyone says subagent now. Here's what the word actually means on the platforms that use it, and when reaching for one helps instead of just adding moving parts.
An agent is any AI system running its own loop of reasoning and action toward a goal. A subagent, specifically in Claude Code and the Claude Agent SDK, is a separate agent instance that a main agent spawns for one bounded job, with its own context window and tool permissions, that returns a summary rather than its full working. This piece covers when a subagent actually earns its place, how to brief both the main agent and the subagents it dispatches, a real look at how Future Factors’ own blog pipeline uses research, writing and QA subagents, and the mistakes, vague briefs, unbounded nesting, redundant subagents, that turn a good idea into more moving parts than the job needed.
Say you’re running one long Claude Cowork conversation to put together a client proposal. You ask it to look into the client’s industry, draft the proposal, then check the numbers against what closed last quarter. Two hours in, the numbers check comes back referencing the wrong company, because thirty messages earlier you mentioned a competitor by name and the conversation never quite let go of it.
The cause is a context problem, not a prompting one. Everything that conversation has ever seen, every search result, every draft, every correction, sits in the same window competing for attention. The fix a lot of teams reach for is a second agent. But “agent” and “subagent” get used almost interchangeably in casual conversation, and the difference is worth being precise about, because getting it wrong is how you end up with five agents doing the job of one confused agent.
An agent, in the general sense, is any AI system running its own loop of reasoning, acting, and observing results, usually toward a goal you gave it in one sitting. A subagent is something narrower and platform-specific. In Claude Code and the Claude Agent SDK, a subagent is a separate agent instance that a main agent spawns to do one piece of work: it gets its own context window, its own system prompt, and its own tool permissions, and when it finishes, only its final summary comes back to the parent conversation, not the searches and drafts it generated along the way. [1] Claude Cowork runs on the same underlying pattern: the agent working with you can dispatch a piece of work to a subagent, wait on or set aside the result, and keep its own conversation free of the raw material that subagent produced.
That’s the Claude-specific meaning, and it isn’t the only one. In the broader multi-agent-systems world, people use “subagent,” “worker agent,” and “specialist agent” fairly loosely for any agent that a coordinating agent hands a narrower task to, regardless of which company’s tooling is involved. There’s no single industry standard here. If you’re reading about subagents outside Anthropic’s own documentation, check which meaning the author is using before assuming it matches what Claude Code or Cowork actually does.
A subagent earns its place when a piece of work needs its own clean context and a clearly bounded job, not because splitting things up sounds more sophisticated.
If you’re still getting oriented to what Cowork actually is before any of this, this plain-English guide is a reasonable place to start. Everything past this point assumes you already have one agent working for you and are deciding whether it needs help.
Priya runs operations for a 40-person agency, and last spring she built herself a single Cowork workflow to handle client onboarding: pull the signed contract, look up the client’s competitors, draft a kickoff brief, then quality-check the brief against the contract terms. One agent, one long conversation, four jobs.
It worked for the first two clients. By the fifth, the kickoff briefs had started repeating material from a different client’s competitor set, and the QA step kept passing briefs that didn’t actually match the contract. Nothing had broken in any obvious way. The conversation had simply accumulated four jobs’ worth of context, and the agent was doing what agents tend to do once a conversation gets crowded: quietly favoring whatever was most recent over whatever was actually relevant.
Here’s the decision rule worth applying before you reach for a subagent at all. Ask whether the sub-task would flood the main conversation with material nobody needs to see again once the useful part is pulled out, or whether you want a clean, reviewable unit of output you can check on its own. Fact-finding is the clearest case: fifteen searches and a pile of half-relevant pages are useful for producing one paragraph of findings, and clutter as permanent residents of your main conversation. Anthropic’s own description of subagent benefits names this directly: context isolation so exploration doesn’t spill into the main thread, and parallelization so independent pieces of work finish in roughly the time of the slowest one instead of stacking up one after another. [2]
Priya’s fix, once she saw the pattern, was to split the one workflow into three: a fact-finding subagent scoped to a single client at a time, a drafting step that stayed in her main conversation because it needed her judgment throughout, and a QA subagent whose only job was comparing the draft against the signed contract line by line. The operator-style approach to Cowork goes into this kind of restructuring in more depth, including what should stay with you rather than get delegated at all.
| Signal | Give it to a subagent | Keep it in the main agent |
|---|---|---|
| Volume of raw material | Produces many searches, logs, or draft pages you won’t reread | Produces one short, direct answer |
| Independence | Doesn’t need the last ten messages of context to make sense | Depends heavily on decisions made earlier in the conversation |
| Judgment required | Follows a checklist or comparison you can describe in two sentences | Requires weighing tradeoffs specific to this situation |
| Reviewability | You can check the output without redoing the work | You’d have to redo it yourself to know if it’s right |
Run through this before creating a new subagent. Two or more “give it to a subagent” answers is a reasonable signal. One on its own often isn’t enough.
Once Priya had three pieces instead of one, the harder problem showed up: her main agent still had to decide when to call the fact-finding subagent, what to hand it, and what to do with what came back. That’s the orchestrating agent’s actual job, and it’s easy to get backwards. The instinct is to treat the main agent as a dispatcher that fires off subagents and assembles whatever returns. The better model is a main agent that keeps the judgment calls for itself and uses subagents only for the parts that don’t need them.
A few habits make the main agent’s side of this work in practice.
The genuinely hard part, and the one most teams skip, is deciding what stays a human call no matter how good the subagent’s output looks. This is where most of the actual review time should go, whether the work is client onboarding, a background summary, or a piece of published content.
| What the subagent does | What the human still owns | How it gets checked |
|---|---|---|
| Gathers and summarizes research from a defined set of sources | Deciding which findings actually matter for this client or decision | Spot-check two or three of the cited sources before the summary gets used |
| Drafts a first pass of a document against a template or brief | Tone, judgment calls, and anything client-specific that wasn’t in the brief | A human reads the full draft, not just a summary of it |
| Checks a draft against a checklist: facts, links, formatting, banned phrases | Deciding what to do when the QA subagent flags something borderline | A second read on anything flagged, before it ships |
The subagent produces material. A person still decides whether it’s right. Skipping the “how it gets checked” column is the most common way delegation quietly turns into abdication.
A subagent is only as good as the two or three sentences you hand it, so put your effort there, not into picking a clever name for it.
Here’s what a vague brief actually produces. Say a subagent gets the instruction “look up subagent trends for our blog.” It comes back with three paragraphs about the general growth of AI agents, no named sources, and nothing you couldn’t have written yourself from memory. Nothing went wrong technically. The subagent did exactly what an open-ended, undefined brief invites: it produced something plausible-sounding instead of something checkable, because “look up subagent trends” isn’t a job. It’s a direction.
Compare that to: “Find the current definition of ‘subagent’ in Anthropic’s own Claude Code and Agent SDK documentation. Quote the exact wording. Note the last-updated date if it’s visible. Don’t summarize from memory, only state what’s actually on the page.” That version has a finish line. The subagent knows what done looks like, and so do you, when you check it.
A few habits keep subagents useful rather than decorative:
| Field | Example |
|---|---|
| Job in one sentence | Verify the three statistics in this draft against their original sources and flag anything that doesn’t match. |
| What “done” looks like | Each stat marked confirmed, doesn’t match, or source not found, with a one-line reason. |
| What it can access | Web search and the draft document. Nothing else. |
| What it should not do | Rewrite the draft, add new statistics, or decide whether to keep a flagged stat. |
| What comes back | A short table, one row per statistic, not a narrative of the search process. |
This is the level of specificity that separates a subagent producing something checkable from one producing something merely plausible. Swap the top row for whatever you’re delegating.
Give a subagent a way to know it’s done, or it will keep going until it runs out of turns, not until the job is actually finished.
The level of detail in that brief is worth keeping somewhere reusable rather than reinventing each time. A shared prompt library is a natural home for the handful of subagent briefs your team ends up reusing.
How much detail a brief needs also depends on who’s writing it and what the subagent touches. Someone using subagents for content work can scope a QA subagent tightly around facts, links, and formatting. Someone automating fact-finding can scope theirs around source freshness and verification instead. Someone building a subagent into a customer-facing workflow is working under a stricter bar, because “good enough to check later” isn’t good enough when the output might reach a customer before a person ever sees it.
Future Factors runs its own blog through a daily pipeline, and it uses this exact pattern rather than one long editorial conversation. When an article like this one gets written, the work is split across a small number of subagents dispatched for specific jobs: one focused on fact-finding and source verification, one focused on drafting sections against a brief, and one focused on quality assurance, checking the draft against a fixed checklist for factual claims, broken or irrelevant links, banned phrasing, and template requirements before anything gets published.
Nothing about that setup is exotic. It’s the same decision rule from earlier in this piece, applied to one recurring job. Fact-finding generates a pile of search results nobody needs to keep. Drafting benefits from a subagent that can focus purely on the brief in front of it, without the accumulated back-and-forth of a long editorial chat. QA works better as an independent check that isn’t shaped by having watched the piece get written. Keeping those three separate is what lets each one stay narrow enough to actually check.
What doesn’t change, regardless of how many subagents are involved, is who owns the call on whether an article is accurate and ready to go out. The QA subagent can catch a broken link or a banned phrase reliably. It can’t decide whether a genuinely borderline claim is worth including, and it isn’t asked to. That decision routes back to a person, the same principle from the ownership table earlier in this piece, just applied to publishing instead of client onboarding.
The specifics of how each subagent is configured, which tools it gets, exactly how its output gets passed along, aren’t the interesting part here. The interesting part is that splitting the job this way is what makes daily publishing checkable at all, rather than one long conversation that gets harder to audit the longer it runs.
Say a small team gets excited about subagents after their first success and starts creating one for everything: a subagent to check grammar, a subagent to check tone, a subagent to check grammar again in a slightly different voice. Three weeks in, nobody can say which subagent is responsible for what, two of them are doing overlapping checks, and a simple typo fix now involves reading three separate summaries to figure out which one should have caught it.
That’s the most common failure, and it’s rarely about the technology. It’s scope creep dressed up as sophistication. A few other patterns show up often enough to name directly.
| What you see | Likely cause | What to fix |
|---|---|---|
| Generic, unusable output | The brief described a topic, not a job with a finish line | Rewrite the brief around one sentence of “done” |
| Two subagents overlap | Both were scoped around the same kind of check instead of a distinct one | Merge them, or redraw the boundary between their jobs |
| Costs climb without a clear reason | Subagents are spawning subagents of their own, unmonitored | Set an explicit limit on how many layers deep a chain can go and how many can run at once |
| Nobody catches a mistake until it ships | The output was treated as final rather than reviewed | Reintroduce a specific human check before anything downstream uses the result |
Most of these trace back to an unclear brief or a missing limit, not to the subagent doing something unexpected.
The costs-without-explanation row is worth taking seriously if you’re working in Claude Code or the Agent SDK directly rather than through a simpler interface. Subagents can spawn subagents of their own, and by default the Agent SDK allows a chain three layers deep and up to 20 running at once within a single query. [3] That’s a reasonable default for a lot of work. It’s also exactly the kind of setting that turns one ambitious prompt into a much larger bill than expected, if nobody sets a tighter limit for the job at hand.
More subagents is not the same as more sophistication. It’s more places for a small mistake to hide before anyone reviews it.
The pattern underneath most of these mistakes is the one from the start of this article: subagents are a tool for isolating a specific, bounded job, not a general sign of a more advanced setup. A team running one well-scoped subagent for the single task that actually needs it is doing this better than a team running six that nobody can describe individually.
If you want to try this on something real this week, pick one recurring task you currently run inside a single long agent conversation. Take just the fact-finding or the QA piece of it, write a two-sentence brief for it using the finish-line test from earlier, and hand that one piece to a separate subagent. Don’t restructure the whole workflow yet. See what a properly scoped subagent produces before deciding whether the rest of the job needs the same treatment.
An agent is any AI system running its own loop of reasoning and action toward a goal. A subagent, in Claude Code and the Claude Agent SDK specifically, is a separate agent instance that a main agent spawns for one bounded piece of work, with its own context window, tool permissions, and system prompt; only its final summary returns to the parent conversation. Outside Anthropic’s own tools, “subagent” is also used more loosely across the multi-agent-systems world for any narrower worker agent a coordinator delegates to, so the exact meaning shifts depending on which platform or paper you’re reading.
For most single-step or short tasks, one agent is enough, and adding subagents adds overhead without adding value. Reach for a subagent when a task would flood your main conversation with material you won’t need again, like dozens of search results or long logs, or when you want an independent, reviewable check on something, like QA on a draft. If your current agent conversation is short and focused, it doesn’t need subagents yet.
Yes. In Claude Code and the Claude Agent SDK, a subagent can spawn subagents of its own, and by default that nesting is allowed three layers deep with up to 20 subagents running at once in a single query, both of which are configurable. In practice, most non-technical use cases don’t need more than one layer: a main agent dispatching a handful of subagents directly. Deeper nesting adds real value for large, genuinely parallel jobs and adds real risk of runaway cost and confusion for everything else.
Writing the brief too vaguely and expecting the subagent to fill the gap with judgment. A subagent only sees what’s in its prompt, not your reasoning or your conversation history, so a vague instruction like “research this” produces something plausible rather than something useful. The fix is describing the job in a sentence or two with a clear definition of “done,” the same way you’d brief a contractor who has never spoken to you before.
It depends on how they’re used. Running subagents in parallel for independent pieces of work can finish faster than doing everything sequentially in one conversation, since each one works in its own context and doesn’t wait on the others to finish unrelated steps. But every subagent makes its own set of requests, so cost scales with how many you spawn, not just with how much total work gets done. An unscoped setup where subagents spawn further subagents can get expensive quickly, which is why setting a limit on depth and concurrency matters once you’re doing this beyond a single well-defined task.
Sana writes Future Factors’ guides on making AI agents actually usable inside a normal workday. The Claude Code and Agent SDK documentation referenced in this piece was read directly on docs.claude.com on 31 August 2026, not taken from secondhand summaries of it. If you want to work through scoping subagents for your own team’s workflows in person, that’s exactly the kind of thing covered in Future Factors’ practical AI courses.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.