Same conversation, two very different tools
Both subagents and skills show up when people talk about "extending" an agent, and both terms get used loosely enough that it's easy to conflate them. They're not close substitutes. A subagent is a way of organising who does the work. A skill is a way of shaping how the work gets done. You can use either without the other, and most non-trivial setups end up using both together. See What Are Agent Skills? for the fuller picture of where skills fit among an agent's other extension mechanisms.
What a subagent actually is
A subagent is a separate agent instance, spawned with its own context window, and often its own system prompt and tool set. When a main agent spawns a subagent, it hands off a task and gets back a result, the subagent's internal reasoning, exploration, and any dead ends it went down don't come back with it. Only the final output does.
That isolation is the entire point. Subagents exist to parallelise work (spin up three subagents to search three different parts of a codebase at once) or to keep a noisy, exploratory task from filling the main conversation's context with everything it tried before it found the answer.
The cost is real, though. Every subagent is a new context window, which means tokens spent restating relevant context, plus coordination overhead in deciding what to hand off and how to interpret what comes back. Spawning a subagent for a two-line task is usually slower and more expensive than just doing the two-line task.
What a skill actually is
A skill is an instruction package (a folder with a SKILL.md file) loaded into an existing agent's context on demand. There's no new instance, no separate context window, no handoff. The agent reading your message is the same agent that reads the skill and does the work.
Skills use progressive disclosure to stay cheap: at session start, the agent only reads each skill's name and description. The full body loads only when a request matches. That's why an agent can have a large skills library installed without any of it weighing on a conversation that never uses it.
The core trade-off
Subagents buy you isolation and parallelism, at the cost of coordination overhead and token spend. Skills buy you expertise, cheaply, in the current context, but they don't isolate anything. A skill's instructions run in the same conversation, competing for the same context budget as everything else in that thread.
Put differently: a skill changes what the current agent knows how to do. A subagent changes who is doing it, and where.
Side-by-side
| Agent Skills | Subagents | |
|---|---|---|
| What it changes | The current agent's knowledge and procedure | Who performs the work, and in what context |
| Context | Loaded into the existing conversation | Runs in its own, separate context window |
| Cost | Cheap — name + description at idle, full body only when triggered | Higher — new context, handoff overhead, token spend |
| Best for | Doing a task a specific, consistent way | Parallel work, or isolating noisy exploration |
| Output | Shapes the main conversation directly | Returns a result to the main conversation; internal steps don't come back |
| Composability | Can be loaded by a subagent too | Can load its own skills |
A worked scenario: reviewing a large pull request
Say a pull request touches forty files across a frontend and a backend, and your team has a specific checklist for how PRs get reviewed. Check for missing tests, check for exposed secrets, check that migrations are reversible.
Using subagents alone: you could spawn one subagent to review the frontend changes and another to review the backend changes in parallel, each returning a summary. That buys speed and keeps the two reviews from tangling in the same context. But without more instruction, each subagent reviews however it sees fit, no guarantee it checks for reversible migrations or applies your team's actual bar.
Using skills alone: a pr-review skill with your team's exact checklist ensures whichever agent does the review follows the same steps every time. But if the review sprawls across forty files, all of that reading happens in one context window, competing for space with everything else in the conversation.
Composed: spawn subagents per area of the codebase for isolation and speed, and have each subagent load the same pr-review skill, so every subagent applies the identical checklist. You get parallelism and consistency together.
project/
├── .claude/skills/
│ └── pr-review/
│ ├── SKILL.md
│ └── references/
│ └── checklist.md
---
name: pr-review
description: Use when reviewing a pull request for correctness, missing tests, exposed secrets, or unsafe migrations.
---
# PR Review
## Checklist
1. Confirm new logic has corresponding tests.
2. Scan diffs for hardcoded credentials, API keys, or tokens.
3. Check that any database migration has a working down step.
4. Flag any changed public API without a corresponding changelog entry.
See references/checklist.md for the full list by change type.
Every subagent spawned to review a slice of the PR loads this same skill, so "who reviewed which files" varies, but "what counts as a passing review" doesn't.
A second worked scenario: research versus a style guide
The PR review example is a coordination-heavy case. It's worth also looking at a case where the two pull in genuinely opposite directions, because that's where the trade-off is clearest.
Say you're asking an agent to research five competitors' pricing pages and summarise them. That task is a textbook fit for subagents: five independent lookups, none of which depend on what the others find, each one likely to involve some noisy back-and-forth. A wrong URL, a paywall, a page that needs a different search. Isolating each investigation in its own subagent means the main conversation only ever sees five clean summaries, not five investigations' worth of dead ends.
Now say instead you're asking the agent to rewrite five pages of marketing copy in your brand's voice. Nothing about that parallelises meaningfully, the five pages benefit from being written with a consistent voice, which is easier to hold in one context than to coordinate across five isolated ones. What actually matters here is that the agent applies the same style rules every time, which is a skill's job, not a subagent's. Spawning five subagents to rewrite five pages independently risks five subtly different voices, exactly the inconsistency problem skills are built to prevent.
The distinction isn't about task size. Both examples involve five units of work. It's about whether the units are independent (subagent territory) or need to stay consistent with each other (skill territory).
When a subagent is the right call
Reach for a subagent when the work genuinely parallelises (independent chunks that don't depend on each other's intermediate state) or when a task is going to be exploratory and noisy enough that you don't want its false starts cluttering the main thread. Long, multi-step research tasks and broad codebase searches are classic cases.
A subagent is the wrong call for anything small. If the task is a few tool calls deep, the overhead of spinning up a new context and interpreting its return value usually costs more than it saves. It's also the wrong call when the value you're after is consistency across the units of work. That's a job for a shared skill, not for isolation.
When a skill is the right call
Reach for a skill when you want the agent, whichever agent, main or subagent, to do something a particular way, consistently, without you having to restate the instructions every time. Style guides, review checklists, report formats, "the way we do X here": all of it belongs in a skill.
A skill is the wrong call when the problem isn't "how" but "where" or "how much at once." A skill can't parallelise anything and can't keep one exploratory dead end from bloating the current context. That's what a subagent is for.
They compose: a subagent that loads its own skills
The worked example above is the general pattern, not a special case. Any subagent is still an agent, and any agent that supports skills can load them the same way the main conversation does. That means the interesting design question usually isn't "skill or subagent". It's "which subagents do I need, and which skill should each one load."
A research pipeline might spawn a subagent per source to investigate in parallel, with every subagent loading a shared source-evaluation skill that defines how to judge credibility. A codebase migration might spawn a subagent per module, each loading a shared migration-pattern skill that defines the exact before-and-after shape of the change. In both cases, the subagent supplies the isolation and parallelism; the skill supplies the consistency.
Decision checklist
- Do you need the work done in parallel, or isolated from the main context? Use a subagent.
- Do you need the work done a specific way, consistently, wherever it happens? Use a skill.
- Do you need both, isolated parallel work that still follows your process? Compose them: subagents that load the relevant skill.
- Is the task small enough to just do inline? Skip both.
Where teams get this wrong
The most common mistake is reaching for a subagent to solve a consistency problem. Spawning three subagents to review three files, each with a slightly different unstated notion of what "good" looks like, produces three inconsistent reviews faster than one agent would have produced one inconsistent review. The fix isn't more subagents. It's a shared skill they all load.
The reverse mistake is trying to make one skill's instructions handle work that should be parallelised, cramming "review these forty files one by one, remembering everything about each as you go" into a single long-running pass. That's a context-management problem a skill can't fix on its own; it needs subagents to split the work up.
If you're not sure which side of this you're on, ask what would happen if you just described the task to a single agent in one context. If the answer is "it would get confused about which of several unrelated things to focus on first," you likely need subagents. If the answer is "it would do the task, just not the way we want," you need a skill. Browse the full skills directory for examples of the kind of procedural, repeatable work skills are built for.
Signals you're reaching for the wrong one
A few quick tells, if you're mid-task and unsure:
- You keep re-explaining the same instructions to every subagent you spawn. That's a sign the instructions belong in a skill all of them load, not in each handoff prompt.
- A single subagent's context is filling up with unrelated exploration. That's a sign the task should split into more than one subagent, not that it needs a bigger skill.
- Output is inconsistent across parallel subagents even though you gave them the same brief. That's the strongest signal you're missing a shared skill. A spoken brief gets reinterpreted each time; a skill loaded identically by every subagent doesn't.
- You're spawning a subagent for a task that's three tool calls long. That's almost always overkill. Just do it inline.
Where this fits with the rest of your setup
Skills and subagents aren't the only two levers available. Project-wide conventions that should apply to every task, subagent or not, belong in an always-loaded file rather than either of these. See Agent Skills vs AGENTS.md for that distinction. And if part of what a subagent needs is live access to an external system rather than a documented process, that's a job for MCP, not a skill. See Agent Skills vs MCP. Used together, the four pieces cover four different problems: AGENTS.md for what's always true, skills for how to do something well, subagents for isolating and parallelising work, and MCP for reaching outside the agent's own context entirely.
