Reach for a subagent when the task feels big, and reach for a skill for everything else — that's roughly how most people decide, and it's the wrong axis. Size isn't the question. Isolation is.
What each one actually is
A skill is a procedure your agent loads into its current context — the same session, the same memory of everything that came before, the same conversation you're watching unfold. A subagent is a separate context doing work on its own and reporting back a conclusion. Same model, potentially, but a different working set.
That single difference — shared context vs. isolated context — is what should decide between them, not how hard or how long the task looks.
The test: does this task need to forget everything else?
Ask it plainly: would this task benefit from not seeing the rest of the conversation?
Use a skill when the work needs what's already in context. Debugging a failure you've been discussing for ten messages, reviewing a diff against decisions made earlier in the session, writing something that has to match a tone established three exchanges ago — all of these get worse in an isolated context, because the isolation throws away the exact information the task needs.
Use a subagent when the task would otherwise flood that context with noise you don't need. Searching two hundred files to answer "does this codebase already do X" produces a mountain of intermediate reads and greps. You don't want that mountain sitting in your main session afterward — you want the answer. Same with an adversarial second opinion: it's more useful uncontaminated by the reasoning it's supposed to be checking.
Where this goes wrong in practice
The common mistake isn't picking a subagent when a skill would do — it's reaching for a subagent first, by reflex, on anything that looks effortful. That loses the context that would have made the answer good. A subagent's output is a conclusion, stripped of the reasoning trail that produced it. If the next step needs that trail — "why did you conclude that" — you've already thrown it away.
The reverse mistake is rarer but costlier: running an extremely broad search inline, in your main session, because it felt simpler than delegating. Every file you read stays in context whether it mattered or not, and by message forty your agent is reasoning with a session full of dead weight.
They compose, they don't compete
The strong pattern isn't choosing one over the other — it's dispatching a subagent with a skill attached, so the isolated work is still following a hardened procedure instead of improvising. A subagent decides where work happens; a skill decides how it's done well once it gets there. Multi-stage pipelines usually want both: each stage isolated for context hygiene, each stage carrying its own procedure so a delegated step isn't a worse-supervised version of the main one.
If you're building a library of these procedures rather than writing them fresh in every session, Skill Forge ships 43 of them pre-hardened across five domains — useful mainly if you'd rather start from tested triggers and gates than debug your own from scratch.
Full answer: https://agentkitworks.com/answers/skill-vs-subagent
Top comments (0)