team of other agents and it becomes an orchestrator. Each member is exposed to the orchestrator’s model as a tool named ask_<name>, described by the member’s description. The orchestrator decides whom to ask, sends each a task, and composes the final answer from their replies.
Writing members
namebecomes the tool name (ask_weather_agent): keep it short and explicit.descriptionis how the orchestrator decides to delegate: write it like a job description, saying what the member knows and does.- A member can have its own tools, model, skills and even its own team.
What a member sees
Every handoff runs on a fresh clone of the member: same configuration, empty history. A member never sees the orchestrator’s conversation, so the task it receives must be self-contained, and two delegations in the same turn never share state. They run in parallel. The member’s answer comes back to the orchestrator as the tool result: itscontent, or its parsed object as JSON when it has a response_model.
Usage
The members’ spend (model calls, tool calls, compaction) is folded into the orchestrator’s run:response.usage includes it, response.delegation_usage isolates it, and orchestrator.total_usage and orchestrator.delegation_usage sum it over every run.
Limits
- A member that reaches its
max_turnsreturns a failure the orchestrator can act on. - A member cannot ask for a tool approval: the handoff fails with a message naming the tools that needed one. Use a sub-agent when delegated work must go through approvals.
Teams or sub-agents
For fixed pipelines where the order is known in advance, a flow is simpler than either.