Choose the lowest rung that can reliably complete the work. Use a tool for deterministic actions, a skill for reusable procedures, and a sub-agent only when the task needs independent reasoning, separate context, or ambiguity handling that the parent should not manage directly. The higher the rung, the more governance and traceability you need.
Choosing the Lowest-Risk Abstraction for the Job
A good decision starts with the work itself, not with the mechanism you happen to prefer. If the task is deterministic, repeatable, and can be executed safely from clear inputs, a tool is usually enough. If the work follows a reusable procedure with judgment at the edges, a skill is the better fit. If the task needs independent reasoning or separate context management, only then should you escalate to a sub-agent.
The practical value of this ladder is that it prevents over-engineering. Teams often reach for a sub-agent because it feels flexible, but that also expands the surface area for mistakes, hidden assumptions, and control drift. A smaller abstraction is easier to test, easier to govern, and easier to explain when something goes wrong.
For teams building AI workflows, this also helps keep autonomy proportional to actual need. A tool can be invoked with tightly bounded inputs and outputs. A skill can package a procedure without handing over open-ended judgment. A sub-agent should be treated as a separate actor in the workflow, not just a more powerful helper.
What Each Rung Is Best At
A tool is best when the operation is narrow and objective, such as formatting data, querying a system, or running a fixed transformation. The key test is whether success can be defined up front without much interpretation. If the answer is yes, adding reasoning layers usually increases latency and failure modes without improving outcomes.
A skill is best when teams want a reusable sequence that still stays inside a controlled procedure. Skills work well when the steps are known, but the work benefits from packaging, consistency, and reuse across many calls. They are especially useful when you want the parent to retain oversight while avoiding repeated prompt engineering or ad hoc orchestration.
A sub-agent is best when the task cannot be safely reduced to a script or a procedure. That includes cases where the work has branching logic, ambiguous evidence, multi-step investigation, or the need to hold a separate context window. The important point is that the sub-agent should earn its independence by reducing complexity for the parent, not by being the default option.
When the Choice Becomes a Governance Decision
The higher you move up the ladder, the more you need to think about traceability, authorization, and review. That is why teams should treat the jump from tool to skill to sub-agent as an increase in governance burden, not just capability. This matters most when actions can change data, call external systems, or trigger downstream work that the parent cannot easily reverse.
It also changes failure analysis. A tool failure is usually a bounded execution problem. A skill failure is often a process design problem. A sub-agent failure can become an attribution, containment, or policy problem because the parent may not fully see every intermediate decision it made. That makes logging, explicit handoff points, and clear ownership more important as autonomy increases.
In practice, AI Agent Authorisation Guide is a useful companion when the choice affects what an autonomous component may do, while AI Agent Observability, Audit and Incident Response Guide helps teams decide whether the workflow remains attributable after escalation. For a broader view of autonomy and identity change, AI Agents vs Agentic AI is a strong reference point.
Risk and Threat Considerations
Choosing too much autonomy too early can create unnecessary exposure. The main risk is not that sub-agents exist, but that teams assign them work that should have remained deterministic or procedure-bound, which can widen the blast radius of a bad input, a bad prompt, or a bad decision.
Failure mechanism: Over-escalation from tool to skill to sub-agent allows ambiguous tasks to accumulate hidden state, weaker supervision, and broader action authority, making it easier for errors to propagate across systems or workflows.
Impact: Teams can lose traceability, increase unauthorized or unintended actions, and make containment harder when a workflow behaves unexpectedly. The greater the autonomy, the more important it becomes to constrain scope, log actions, and define explicit stop conditions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Choosing sub-agents changes delegated authority and privilege boundaries. |
| ASI02 — Tool Misuse | The tool-vs-skill-vs-agent choice centers on bounded tool use versus broader autonomy. | |
| ASI10 — Rogue Agents | Sub-agents introduce containment and oversight concerns if they act beyond intent. | |
| Recommendation — Limit each sub-agent to the minimum action scope needed for its task. Keep deterministic work in tools and block open-ended tool chaining by default. Require explicit ownership, monitoring, and shutdown paths for any sub-agent. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Rung selection should minimize authority as complexity rises. |
| AU-2 — Event Logging | Higher-autonomy choices need stronger traceability and review evidence. | |
| Recommendation — Grant each component only the access needed for the chosen abstraction. Log tool calls, skill steps, and sub-agent actions at a level suitable for audit. | ||
Practitioner Guidance
What to prioritise: Start by classifying the task by determinism, reuse, and judgment. If the same result should follow from the same input every time, keep it at tool level unless there is a strong operational reason not to.
Decision rule: If the parent can safely manage the work end to end, do not introduce a sub-agent just to save prompt length or orchestration effort. Escalate only when separate context, independent reasoning, or deliberate ambiguity handling materially improves the outcome.
What to verify: Before approving a sub-agent, confirm that you can describe its allowed inputs, outputs, stop conditions, and audit trail in one sentence each. If you cannot, the design is probably too open-ended for the task.
Practitioner takeaway: The right abstraction is the smallest one that still completes the job reliably, because every increase in autonomy should buy real capability, not just convenience.
Related resources from NHI Mgmt Group
- How should enterprise teams decide between agent-to-tool governance and application-to-model routing in AI platforms?
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- How should teams think about AI agent privileges?