Orchestration

An orchestrator coordinates multiple subagents to manage complex multi-step workflows.

After you configure an agent as an orchestrator by adding subagents, it becomes a coordination layer that plans tasks, delegates work to subagents, and integrates their outputs. The orchestrator does not execute tools directly. Instead, it focuses on strategy, task routing, and combining results.

Architecture

The orchestrator works as a supervisory layer that coordinates multiple agents. It does not call tools directly.

Instead, it manages the workflow by doing the following:

1. Interpreting the end user's goal.
2. Identifying which agents are required.
3. Delegating tasks to those agents.
4. Collecting and integrating their results.

Benefits

• Modular architecture: Agents are specialized and can be maintained independently.
• Scalable execution: Tasks can run in parallel.
• Robustness: Failures are isolated with retry/fallback mechanisms.
• Clear division of responsibilities: Orchestrator manages planning, agents manage execution.
• Extensibility: New agents or tools can be added easily.

Example orchestrator prompt

Workflow Example: Quarterly Sales Report
 
  1. Understand end user intent.
     - Identify that the request involves data extraction, analysis, visualization, and summary generation.
  2. Break down into subtasks:
     - Data Extraction → retrieve and prepare sales data
     - Analysis → compute key metrics (totals, growth rates, etc.)
     - Visualization → generate charts and graphs
     - Summary Generation → write a textual executive summary
  3. Delegate each subtask:
     - Assign to the most suitable AI agent based on its capabilities
     - Provide each agent with clear, structured instructions and required inputs
  4. Monitor and validate responses:
     - Check if each agent output meets the required format and quality
     - Retry or reassign if an agent fails or produces incomplete output
  5. Integrate results:
     - Combine data, charts, and summary text into a unified final report
  6. Deliver the final output to the end user in a clear and formatted structure
 
  Behavioral Guidelines:
  - Always focus on planning and coordination, not execution
  - Use consistent task naming and clear communication between agents
  - Ensure all outputs are validated before integration
  - Manage partial failures gracefully: retry or reroute when needed
  - Maintain transparency in the workflow (log which agent performed which subtask)
 
  Example End User Request:
  "Generate a Q2 sales performance report with visualizations and an executive summary."
 
  Expected Orchestrator Behavior:
  - Break down → Delegate → Monitor → Integrate → Deliver

For information about when to use orchestration, see Plan your agent.

To build components that subagents can use as tools, see Component design.

Subagent versioning

When an orchestrator agent references subagents, each subagent has its own independent version lifecycle. Publishing the orchestrator creates an immutable snapshot that pins the exact version of each subagent.

How it works

• A draft orchestrator can reference any version (draft or released) of a subagent.
• When you create a released version of the orchestrator:
  • Subagents that are still in draft are automatically published to a new released version and pinned into the orchestrator's release.
  • Subagents that are already released are pinned as-is. No unnecessary version bumps occur.
• If any subagents are still in draft, the system shows a confirmation dialog listing them before proceeding.
• A released orchestrator is not affected by any future changes to its subagents. The pinned versions remain frozen.

Runtime version resolution

When an orchestrator invokes a subagent at runtime, it uses the pinned version from its manifest, not whatever version of the subagent is currently active.

The active version of a subagent controls which version handles direct traffic to that subagent (for example, when a user interacts with the subagent standalone). It does not affect how parent agents resolve their dependencies.

Example: An orchestrator (V1) pins Refund Handler V2. Even if Refund Handler V3 is active, the orchestrator continues to use V2. To use V3, update the orchestrator's draft to reference V3, then create a new released version.

Rollback

Because each released version of the orchestrator is an immutable snapshot of pinned subagent versions, you can roll back the orchestrator to a previous version to instantly restore the previous subagent configuration. For more information, see Version history.