Agent Skill vs Subagent: Procedure or Delegation?

An agent skill is a reusable procedure an agent can load to do a job more reliably. A subagent is a delegated worker or execution context that handles part of the job, often with its own instructions, tools, context window, and review boundary.

Use a skill when the failure mode is "the agent does not know the right method." Use a subagent when the failure mode is "one agent should not do all of this work in one context."

That distinction matters because both words now appear in real agent systems. OpenAI's Codex skills documentation describes skills as packages of instructions, resources, and optional scripts for reliable workflows. OpenAI's Codex subagents documentation describes delegated agents that Codex can spawn, route, wait on, and summarize. Anthropic's Claude Code SDK docs describe subagents as separate agent instances for context isolation, parallelization, specialization, and tool restrictions.

The practical rule is simple: skills preserve method; subagents distribute execution.

An agent skill improves how an agent performs a repeatable workflow. It tells the agent where to start, what to inspect, what evidence matters, what output shape to produce, and when to stop. If you want the fuller definition, start with What Is an Agent Skill?, but the short version is this: a skill is the reusable job design.

The open Agent Skills overview frames a skill as a folder with SKILL.md plus optional scripts, references, assets, and other resources. Anthropic's engineering writeup on equipping agents with skills makes the same point from a product angle: skills package procedural knowledge and organizational context so a general agent can act like it has been onboarded into a specific task.

A strong skill usually defines:

• the repeatable job in one sentence
• the trusted inputs or source hierarchy
• the workflow steps and decision points
• examples, templates, or scripts when needed
• completion evidence the user can inspect
• boundaries, escalation rules, and stop conditions

That makes skills portable. A code review skill, research brief skill, migration-guide skill, or customer-feedback triage skill can travel across runs and often across compatible agent clients. The agent changes; the procedure survives.

A subagent changes the execution structure. Instead of one agent doing everything inside one conversation, the main agent delegates a bounded part of the work to another worker. That worker may get a fresh context, narrower instructions, different tools, a different model, or a different permission policy.

This is why subagents show up in multi-agent frameworks. The OpenAI Agents SDK distinguishes between handoffs and agents-as-tools: use handoffs when a specialist should take over a branch of work, and use agents as tools when the manager should stay responsible for the final answer. LangChain's multi-agent documentation describes subagents as a pattern where the main agent coordinates specialized workers as tools, while handoffs transfer control more directly.

A subagent is useful for:

• parallel research across independent areas
• review with a fresh context
• specialized execution with different tools
• isolating risky or noisy exploration
• dividing a large task into work packets
• keeping the main conversation smaller and cleaner

The catch is that a subagent is not automatically better. It can be faster, more isolated, or more specialized, but it can also hallucinate, miss context, duplicate work, or produce a result the parent agent cannot safely integrate. Delegation only helps when the task packet is clear.

A code review skill defines the review method. It might tell the agent to inspect the diff, related tests, security-sensitive paths, database migrations, and user-facing behavior before writing findings. It can require file and line references, separate correctness issues from style suggestions, and report "no findings" clearly when there are no blocking defects.

That is procedure. One agent can use it. Ten agents can use it. A future agent can use the same skill after the review standard improves.

A subagent architecture changes who does the review. For example, a main agent might delegate one branch to a security reviewer, one to a test-coverage reviewer, and one to a product-behavior reviewer. Codex's subagent docs even use a similar review prompt pattern: spawn one agent per review concern, wait for all of them, then consolidate results.

The stronger architecture combines both ideas:

1. A parent agent owns the final review.
2. Each subagent receives a narrow review question.
3. Each subagent runs the same review skill or a lens-specific variant.
4. The parent integrates only findings with evidence.
5. The final answer names severity, file references, and test gaps.

Without the skill, the three reviewers may produce three incompatible opinions. Without the subagents, the review may be slower or may overload one context. The distinction is not academic; it changes the operating model.

Claude Code subagents are the most literal example for many developers. The SDK docs say each subagent runs in a fresh conversation and returns only its final message to the parent. That is useful when a research assistant needs to scan many files without filling the main thread, or when a database-migration reviewer needs detailed SQL guidance that would be noise in the parent prompt.

Codex subagents are similar in spirit but intentionally explicit. The docs say Codex only spawns subagents when you ask it to, and that subagent workflows consume more tokens because each worker performs its own model and tool work. That is an important tradeoff for teams: use subagents for meaningful parallel review, not for every small edit.

LangChain and LangGraph add the application-architecture version of the same choice. A LangChain personal-assistant tutorial uses a supervisor to coordinate a calendar agent and an email agent. The reason is not that "calendar" and "email" are magical roles. It is that each domain has different tools, formats, and approval risks. Splitting them makes the system easier to reason about.

CrewAI uses the language of agents, crews, flows, tasks, and processes. The CrewAI docs describe agents with tools, memory, knowledge, and structured outputs, plus tasks that can run through sequential, hierarchical, or hybrid processes. In that world, a skill is not the whole crew. A skill is closer to the repeatable operating procedure one agent or one task follows inside the crew.

AutoGen and Microsoft Agent Framework show the same evolution from another direction. Microsoft's AutoGen migration guide says AutoGen pioneered multi-agent orchestration concepts such as GroupChat and an event-driven runtime, while the newer Agent Framework leans toward typed, graph-based workflows. That is a reminder that "subagent" is not one product feature. It is a family of delegation patterns: group chat, supervisor-worker, handoff, router, graph, and manager-calls-specialist.

Use a skill without subagents when the task is repeatable but not meaningfully parallel. The most common mistake is reaching for a multi-agent setup when the real problem is simply an underspecified workflow.

A skill-only approach fits when:

• the task is narrow enough for one context
• the agent can inspect the relevant sources directly
• the work does not benefit from parallelism
• the biggest failure is inconsistent procedure
• the output needs one coherent narrative
• the cost of another agent would exceed the value of delegation

Examples include writing a release note, converting one transcript into an account brief, testing one skill before publication, migrating one document, or creating one technical enablement checklist. In those cases, the better investment is usually the skill: tighter inputs, clearer output format, better examples, and stronger completion evidence.

This also applies when teams are deciding between a skill and a broader agent configuration. The comparison in Agent Skill vs Custom Agent is useful here: if the runtime does not need to change, start with the portable workflow. Do not build a fleet of specialized workers just because one prompt is vague.

Use a subagent when the work naturally splits into independent branches, when the parent context is getting noisy, or when you need a second perspective before trusting the result.

Good subagent uses include:

• independent parts can run in parallel
• you want a second-pass review with fresh context
• the task has distinct expert lenses
• a risky exploration should be isolated
• the main agent should coordinate rather than execute every detail
• tool access should be narrower for one branch
• one branch needs a cheaper, faster, or stronger model than the parent

For example, an enablement team writing a migration guide could delegate API behavior, customer FAQ review, and code-example validation to separate subagents. The parent agent then uses one publishing skill to assemble the guide into a coherent article. The subagents provide coverage; the skill preserves the editorial standard.

Community usage points in the same direction. A Reddit thread on Claude subagents has users reporting that explicit subagent invocation helps with large review or investigation tasks, especially when the prompt names how many subagents should be used and what each should inspect. That is anecdotal, not benchmark evidence, but it matches the official guidance: subagents work best when the split is explicit.

The strongest pattern is not "skill or subagent." It is often "skill inside subagent, with the parent as integrator."

Imagine a research workflow for a technical article about agent architecture. A weak delegation prompt says: "Research this topic." A stronger delegation contract says:

1. One subagent reads official product docs for definitions.
2. One subagent reads framework docs for architecture examples.
3. One subagent reads community discussions for failure modes and practical objections.
4. Each subagent returns claims, source links, and caveats.
5. The parent agent writes the article using a publishing skill that enforces structure, internal links, external links, and examples.

That is much more reliable than either layer alone. The subagents reduce search breadth and context pressure. The skill keeps the final answer from becoming a pile of disconnected summaries.

This is also how Skillfully thinks about the category: skills are workflow assets that should be versioned, reused, and improved. If you are writing your own, How to Write an Agent Skill That Actually Works covers the procedure design side, and How to Test an Agent Skill Before You Publish It covers the validation side. Subagents can help with both, but they do not replace the skill's need for a clear job, evidence rules, and failure feedback.

Before spawning a subagent, define the contract as if you were writing a tiny skill:

1. The exact question it must answer.
2. The sources it may use.
3. The context it should ignore.
4. The tools it may or may not use.
5. The output format.
6. Evidence requirements.
7. What is out of scope.
8. Whether the parent should wait for all subagents.
9. How the result will be reviewed and merged.

The last two items are where many multi-agent workflows fail. If three subagents return long, overlapping essays, the parent now has another hard task: reconcile contradictions, remove duplicates, and decide what to trust. The better prompt asks for compact, comparable outputs, such as a table of claims with source links and confidence levels.

For code work, a useful contract might be: "Inspect only authentication files changed in this branch. Return blocking security findings with file references, reproduction steps, and any tests you ran. Do not comment on formatting or product copy." That is narrow enough to be useful.

For content work, the contract might be: "Find official documentation and credible community examples for subagent delegation. Return five source-backed points, each with one URL and one caveat. Do not draft the article." That prevents the research subagent from stepping into the editor's job.

Subagents create coordination cost. They can be faster wall-clock time while being more expensive in tokens, harder to supervise, and easier to over-trust. OpenAI's Codex docs call out the token cost directly. Claude's docs emphasize tool restrictions and what subagents inherit because permission boundaries matter. LangChain puts context engineering at the center of multi-agent design because the quality of the system depends on what each agent sees. A community benchmark post even reported higher cost without quality gain when parallel agent teams lacked a strong task contract.

Skills create maintenance cost. A skill that is too broad becomes a second system prompt. A skill that is too vague becomes a fancy prompt. A skill that is never tested becomes stale. The fix is not more prose; it is sharper scope, examples, scripts where useful, and feedback from real runs.

There is also a review asymmetry. A skill can be inspected before it runs. You can read SKILL.md, inspect references, and run evals. A subagent's behavior is partly visible only after execution. You need traces, summaries, output contracts, and parent-agent review to know whether delegation helped.

Skills and subagents solve different problems. A skill improves the method. A subagent changes the execution topology.

Use a skill when you want a repeatable procedure that travels across agents and runs. Use a subagent when the task should be split, isolated, parallelized, or reviewed by a separate context. Use both when the work is important enough that every delegated worker needs a clear method and every final result needs synthesis.

If you remember one sentence, make it this: subagents distribute labor; skills preserve standards.