Agent-as-Tool (Sub-Agent Invocation)
Expose specialised agents to other agents as tools, with the same typed-contract discipline as any other tool.
This page is the complete instruction page for one pattern called "Agent-as-Tool (Sub-Agent Invocation)." It explains the problem this pattern solves, the idea behind the solution, when you should (and should not) use it, and what happens afterward, both the good effects and the costs.
This matters because building AI agents is not just about making them clever. It is also about making them safe and predictable. Following a well-tested pattern like this one helps avoid common mistakes, and shows you exactly which safety rules and regulations it connects to, listed under "Standards Mesh" on this page.
Context
Some sub-problems are better solved by a specialist agent than by a tool. A specialist has its own reasoning, memory, and guardrails. Treating it as just another callable function composes naturally.
Problem
Hand-wired multi-agent systems entangle control flow and obscure responsibility.
Forces
- Specialist depth vs coordination cost
- Composability vs emergent complexity
Solution
Expose each specialist agent behind a tool interface: named, typed inputs/outputs, cost and latency metadata, capability description. The caller does not need to know whether the "tool" is a function or another agent. Standard observability captures the delegation.
Where this pattern acts in the two lifecycles
04 Act. Tool call, API invocation, environment mutation. 15 of 61 catalogue patterns act at this stage.
02 Build & Integrate. Model selection, tool wiring, memory design. 17 of 61 catalogue patterns act at this stage.
Stages and counts from the catalogue data. The Runtime lens is the loop the agent runs each turn; the AgentOps lens is the lifecycle the team runs the agent through. See the Matrix for every pattern at each stage.
Applicability
- Hierarchical multi-agent systems
- Supervisor/worker patterns
- Mixed human-agent organisations
Anti-Patterns
- Tight coupling to specific agent implementations
- Delegation without observability
Consequences
- +Composable specialisation
- +Substitutable implementations
- −Performance overhead of additional agent hops
- −Error propagation across agent boundaries
