using ambient / symphony

Symphony Sub-Agent Orchestration

Symphony coordinates parent and child agents with scoped tools, role policy, artifacts, and join logic.

In Development
Symphony Orchestration Topology Parent sessions coordinate scoped child agents through role policy, artifacts, and explicit joins. Symphony Orchestration Topology Parent sessions coordinate scoped child agents through role policy, artifacts, and explicit joins. Parent session objective, budget, approvals Research child searchcitationssource notes Implementation child file editscommandsartifacts Review child testsproofrisks Local-model child private datacheap loopsvision Artifact-driven join: summaries, conflicts, metrics, board cards, and final proof. Callable workflows can package approved orchestration recipes.
Parent sessions coordinate scoped child agents through role policy, artifacts, and explicit joins.
Product screenshots

Planner

Planner mode grounds long-running work in reviewable steps.

Ambient Desktop planning surface.

What Symphony is for

Symphony is Ambient's orchestration system for work that benefits from more than one role, context window, runtime, or review posture. It 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 Symphony when a single agent would either carry too much context, mix incompatible responsibilities, or review its own work without enough independence.

Child agent types

Research child

Collects source evidence, links, screenshots, logs, and structured notes. It should return citations and uncertainty, not final product decisions.

Implementation child

Works on a bounded implementation slice with explicit file or command scope. It returns artifacts, changed files, and validation output.

Review child

Checks the parent or implementation child against acceptance criteria, tests, security constraints, and user intent. It should identify gaps and proof quality.

Local-model child

Uses local runtimes for privacy-sensitive, low-cost, visual, or repetitive work where a local model is the right fit.

Workflow child

Executes a confirmed workflow artifact or reusable recipe with known parameters, prerequisites, and expected outputs.

Core 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 child agents for selected implementation or validation lanes. Draft Inbox remains the user 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 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 can become a child-like executable unit. The parent supplies parameters and joins the workflow artifact back into the larger task.

Controls developers should understand

  • 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.

Example: feature implementation with review

A parent receives: Add keyboard shortcuts to the calculator and prove they work. The parent 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. The parent joins artifacts into a final answer with changed files, proof, and remaining risks.

Maturity note

Symphony is in development. The contracts, recipes, tests, scoped child launches, and UI concepts exist, but documentation should present advanced orchestration as guided patterns with explicit limits rather than as fully open-ended autonomous delegation.