Orchestra Mode
Orchestra Mode coordinates multiple specialist LLM agents to solve complex tasks collaboratively. A Chief agent delegates work to 8 expert roles, synthesizing parallel and sequential outputs into a coherent result.
Orchestra Mode requires external providers. Each role can use a different provider or model, enabling optimal quality/cost/latency trade-offs.
Chief + 8 Expert Roles
┌───────────────────┐
│ CHIEF AGENT │
│ Coordinates & │
│ synthesizes │
└────────┬──────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ Researcher │ │ Coder │ │ Analyst │
│ Web + RAG │ │ Code gen │ │ Data + SQL │
└───────────┘ └───────────┘ └───────────┘
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ Reviewer │ │ Writer │ │ Architect │
│ QA + lint │ │ Docs + UX │ │ Design + │
└───────────┘ └───────────┘ │ structure │
└───────────┘
┌───────────────────────┼───────────────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐
│ Debugger │ │ Planner │
│ Bug hunt │ │ Task break │
└───────────┘ │ down │
└───────────┘
| Role | Specialty | Default Provider |
|---|---|---|
| Chief | Task decomposition, result synthesis, quality gate | Claude 3.5 Sonnet |
| Researcher | Web search, document analysis, fact-checking | GPT-4o |
| Coder | Code generation, refactoring, testing | Claude 3.5 Sonnet |
| Reviewer | Code review, lint checking, security audit | GPT-4o |
| Writer | Documentation, UX copy, report generation | Claude 3.5 Sonnet |
| Analyst | Data analysis, SQL queries, statistics | GPT-4o |
| Architect | System design, API design, schema planning | Claude 3.5 Sonnet |
| Debugger | Bug investigation, stack trace analysis, root cause | GPT-4o |
| Planner | Task breakdown, dependency mapping, estimation | Claude 3.5 Sonnet |
Three-Phase Workflow
Phase 1: Plan
The Chief agent analyzes the user's request and produces an execution plan:
{
"phases": [
{
"id": "research",
"role": "researcher",
"task": "Find best practices for Go SQLite vector search",
"depends_on": [],
"parallel_group": "group_1"
},
{
"id": "analyze_code",
"role": "analyst",
"task": "Profile current search performance",
"depends_on": [],
"parallel_group": "group_1"
},
{
"id": "implement",
"role": "coder",
"task": "Implement optimized search based on research",
"depends_on": ["research", "analyze_code"],
"parallel_group": null
},
{
"id": "review",
"role": "reviewer",
"task": "Review implementation for correctness and performance",
"depends_on": ["implement"],
"parallel_group": null
}
]
}
Phase 2: Execute
Tasks are dispatched according to their dependency graph:
- Parallel execution: Independent tasks in the same
parallel_grouprun concurrently via goroutines - Sequential execution: Tasks with dependencies wait for their predecessors
- Progress streaming: Real-time SSE updates show which role is working on what
[████████░░] Researching... (Researcher)
[██████░░░░] Profiling code... (Analyst)
[░░░░░░░░░░] Waiting: research (Coder)
[░░░░░░░░░░] Waiting: implement (Reviewer)
Phase 3: Synthesize
The Chief agent collects all role outputs and produces a unified response:
- Quality gate: Each role output is validated against the task description
- Conflict resolution: Contradictory outputs are flagged for re-evaluation
- Merge: Outputs are combined into a single coherent response
- Final review: Chief performs a final quality check before streaming to the user
Progress Streaming
Orchestra progress is streamed to the UI in real time via SSE:
{"type": "plan", "tasks": 4, "parallel_groups": 2}
{"type": "task_start", "role": "researcher", "task_id": "research"}
{"type": "task_start", "role": "analyst", "task_id": "analyze_code"}
{"type": "task_progress", "task_id": "research", "pct": 45}
{"type": "task_complete", "task_id": "analyze_code"}
{"type": "task_start", "role": "coder", "task_id": "implement"}
{"type": "task_progress", "task_id": "research", "pct": 100}
{"type": "task_complete", "task_id": "research"}
{"type": "task_complete", "task_id": "implement"}
{"type": "synthesis_start"}
{"type": "final_response", "content": "Based on the research and analysis..."}
{"type": "done"}
Role Configuration
Each role can be configured independently:
orchestra:
roles:
coder:
provider: anthropic
model: claude-3.5-sonnet
temperature: 0.2
researcher:
provider: openai
model: gpt-4o
temperature: 0.7
reviewer:
provider: openai
model: gpt-4o-mini
temperature: 0.1
chief:
provider: anthropic
model: claude-3.5-sonnet
max_iterations: 3
Use cheaper models for routine roles (Reviewer, Planner) and reserve expensive models for quality-critical roles (Chief, Coder, Architect). This can reduce API costs by 40–60% without sacrificing output quality.
Slash Command
Invoke Orchestra Mode from any chat with the /orchestra command:
/orchestra Build a REST API for a todo app with Go and SQLite.
Include input validation, error handling, and tests.
Alternatively, describe your task and Memo will suggest when Orchestra Mode would be beneficial.
Performance Characteristics
| Orchestra Size | Parallel Tasks | Typical Duration |
|---|---|---|
| 2 roles | 2 parallel | 8–15s |
| 4 roles | 2 groups × 2 | 12–25s |
| 6 roles | 3 groups × 2 | 18–40s |
| 8 roles | 4 groups × 2 | 25–60s |
Duration depends on model latency, task complexity, and the dependency graph depth. Parallel tasks complete in the time of the slowest role in the group.
Orchestra + Agent Mode (v3.5.5)
Turning on Agent Mode and Orchestra Mode together is now a fully supported combination — each task Orchestra's chief delegates runs through the exact same real, sandboxed, permission-gated agent pipeline a direct agent chat uses, instead of a bare text completion. That means genuine run_command/file-edit/web-search tool calls inside an Orchestra task, with the same 60-second permission-request timeout and auto-deny behavior as any other agent call, and a chief synthesis that describes what actually happened rather than a plausible-sounding guess.
Known limitation: the live chat view can occasionally show a turn as already finished while an Orchestra task's tool-permission request is still resolving in the background — the backend itself handles this correctly (the real timeout still fires and the result is saved), it's a display-timing gap rather than a lost request.