A subagent is an independent instance the main agent dispatches mid-task: its own system prompt, its own context window, its own tool list and permissions. It does the work, hands back a conclusion, and disappears.
The problem it addresses is concrete: a long task contains a lot of rummaging — reading twenty files to find three lines, running tests five times to locate one error. That process fills the context while contributing little to the final decision. A subagent keeps the rummaging in a separate window and brings back only the result.
Grab It in One Sentence First
A Subagent is a stand-in the main agent sends to look something up: the process stays with it, only the conclusion comes back.
An everyday analogy is sending an assistant to research something. You say "pull together the return reasons for the East region in Q3," and the assistant goes through two hundred pages of records, makes six phone calls, and comes back with one page. You don't need to know which two hundred pages — handing you all of it would make the point harder to find, not easier.
Why This Term Emerged
The immediate reason is that the context window runs out, but a more accurate framing is that the signal-to-noise ratio inside the window degrades. By the time a several-hundred-thousand-token window is two-thirds full, answer quality often starts slipping — not because the model got worse, but because it must attend to a screen full of noise on equal terms.
Hence a counterintuitive but useful framing: subagents don't make the AI smarter; they protect the clean context the main session already has.
Anthropic's multi-agent research offers supporting data: multiple agents holding isolated context clearly outperformed a single agent on breadth-first research tasks, beating a single Claude Opus 4 agent by around 90.2% in internal testing — in part because each subagent's window could be allocated entirely to a narrower sub-task.
flowchart TB
Main["Main agent (orchestrator)<br/>holds the overall task"] -->|"dispatch: one prompt string only"| S1["Subagent A<br/>isolated window"]
Main -->|dispatch| S2["Subagent B<br/>isolated window"]
S1 -->|"returns only the final conclusion"| Main
S2 -->|returns only the final conclusion| Main
S1 -.->|intermediate work stays inside| X1["read files / run tests / search"]
S2 -.-> X2["read files / run tests / search"]
Main --> Out["Integrate and deliver"]What It Usually Includes
Taking Claude Code's implementation as the example, a subagent is spawned from the main session via the Agent tool (originally called Task). Each subagent is defined by a markdown file under .claude/agents/: YAML frontmatter at the top for name, description, available tools, and model, with the body serving as its system prompt.
The channel is deliberately narrow: in goes only the prompt string of the dispatching call, and out comes only its final reply. Every intermediate tool call, file read, and line of test output stays inside the subagent's own window and is never injected into the parent. What the parent receives is that final message.
A few constraints are worth remembering: a subagent can't spawn subagents of its own, so when it hits something that would normally warrant delegation it works through it in its own context; it exists only for the duration of its task and is destroyed afterward; and independent sub-tasks can be dispatched in parallel, which is the pattern's most direct performance win.
The Difference from Multi-Agent Teams and Skills
Anthropic draws a clean line: subagents work within a single session, while agent teams coordinate across sessions. Each teammate has its own window and is fully independent, at the cost of higher token usage and with the benefit of genuine peer-to-peer coordination. The rule of thumb is to reach for subagents first and escalate to teams only when they aren't enough.
Agent Skills are a third option with a different use case: reach for a skill when you want a reusable set of instructions that runs in the main conversation context; reach for a subagent when you want the execution isolated in a separate window. One reuses knowledge, the other isolates context.
Its Relationship to Context Engineering
Among the four strategy buckets of context engineering, subagents are the most typical implementation of "isolate" — splitting context by sub-task, each piece carrying its own tools and instructions without contaminating the others. It's often paired with "compress" (compaction): isolate what can be isolated, then compact the long history that remains.
Where It's Easy to Misunderstand
The first misconception is "more dispatching is better." Every dispatch has a fixed cost: the subagent has to build up its own understanding of the task, and it doesn't get the parent's history. For tasks needing substantial background to judge, the cost of restating that background can exceed what you save.
The second is assuming subagents can talk to each other. By default they're mutually invisible, and sharing information has to go through the parent or through an external file. When designing parallel work, make sure the sub-tasks are genuinely independent, or two subagents may make conflicting changes.
The third is treating them as a debugging black box. By default very little of what happens inside is exposed, so when something goes wrong you need to expand the message history to see the prompt it received and the conclusion it returned — otherwise you can't tell whether the dispatch description was poor or the subagent went off course.
How to Decide Whether to Use It
Good candidates share three traits: a long process with a short conclusion (broad searches, locating a bug, walking a directory for usages), little relevance to the main thread's context (it doesn't need to know what you discussed earlier), and being describable in a single paragraph (since a paragraph is all you can pass).
The poor fits are equally clear: exploratory work where you'll keep questioning and redirecting, tasks needing a lot of main-session background to judge, and parallel tasks that modify shared state and depend on each other. One more gets overlooked: if the task is only a few steps, the fixed cost of dispatching can exceed just doing it inline.