Skip to content

15. From One Agent to Many ​

This manual focuses on the single-agent harness. Multi-agent systems are a separate topic, but one key pattern is worth recognizing.

Agent-as-Tool ​

A multi-agent system can be built by wrapping an agent so it can be called like a tool.

text
+-----------------------------+
| Orchestrator Agent          |
|                             |
|  Calls sub-agent tools      |
+-----------------------------+
       |           |           |
       v           v           v
+---------+   +---------+   +---------+
| Agent A |   | Agent B |   | Agent C |
| search  |   | analyze |   | draft   |
+---------+   +---------+   +---------+

From the orchestrator’s point of view, a sub-agent is an action that:

  • Receives a scoped task
  • Runs its own internal loop
  • Returns a structured result
  • Consumes time, tokens, and cost
  • May fail or require retry

This enables one-to-many fan-out: one orchestrator splits a task into parallel subtasks, hands them to specialized agents, and combines the results. In practice this is a common daily setup: an orchestrator assigns work to specialized runner or implementer agents and combines their results.

Why Use Agent-as-Tool? ​

BenefitDescription
Context isolationSub-agents keep intermediate work out of the orchestrator context
SpecializationEach sub-agent can have its own tools and prompts
ParallelismIndependent subtasks can run concurrently
ModularitySub-agents can be tested and replaced independently

Costs and Risks ​

RiskDescription
Compounding errorsA wrong sub-agent result can mislead the orchestrator (22)
Cost multiplicationEvery sub-agent adds model and tool calls
LatencyCoordinating and combining results add delay
Observability complexityTraces must span multiple agent runs
State consistencyShared state requires explicit synchronization

Design Rule ​

Adding agents brings compounding errors, multiplied cost, and coordination overhead. Use more than one agent only when you concretely need context isolation, specialized tool sets, or parallel execution. If a single agent with a clear boundary and a well-designed harness can handle the task, it is almost always the better choice.