Multi-agent workflows are useful when specialists should own different parts of the job. The first design choice is deciding who owns the final user-facing answer at each branch of the workflow.
Choose the orchestration pattern
| Pattern | Use it when | What happens |
|---|---|---|
| Handoffs | A specialist should take over the conversation for that branch of the work | Control moves to the specialist agent |
| Agents as tools | A manager should stay in control and call specialists as bounded capabilities | The manager keeps ownership of the reply |
Use handoffs for delegated ownership
Handoffs are the clearest fit when a specialist should own the next response rather than merely helping behind the scenes.
Keep the routing surface legible:
- Give each specialist a narrow job.
- Keep short and concrete.
- Split only when the next branch truly needs different instructions, tools, or policy.
At the advanced end, handoffs can also carry structured metadata or filtered history. Those exact APIs stay in the SDK docs because the wiring differs by language.
Use agents as tools for manager-style workflows
Use when the main agent should stay responsible for the final answer and call specialists as helpers.
This is usually the better fit when:
- the manager should synthesize the final answer
- the specialist is doing a bounded task like summarization or classification
- you want one stable outer workflow with nested specialist calls instead of ownership transfer
Add specialists only when the contract changes
Start with one agent whenever you can. Add specialists only when they materially improve capability isolation, policy isolation, prompt clarity, or trace legibility.
Splitting too early creates more prompts, more traces, and more approval surfaces without necessarily making the workflow better.
Next steps
Once the ownership pattern is clear, continue with the guide that covers the adjacent runtime or state question.