Give an agent a 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

  • name becomes the tool name (ask_weather_agent): keep it short and explicit.
  • description is 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: its content, 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_turns returns 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.