Claude Skills vs Subagents: When to Use Each

Use a skill when you want to change how the current agent works; use a subagent when you want the work done somewhere else.That single distinction settles most of the arguments. A skill is loaded into the conversation you're already having — it's a procedure, a checklist, a set of conventions the same Claude follows next. A subagent is a fresh Claude with its own system prompt and its own blank context window, doing work you never see, returning only a summary.

I lean on the multi-tool picture at the top of this page. A skill is the folding multi-tool: one thing you keep reaching for, always in the same hand, reusable across jobs. Subagents are the row of specialists — you hand each one a single task, they do it in isolation, and you collect the results. Same workshop, two very different moves.

Strip away the marketing and three properties decide everything:

• Context: A skill shares the current context window — it can see the conversation so far, and its instructions add to that same budget. A subagent starts empty. It only knows what you pass it, and its work never touches your window until it reports back.
• Isolation: A skill has none — it's the same agent, same tools, same permissions. A subagent is isolated: its own system prompt, its own tool set, optionally a different model. What happens in the subagent stays in the subagent unless it's in the summary.
• Control flow: A skill is loaded when its description matches the task, then the current agent keeps going. A subagent is a deliberate hand-off — you decide to delegate, it runs to completion, and only then do you get a result to act on.

That last one, context, is the property people underrate. Your context window is a budget, and the fastest way to blow it is a wide search that reads forty files to answer one question. Send that to a subagent and the forty files land in its throwaway window; your main context only ever sees the two-sentence answer. I dug into that math in what a Claude subagent actually costs in tokens — the fixed overhead is real, but on big reads it pays for itself several times over.

If you're also weighing whether the capability should live in an MCP server instead of either of these, that's a related-but-separate call — I split it out in Claude Skills vs MCP. Short version: skills and subagents shape youragent's behavior; MCP is how it reaches the outside world.

Pick a skill when the work is a repeatable procedure that belongs in the current task. The tells:

• You do the same thing often and want it done the same way every time — a report skeleton, a commit-message format, a QA checklist, a deploy runbook.
• The step needs the conversation's context to make sense — it builds on what you and Claude just discussed.
• It's short and runs on the same model. Spinning up a whole separate agent for a five-line procedure is pure overhead.
• You want progressive disclosure — the skill's details only load when the task actually matches, so it isn't bloating context the rest of the time.

My own blog pipeline is a skill for exactly this reason. It encodes the format, the SEO checklist, the image rules, the publish steps — the how — and it loads into whatever session is running that day. There's no reason to isolate any of that; I want it in the main context so it can react to what I'm writing. Skills also pair naturally with hooks that enforce guardrails — the skill says what to do, the hook makes sure it happened.

Pick a subagent when you need one of three things a skill can't give you: isolation, parallelism, or context protection.

• Isolation: The work has its own tools, permissions, or a system prompt you don't want leaking into the main agent — a locked-down reviewer, a research agent with web access the parent shouldn't have.
• Parallelism: You want several investigations running at once and merged. Read this subsystem, audit that diff, verify these claims — three subagents, three summaries, one reconciliation pass.
• Context protection: A broad search would dump thousands of tokens of file contents into your window. Send it to a subagent; it reads everything and hands back only the conclusion, keeping your main context lean.

On a real repo audit last month I fanned out four subagents — one per service — to answer “where does auth get validated?” Each read a dozen files it didn't need to keep, and I got four tight answers back instead of fifty files clogging one window. That's the whole pitch: the expensive reading happens in a context you throw away.Just don't overdo the fan-out — three to five is the sweet spot. Past that, merging and de-duplicating the summaries eats the time you saved.

Here's the part the “X vs Y” framing hides: the best setups use both, together. The skill is the how; the subagent is the where.

My go-to shape is a code review. I have a review skill that spells out what to check — correctness, security, dead code, test coverage — and exactly how to report each finding. Then I run it inside three subagents, one per slice of the diff, in parallel. Every subagent follows the same skill, so the output is consistent; they run isolated, so a huge diff never floods one context; and they finish roughly three times faster than one sequential pass. Consistent format and parallel throughput, from the same two primitives.

If you want to see this wired into an actual control-flow loop — spawning agents, gating on their results, retrying — I walked through a full build in dynamic workflows in Claude Code. And for the newer trick of letting a tool hand back an actual interface instead of text, there's MCP Apps. Different layer, same instinct: put each concern where it belongs.

• Using a subagent for a one-liner. If the task is short and needs the current context, you just paid a system-prompt-plus-summary tax for nothing. That's a skill, or just an inline step.
• Fanning out ten subagents. More isn't better past a point — you'll spend the afternoon reconciling ten overlapping summaries. Three to five, then merge.
• Putting a procedure in a subagent's prompt instead of a skill. If you're copy-pasting the same instructions into every delegated task, that's a skill screaming to be extracted.
• Forgetting the summary is all you get. A subagent's context vanishes when it finishes. If you need a detail later, the subagent has to return it — you can't go back and read its window.

• A skill = reusable instructions loaded into your current context; same model, no isolation. A subagent = a separate assistant in a fresh, isolated context window that returns only a summary.
• Skill changes how the current agent works. Subagent moves the work somewhere else.
• Use a skill for repeatable procedures, formats, and checklists that need the current context.
• Use a subagent for isolation, parallelism, or to keep a big read from flooding your context.
• Three to five parallel subagents is the sweet spot; beyond that, merging costs more than fanning out saves.
• The strongest pattern is both: a skill defines the how, a subagent provides the isolated, parallel where.

Straight from the source if you want the primitives in detail: Anthropic's docs on Claude Code subagents and Agent Skills are the canonical references.