Symphony

Symphony is Ambient Desktop's orchestration system for work that benefits from more than one role, context window, runtime, or review posture. The model: one parent session owns the work, typed child agents receive scoped slices of it, and an artifact-driven join brings everything back.

What Symphony is for#

Symphony is not a generic swarm button. A parent session owns the objective, budget, approval posture, and final synthesis, while children receive scoped work and return artifacts. Use it when a single agent would either carry too much context, mix incompatible responsibilities, or review its own work without enough independence.

Child agent types#

Each child has a defined role and a defined boundary on what it must not decide:

1. A research child collects source evidence: links, screenshots, logs, and structured notes. It returns citations and uncertainty, not final product decisions.
2. An implementation child works on a bounded slice with an explicit file or command scope, returning artifacts, changed files, and validation output.
3. A review child checks the parent or an implementation child against acceptance criteria, tests, security constraints, and user intent, identifying gaps and assessing proof quality.
4. A local-model child uses local runtimes for privacy-sensitive, low-cost, visual, or repetitive work where a local model is the right fit.
5. A workflow child executes a confirmed workflow artifact with known parameters, prerequisites, and expected outputs.

Orchestration patterns#

1. Fan-out research. The parent splits a broad question into research children with different source scopes; children return evidence bundles, and the parent joins them into a ranked synthesis with conflicts called out.
2. Plan decomposition to Project Board. The parent turns an objective into card candidates, then uses children for selected implementation or validation work. The Draft Inbox remains your review point before execution expands.
3. Implementation plus independent review. One child implements a bounded change while another reviews tests, edge cases, and proof; the join step compares their artifacts before the parent presents a final answer.
4. Local/cloud model split. The parent routes private, cheap, or specialized subtasks to local models while reserving harder synthesis or network-native tasks for Ambient or another selected provider.
5. Callable workflow orchestration. A reviewed workflow runs as a child-like executable unit: the parent supplies parameters and joins the workflow's artifact back into the larger task.

The control surface#

• Role policy: what each child is responsible for and what it must not decide.
• Tool grants: which tools, files, providers, browser surfaces, or local runtimes each child may use.
• Context boundary: what the child receives up front and what it can discover later.
• Budget and stop conditions: token, time, retry, and approval limits for each child.
• Mailbox and artifact join: how summaries, conflicts, metrics, board cards, and final proof return to the parent.

A worked example#

A parent receives: "Add keyboard shortcuts to the calculator and prove they work." It creates three children (a research child to inspect the existing UI and shortcut conventions, an implementation child to edit the calculator, and a review child to run or inspect validation), then joins their artifacts into a final answer with changed files, proof, and remaining risks.

Keep going#

• Durable goals: the persistence engine a Symphony run hangs off
• Project Board: where decomposed work becomes reviewable cards
• Workflow Recorder: packaging an approved recipe as a callable unit