Most teams building an AI capability start by choosing a model. The real fork comes first: is the work a skill or a sub-agent? This is a practitioner framework for telling the two apart, and for knowing when the answer is both, so the capabilities you build actually get reused.
Audience: Cloud architects, platform engineers, engineering leaders
The wrong first question
Most teams building AI capabilities start with the wrong question. They ask which model to use.
The model matters less than the shape of the capability around it. The first real fork is this. Are you building a skill or a sub-agent? Get that wrong and no model choice will save you. A skill and a sub-agent are two different delivery shapes, and each one fails at the other one's job.
The insight
The choice between a skill and a sub-agent is not about model power. It comes down to four checks. How the work iterates, whether the output carries a voice, how far an early wrong turn spreads, and how often it recurs. Score each, count which way they lean, and the shape falls out. An even split means build both, and let the skill drive the sub-agent.
The three sections below take the checks worth a pause. Frequency is the plain one: a one-off craft piece leans to a skill, a repeatable batch job to a sub-agent.
A skill lives inside the conversation. It reads files, asks a question, refines with the author, and keeps a human in the loop mid-flight. A sub-agent takes one prompt, runs to completion, and returns one report. Both are useful, for different work.
| Dimension | Skill | Sub-agent |
|---|---|---|
| Iteration | Conversation, many turns | One hand-off, one pass |
| Voice | Holds a style profile and applies it | Drifts toward generic by design |
| Human gate | Every turn | Once, at the end |
| Best for | Craft, subjective output | Bounded, structured output |
Table 1. The same three dimensions decide the shape every time.
1. Decide the iteration model first
Before anything else, architects should ask how the work actually happens. Is it a conversation or a hand-off? That single answer removes most of the ambiguity.
- Craft work needs back and forth
- Batch work needs one clean pass
- Conversations need memory of the thread
- Hand-offs need a bounded input and a clear output
A skill is right when the value comes from iteration. A blog post, a design review, a tricky refactor. A sub-agent is right when the work is well defined and the output is the deliverable.
In practice
The pattern that works: use a skill when the team expects three or four rounds of "close, but change this". The trade-off: a skill costs more attention per run because a human stays involved. The trap to avoid: forcing iterative craft into a one-shot agent and then editing the output by hand every time.
2. Voice fidelity decides craft work
Some outputs have a voice. An article, a customer email, an architecture narrative. Others do not. A query result, a data export, a status summary. The line between them is not cosmetic. It decides which shape survives review.
- Voice-heavy work favours a skill
- Voice-neutral work favours a sub-agent
- Skills can hold a style profile and apply it
- Sub-agents drift toward generic by design
When the output carries a name, fidelity is the whole game. A capable model with no voice anchor produces text that reads like it came from a committee.
In practice
The pattern that works: give a skill an explicit voice profile with banned phrases and cadence rules. Let it self-check before it shows anyone anything. The trade-off: the profile takes real effort to write once. The trap to avoid: expecting a stateless agent to match a personal style from a single prompt.
Implementation note
A voice profile is not documentation. It lives in the skill definition, an executable contract the skill checks itself against before a draft is ever shown. A small profile goes a long way.
# voice-profile (excerpt)
banned_phrases: [seamless, robust, game-changing, leverage the power]
forbid: [em-dash, semicolon, exclamation in body]
max_avg_sentence_words: 20
require:
- one "In practice" block per section
- a closing discussion question
self_check: run before any draft is shown to a human
3. Put the human gate where the risk is
Every AI capability needs a human review gate. The design question is where that gate sits. Placement is the difference between catching a problem early and unpicking it later.
- Skills gate continuously, turn by turn
- Sub-agents gate once, at the end
- Continuous gates catch drift early
- End gates are cheaper but riskier for craft
If a wrong turn early corrupts everything after it, the team wants a skill. If the work is bounded and a bad output is easy to spot and discard, an end gate is fine.
In practice
The pattern that works: match the gate to the blast radius. High blast radius and subjective quality point to a skill. Low blast radius and objective output point to a sub-agent. The trap to avoid: a one-shot agent doing forty minutes of unattended work that a human then has to unpick.
4. The pattern that scales is both
The mature answer is not one or the other. It is a skill on top of a sub-agent. The two shapes compose cleanly when each one keeps to its own job.
- The skill orchestrates and holds the voice
- The sub-agent executes bounded sub-tasks
- The human reviews at the skill layer
- Each layer does what it is good at
Figure 1. In the combined pattern the human reviews at the skill layer, and the sub-agent only touches the bounded task.
The skill runs the conversation and keeps quality. When it needs a bounded, repeatable job done, it delegates to a sub-agent. The result is iteration where craft lives and automation where the work is mechanical.
In practice
The pattern that works: a skill drafts and refines an article with the author, and calls a sub-agent to fetch and summarise reference material. The trade-off: two layers are more to build than one. The trap to avoid: collapsing both into a single agent and losing either the voice or the automation.
The operational trade-offs
Shape is not only a design choice. It shows up in cost, latency, and how you debug a bad run. Architects should price these in before committing to a pattern.
- A skill spends more tokens and more human minutes per run
- A sub-agent spends compute once and returns fast
- A skill fails in small, visible steps you can correct
- A sub-agent fails as one block you inspect after the fact
The cost of a skill is attention. Someone stays in the loop and that time is real. The cost of a sub-agent is rework. When a one-shot run goes wrong, the whole output is suspect and someone redoes it. Observability follows the same split. A skill leaves a turn-by-turn trail you can read. A sub-agent leaves one input and one output. You instrument the boundary and log the prompt and the result. Pick the shape whose failure mode your team can afford. The wrong shape does not announce itself. It shows up later as a cost line or a rewrite.
Two capabilities, one team
Consider a team standardising its engineering work with AI. Two capabilities land on the backlog in the same week. The first is recurring status queries. Well defined input, structured output, no voice. A stateless sub-agent fits. One prompt in, one report out, gate at the end. It works on day one and keeps working.
The second is authored technical content. Subjective, voice-heavy, many rounds of refinement. The reflex is to reuse the sub-agent that just shipped. That reflex is the mistake. The queries stay clean. The content reads flat and generic, and every draft needs a heavy human rewrite. Rebuilt as a skill with a voice profile and a turn-by-turn gate, the same work compounds instead of fighting back. Same team, same models, two different shapes of work, and only one right tool for each.
What teams get wrong
The common pattern is defaulting to whichever shape the team built first. A team ships one sub-agent, likes it, and forces every new problem into a sub-agent. Or it builds one skill and runs everything as a conversation, including batch work that should be automated.
It looks like consistency. It feels like reuse. But it leads to craft work that reads generic and batch work that needs babysitting. The fix is not a better model. It is naming the shape of the work before picking the tool.
The three shapes to watch for in your own stack:
- A voiced deliverable coming out of a one-shot agent, rewritten by hand every run. A skill wearing a sub-agent costume.
- A batch job run as a conversation and babysat turn by turn. A sub-agent wearing a skill costume.
- A large workflow forced into one agent that holds neither the voice nor the automation. Two shapes collapsed into one.
Name which one you are looking at, and the fix picks itself.
A quick way to decide
When a new capability lands on the backlog, run four checks before picking a tool.
- Iteration: conversation or one hand-off
- Output: subjective and voiced, or structured and neutral
- Blast radius: does an early wrong turn corrupt the rest
- Frequency: a one-off craft piece, or a repeatable batch job
Three or more answers leaning subjective and iterative point to a skill. Three or more leaning structured and repeatable point to a sub-agent. A split answer usually means a skill orchestrating a sub-agent underneath.
Figure 2. Score the four checks and count the leanings. Three or four one way pick the shape. An even split means a skill orchestrating a sub-agent.
Where to start depends on what you have already built
The framework is the destination. Where you start depends on what your team has shipped so far. Find your stage and take the one first move for it this week.
| Stage | First move, this week | Watch out for |
|---|---|---|
| Just starting, nothing built yet | Pick the single task you repeat most and write a one-paragraph capability brief for it, iteration, output, blast radius, and frequency, before you build. The brief names the shape, and the shape names the tool. | Building a general assistant before you have named one concrete job. |
| One capability, reused for everything | List every job you push through the one tool, find the one whose shape does not match, and rebuild just that one in the right shape. You do not need to replace what works. | Forcing new work into the tool you already have. |
| A small fleet, a handful of capabilities | Take your largest layered workflow and split it, a skill that holds the voice and the human gate on top, a sub-agent that does the bounded work underneath. | Capabilities that duplicate each other with no composition between them. |
Table 2. Same framework, different first move. What you have already built decides where the leverage is this week.
Your setup also shapes the answer. A solo builder should optimise for their own voice and iteration speed, where one strong skill beats three thin ones. A platform team should standardise the capability brief and a shared voice profile, so the fleet stays consistent as more people add to it, and a new capability inherits the house style instead of drifting from it.
Figure 3. Whatever you have built so far, the first move has the same shape. Name the work before the tool, then match the shape to the tool.
The shift
The shift is from "what can the model do" to "what shape is the work". Model capability is table stakes now. The advantage is in matching the capability to the work. Our own capability fleet is built this way, interactive skills and autonomous sub-agents in separate places with an orchestrator on top, and that split is what keeps it maintainable as it grows.
Iterative and voice-heavy points to a skill. Bounded and mechanical points to a sub-agent. Large and layered points to a skill orchestrating sub-agents. Decide that first, and the model becomes a detail the team can change later without rebuilding anything.
Most teams collapse both ideas into "automation" and end up with neither. The teams that separate them build capabilities they actually reuse.
Want to discuss? Drop a comment with patterns you have seen in your environment. I read every reply.
Microsoft