Azure、AIシステム構築におけるスキルとサブエージェントの選択基準を公開

In a recent Azure Architecture blog article, Azure lead engineer Kishorekumar Pattabiraman outlines practical criteria for choosing between skills, sub-agents, and other approaches when building AI systems, emphasizing reusability, simplicity, and long-term maintainability.

According to Pattabiraman, teams often begin with the wrong question, focusing on which is the right model to use. The "first real fork" though, is not the model, but the architecture:

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.

A skill operates within an ongoing conversation: it can read files, ask questions, iterate with the user, and keep a human in the loop throughout the process. A sub-agent, by contrast, takes a single prompt, runs independently to completion, and delivers a final output. Both have their place, depending on the task, says Pattabiraman.

To decide whether to build a skill or a sub-agent, Pattabiraman highlights four key dimensions to consider: the iteration model, voice fidelity, human gate placement, and how frequently the task is repeated.

Among the four dimensions, frequency is the one leading to the clearest divide: a "one-off craft piece leans to a skill, a repeatable batch job to a sub-agent". The other factors require more careful consideration. For example, the choice is rarely between a fully interactive conversation and a simple handoff, so you need weigh the cost of having a human engaged in an iterative skill-based flow against the risk of forcing that same process into a one-shot response that might require to be corrected each time. For each dimension, Pattabiraman outlines the key trade-offs and common pitfalls to avoid.

The question of when to use a skill versus a sub-agent has also surfaced in discussions across Reddit and Hacker News. One commenter, enthusiast_bob, points out that sub-agents start always clean and not pollute the context window, whereas a skill always takes into account the whole conversation. Another user, dan-does-ai, emphasizes different trade-offs: a skill "is reusable across multiple agents or conversation flows", whereas "sub-agents make sense when: the step needs genuinely separate context, permissions, or a different knowledge source".

Another important consideration is the need for orchestration arising when using sub-agents. Beyond added complexity, one must also consider the non-determinism introduced by the orchestration layer. For example, Reddit commenter Ashlesha-msft notes that in Copilot Studio

the planner dynamically decides when to call skills, tools, topics, or sub-agents based on descriptions, context, and recent conversation history. Because of that, a skill might not be invoked on every similar prompt.

As a final perspective from the community, user Vlourenco69 suggests a simple mental model to "make sense of concepts like AI Agents, Sub-Agents, Skills, MCP", where an agent acts as a director, a sub-agent as a manager, a skill as a specialized worker, a tool as a dedicated machine, and MCP as the governance rules or policies of the organization.

Bringing the discussion full circle, Pattabiraman notes that in many cases the dichotomy skill vs. sub-agent is only apparent. In practice, the two models compose cleanly and a skill can be built on top of a sub-agent when the problem calls for it. In many cases, this layered approach represents the most mature design.

About the Author

Sergio De Simone

Sergio De Simone is a software engineer. Sergio has been working as a software engineer for over twenty five years across a range of different projects and companies, including such different work environments as Siemens, HP, and small startups. For the last 10+ years, his focus has been on development for mobile platforms and related technologies. He is currently working for BigML, Inc., where he leads iOS and macOS development.

Show moreShow less