maestro-orchestration

name	maestro-orchestration
model	opus
description	Conductor agent pattern that decomposes complex tasks, dispatches specialist sub-agents, manages dependencies, and synthesizes results into a unified deliverable. One specific orchestration pattern — a single conductor coordinating specialists. Use directly when that shape already fits; use `orchestration-pattern-selector` first if unsure, or `agent-dispatch-playbook` to plan a general parallel dispatch's mechanics. Use when: 'coordinate multiple specialist agents', 'orchestrate a complex multi-phase task', 'run a conductor pattern across agents', 'this task needs live agent coordination', 'decompose and dispatch to sub-agents'.
category	dispatch-coordinate
metadata	{"version":"1.1"}
inputs	[{"name":"objective","type":"string","description":"The complex task or objective that requires multi-agent coordination","required":true},{"name":"available_agents","type":"string[]","description":"List of specialist agent types available for dispatch (e.g., scout, architect, kraken, arbiter)","required":false}]
outputs	[{"name":"synthesis","type":"string","description":"Unified orchestration report with task decomposition, agent outputs, conflict resolutions, and integrated deliverables"}]

Maestro Orchestration

Purpose: Act as a conductor agent that decomposes complex objectives into subtasks, dispatches specialist sub-agents with appropriate isolation and model routing, manages inter-agent dependencies, resolves conflicts between agent outputs, and synthesizes results into a coherent deliverable.

---

0. Philosophy

Multi-agent orchestration fails in two ways: dispatching too early (before the task is decomposed) and dispatching too broadly (so many concurrent agents that integration overhead exceeds the parallelism benefit). The Maestro pattern exists because neither of those failure modes is obvious when you're inside a complex task.

The core insight is that the conductor's job is judgment, not execution. A conductor that starts implementing is a conductor that has lost the thread. Everything that requires a decision — decomposition, conflict resolution, synthesis — stays in the maestro context. Everything mechanical goes to a sub-agent.

This matters because complex tasks have emergent dependencies that aren't visible at the start. The maestro must hold the full picture while sub-agents hold only their slice. If that judgment is delegated, the integration phase discovers contradictions that no individual agent was positioned to prevent.

Second principle: synthesis is not summarization. After agents complete, the maestro integrates outputs into a single coherent deliverable — not a list of summaries. This requires reading all agent outputs, resolving contradictions, and producing something none of the agents could have produced individually.

---

I. When to Use

• A task requires multiple specialist capabilities (research + implementation + validation)
• Work has both independent tracks (parallelizable) and dependent phases (sequential)
• The objective is too complex for a single agent pass -- it needs decomposition and coordination
• You need live conflict resolution when parallel agents produce contradictory outputs
• Multi-repo or multi-package work where different agents own different scopes

---

II. Orchestration Patterns

Pattern A: Hierarchical (Default for Implementation)

Maestro
  +-- architect  (plan)
  +-- kraken     (implement)
  +-- arbiter    (validate)

Best when the task has a clear plan-build-verify shape.

Pattern B: Pipeline (Linear Dependency)

scout --> architect --> kraken --> arbiter --> herald

Best when each phase depends strictly on the prior phase's output.

Pattern C: Swarm (Parallel Research)

Maestro
  +-- scout   (internal codebase)
  +-- oracle  (external research)
  +-- scout   (pattern analysis)
  --> synthesize all results