Module · M5 · From one agent to a team
Build the specialists with agent-as-tool
Lesson 19 of 21 · 10 min
A specialist is an ordinary agent, attached to another agent as a tool. The manager calls it the way it would call a database read, and gets an answer back.
The team, wired
Three specialists hang off the manager's tool handle; each specialist's own tools hang off it in turn. Everything from the reviewer rightwards is module 4, unchanged.
Scroll for all 16 steps →
| Specialist | Its tools | Its one question |
|---|---|---|
| billing | the policy knowledge base, and the account read | what is this account entitled to? |
| impact | one pinned relational query | who else is affected by the same failure? |
| comms | none at all | what do we say to the customer? |
| manager | only the three specialists | which specialist should answer what, and how do their answers combine? |
billing
- Its tools
- the policy knowledge base, and the account read
- Its one question
- what is this account entitled to?
impact
- Its tools
- one pinned relational query
- Its one question
- who else is affected by the same failure?
comms
- Its tools
- none at all
- Its one question
- what do we say to the customer?
manager
- Its tools
- only the three specialists
- Its one question
- which specialist should answer what, and how do their answers combine?
Why the manager’s emptiness is a real boundary
Lesson 9 was clear that a pinned field is a default the model can push past. This is different, and it is worth understanding why. Tool adapters are built only for the nodes actually wired to an agent’s tool handle. A tool that is not attached does not exist in the agent’s world — there is no name for it, no schema for it, and nothing to override. The manager cannot issue a refund in the way that you cannot dial a phone you do not have.
Orchestration is not execution. The manager’s brief says it does not investigate, look anything up, or act — and the wiring makes that true rather than aspirational. It is the one place in this whole architecture where the instruction and the structure say the same thing.
Depth is capped as well: each specialist carries a maximum agent depth, so a specialist cannot recruit a specialist indefinitely. Set it to the depth your design actually needs and no more.
Briefs that keep a specialist narrow
- One question, stated in the first line. “You answer exactly one question: what is this account entitled to?” Everything else it might be asked, it declines.
- An explicit refusal of the neighbouring jobs. The billing specialist is told not to draft customer wording and not to decide who else to notify, because those belong to other specialists. Without that line, each one drifts into being a small version of the whole desk.
- A rule about evidence. The impact specialist is told the tool result is the only evidence it may cite, and that if the tool fails the answer is “unknown” — never “nobody else is affected”. Silence and absence are different findings.
- A statement of what it cannot do. The comms specialist is told it is drafting, that it holds no tools, and that it must not claim anything has been sent. In lesson 1 an agent claimed exactly that.
What a team does not fix
More agents means more surfaces on which a fact can be invented. On one run of this team the reviewer scored the assembled proposal 5 out of 5, with zero violations — and the proposal named a colleague and an email address that do not exist. The manager could not catch it, because it is instructed not to add or overrule facts. The reviewer could not catch it, because it only ever sees the proposal. Nothing in an org chart verifies anything.
There is also a practical consequence worth knowing before you go looking for a result: a specialist’s output is nested inside the manager’s tool calls rather than sitting at the top level of the run. A later node that refers to a specialist’s result by name gets nothing — quietly. That is precisely the defect lesson 17 dissected, and this build carried the same one until it was repaired.