Multi-Agent Orchestration: Handoffs and Agents as Tools
Choose agents as tools, handoffs, or parallel execution according to the task’s coordination needs. Define which agent retains control, what context each agent receives, and where application code enforces access boundaries. Limit shared history and tool outputs to authorized information. Distinguish agent handoffs from human escalation, and require an acknowledged route to a person when needed. Evaluate additional agents against a simpler workflow, measuring quality, latency, cost, and failure handling. Defend orchestration decisions with evidence and clear trade-offs.
We'll cover the following...
Northstar’s first multi-agent draft looked impressive in review: a triage agent, a dispatch specialist, and a handoff that “alerted a human” when dispatch needed help. When the interviewer asked who received that alert, there was no answer. The handoff had moved the conversation between two agents and notified nobody.
“Why did you add a second agent?” is a useful practice question for an FDE design discussion. Modularity alone does not demonstrate a benefit. Invoking another agent generally adds model work, coordination overhead, context-sharing risks, and failure paths. This lesson compares three patterns supported by the OpenAI Agents SDK: calling a specialist as a tool, handing the conversation to a specialist, and running independent agents in parallel from application code. Choose among them using evidence about quality, latency, cost, and ownership. One agent or ordinary code may be sufficient.
The running example is Northstar’s NS-318. A single status read already works through the read-only tool from earlier lessons. Northstar now also wants a draft update that combines dispatch evidence with a separate handling rule, and that request is where the patterns start to differ.
When should a specialist be called as a tool?
In the manager pattern, one agent keeps control of the conversation and delegates a bounded task to a specialist through Agent.as_tool(), then folds the result into its own response. By default the specialist tool takes one string field, input; pass parameters (a Pydantic model or dataclass) when it needs structured arguments. The nested run doesn’t inherit the manager’s conversation, so the specialist sees only what the manager sends, and its final output comes back as the tool result, which a custom_output_extractor can reshape.
Use this pattern when a specialist should help with a subtask but shouldn’t talk to the user. For the NS-318 draft, the application supplies two inputs: the entitled dispatch record (a replacement-pump window of 08:00–12:00 UTC on October 29, sourced from dispatch/NS-318/v3) and the handling rule policy/dispatch-followup/v1, which requires a draft for operator review and forbids sending messages or modifying tickets. The guarded NS-209 callback workflow stays unchanged.
The manager calls the dispatch specialist with a narrow interpretation task. The specialist returns the ticket, window, and ...