Agent-as-Tool Embedding
Wrap a sub-agent (with its own loop, prompt, and tool palette) behind a single function-shaped tool signature, so the parent agent calls it like any other tool and never sees the sub-agent's internal turns.
Problem
If the parent watches every turn the sub-agent takes, the parent's context window fills up with intermediate searches and tool calls that have nothing to do with the parent's own job, and the parent's reasoning starts to entangle with the sub-agent's internals. Building a full multi-agent broadcast bus to coordinate the two is far more machinery than the situation needs. Without a clean boundary, the team ends up choosing between bloated parent context and over-engineered coordination.
Solution
Define the sub-agent as `def sub_agent(task: str, ...) -> Result`. The parent calls it like any other tool. Inside the function: a fresh agent loop with its own model, tool palette, and step budget runs to completion or failure, returning a structured result. Parent context records only the call and the return value. Step budget and timeout are enforced by the wrapper, not by the sub-agent's prompt.
When to use
- A sub-task is well-scoped enough that the parent should see only its result, not its turns.
- Putting the sub-agent's intermediate state into parent context would bloat tokens or couple parent reasoning to sub-agent internals.
- The sub-agent has its own model, tool palette, or step budget that should not leak into the parent loop.
Open the full interactive page →
Diagram, neighbourhood map, code examples, related patterns and full provenance.