Symphony

Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents.

In this demo video, Symphony monitors a Linear board for work and spawns agents to handle the tasks. The agents complete the tasks and provide proof of work: CI status, PR review feedback, complexity analysis, and walkthrough videos. When accepted, the agents land the PR safely. Engineers do not need to supervise Codex; they can manage the work at a higher level.

Warning

Symphony is a low-key engineering preview for testing in trusted environments.

Dashboard

The dashboard shows each Linear team's factory as a live flow diagram you can steer, and, with all teams picked, everything Symphony is working on by Linear state. Flows themselves are designed from your coding agent over MCP. Click a stage to pause it, cap its agents, choose its harness and thinking level, or move issues along its connections. People sign in with Symphony accounts tied to their Linear identity. The dashboard also shows what needs a human, what each agent is doing, and what it all costs by project, team, task, and harness.

See elixir/README.md for details.

Architecture

docs/architecture.md explains how Symphony is built and how an issue moves through it: components, run lifecycle, durability, launchers, security, observability and scaling. docs/ indexes the rest of the documentation.

Current capabilities

The experimental Elixir implementation currently supports:

• Codex, Claude Code, and OpenCode as unattended agent backends.
• Multi-project routing from one Symphony instance across multiple repos.
• One symphony.yml runtime config with Symphony's own agent prompt; repos need no Symphony files (a repo-local WORKFLOW.md is optional).
• Linear label-based backend switching with labels like codex, claude, and opencode.
• Linear label-based thinking/effort switching with labels like thinking/high and thinking/max.
• Works with Linear's default states: sub-stages (implement, rework, merge, blocked) are factory/* labels, so no custom workflow states are needed.
• Isolated per-issue git clones, with optional per-issue Docker sandboxes (sandbox.kind: docker).
• A live dashboard that shows and steers the factory, with cost tracking by project, team, task, and harness.
• Per-issue agent transcripts (messages, commands, edits, thinking), and messages to the agent working on an issue, delivered into a running Codex turn or at the start of the next turn.
• An MCP endpoint (/mcp) so your own agents can watch the factory and edit flows (the only place flows are edited), move issues, and message agents with per-person, scoped, expiring tokens. It's safe to expose without a sign-in proxy.

If you want to try those features, start with elixir/README.md, which now documents backend support, multi-project setup, and label-routing behavior in detail.

Running Symphony

Requirements

Symphony works best in codebases that have adopted harness engineering. Symphony is the next step -- moving from managing coding agents to managing work that needs to get done.

Option 1. Make your own

Tell your favorite coding agent to build Symphony in a programming language of your choice:

Implement Symphony according to the following spec: https://github.com/openai/symphony/blob/main/SPEC.md

Option 2. Use our experimental reference implementation

Check out elixir/README.md for instructions on how to set up your environment and run the Elixir-based Symphony implementation. It includes setup guidance for OpenCode, Claude Code, multi-project routing, and Linear label-based backend and effort switching. You can also ask your favorite coding agent to help with the setup:

Set up Symphony for my repository based on https://github.com/openai/symphony/blob/main/elixir/README.md

---

License

This project is licensed under the Apache License 2.0.