# OpenAI Agents SDK: Orchestrating multiple agents

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | cap-protocol |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | OpenAI Agents SDK: Orchestrating multiple agents |
| Source URL | https://openai.github.io/openai-agents-python/multi_agent/ |
| Source publisher / author | OpenAI |
| Source type | vendor docs |
| Source date (published) | Unknown — not stated |
| Date researched | 2026-10-25 |
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
| Research method | direct page fetch |
| Confidence | High |
| Status | Active |

## Summary

Short orchestration guide separating LLM-driven from code-driven orchestration and agents-as-tools from handoffs.

## Key findings

- LLM-driven orchestration lets the model plan and choose steps; code-driven orchestration puts application code in charge of which agents run in what order, making speed, cost and performance more predictable.
- Agents as tools: use when a specialist handles a limited subtask 'but should not take over the user-facing conversation'; the manager keeps control of the reply.
- Handoffs: use when 'routing itself is part of the workflow'; the specialist owns the rest of the turn.
- Best practices: invest in good prompts, monitor and iterate, let the agent introspect and improve, build specialists that each excel at one task, use evals.

## Pros / strengths

Names the decision rule (who owns the reply) in two lines.

## Cons / limitations / caveats

Vendor guidance; no data. Overlaps with Anthropic's orchestrator-workers description.

## Relevance to tai

tai's `@agent prompt` is a handoff-like human-chosen route; a model-callable `ask_agent` would be the agent-as-tool form. This page backs choosing the tool form when tai must stay in control of the answer.

## Changelog

| Date | Change |
|---|---|
| 2026-10-25 | Initial dossier created. |