Symphony
Turns project work into isolated, autonomous implementation runs so teams manage work instead of supervising coding agents.
- Source repo
- openai/symphony
- Stars
- ★ 28k
- Last updated
- 1mo ago
- License
- Apache-2.0
- Primary language
- Elixir
- FA score
- 47/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Teams managing requirements in Linear who want board tasks automatically picked up and implemented by agents instead of a manual queue
- Not a fit if
- Teams needing production-grade reliability — it is a preview only
- Codebases that have not adopted harness engineering
- Teams wanting to avoid Codex and Linear vendor dependencies
- Source review
- 47/100 · Major gaps
What does this agent do, and when should you use it?
Symphony is an open-source (Apache-2.0) engineering system from OpenAI built around a simple shift: teams should manage the work that needs doing rather than supervise coding agents one by one. It monitors a task source (a Linear board in the demo), spawns isolated autonomous agent runs per task, and each run delivers proof of work — CI status, PR review feedback, complexity analysis, and walkthrough videos. Once a task is accepted by a human, the agent lands the PR safely. The repository offers two adoption paths: an open specification (SPEC.md) that anyone can implement in the programming language of their choice, and an experimental Elixir-based reference implementation with setup docs. The project is explicitly labeled a low-key engineering preview for testing in trusted environments.
Symphony watches a Linear board for work and spawns isolated agent runs (Codex-driven in the demo) to handle each task. Completed runs produce auditable proof of work — CI status, PR review feedback, complexity analysis, and walkthrough videos — and land PRs safely only after human acceptance. The repository ships SPEC.md describing how to implement Symphony yourself, and elixir/README.md with setup and run instructions for the Elixir reference implementation; you can also hand these instructions directly to a coding agent to perform the setup.
- Teams managing requirements in Linear who want board tasks automatically picked up and implemented by agents instead of a manual queue
- Engineering teams already practicing harness engineering that want to move from supervising coding agents to managing work at a higher level
- Platform or infrastructure teams willing to implement Symphony themselves from SPEC.md in a language of their choice for full control over the runtime boundary
- Elixir teams that want to try the reference implementation quickly using the steps in elixir/README.md
- Rigorous teams that require auditable proof of work (CI, review feedback, complexity analysis) before any agent-authored PR is merged
How do you install or deploy this agent?
The source does not document a single copy-paste install command; two paths are offered:
Option 1 (build your own): instruct any coding agent to implement Symphony from the spec:
> Implement Symphony according to the following spec:
> https://github.com/openai/symphony/blob/main/SPEC.mdOption 2 (Elixir reference implementation): clone the repository and follow the environment setup and run instructions at https://github.com/openai/symphony/blob/main/elixir/README.md, or delegate the setup to a coding agent:
> Set up Symphony for my repository based on
> https://github.com/openai/symphony/blob/main/elixir/README.mdMissing information: specific Elixir version requirements, dependency commands, and environment variables are not expanded in the source; consult elixir/README.md.
How do you use this agent?
Once set up, Symphony continuously monitors the configured work source (a Linear board in the demo). The flow: a task appears on the board → Symphony spawns an isolated agent run → the agent implements the task and opens a PR with proof of work (CI status, review feedback, complexity analysis, walkthrough video) → engineers review and accept or reject at a higher level → on acceptance the agent lands the PR safely. No per-agent supervision is required. Note: this is an engineering preview; the repository recommends testing only in trusted environments.
What are this agent's strengths and limitations?
- Open specification: SPEC.md lets teams implement Symphony in any programming language, avoiding lock-in to a particular runtime or stack
- Auditable output: agent runs must produce CI status, PR review feedback, complexity analysis, and walkthrough videos rather than just code
- Isolated tasks with safe landings: each task is an independent autonomous run, and PRs merge only after human acceptance, preserving a human gate
- A runnable Elixir reference implementation exists, and setup can be delegated to a coding agent, lowering the trial barrier
- Officially labeled a low-key engineering preview for trusted environments — not positioned for production-critical workflows yet
- Works best in codebases that have adopted harness engineering; repositories without that groundwork may need upfront infrastructure investment
- The core demo depends on external services (Codex, Linear), so adopters must evaluate vendor dependencies and their costs
- No benchmarks, failure-mode handling, or detailed security-boundary documentation in the source, leaving agent reliability without auditable evidence
How does this agent compare with similar options?
The README positions Symphony as the next step after OpenAI's harness engineering approach — moving from managing coding agents (directly supervising tools like Codex) to managing the work itself. It is the vehicle for that transition; no other named competitor products appear in the source.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Symphony This agent | 47 · Major gaps | CLIFree + model costs | ★ 28k | 1mo ago | Elixir | Codex |
| Helix Private Coding Fleet | 43 · Major gaps | Self-hosted serviceFreemium | ★ 823 | 1d ago | Go | Codex · Claude Code · OpenAI API · Claude API |
| Helmor Local Agent Workbench | 52 · Major gaps | Desktop appFree + model costs | ★ 1.3k | 3mo ago | TypeScript | Codex · Claude Code |
| Open SWE | 68 · Some gaps | Self-hosted serviceFree + model costs | ★ 11k | today | Python | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Core sources (SPEC.md, Elixir implementation) are absent from the evidence, so least privilege, user confirmation, rollback and similar mechanisms cannot be verified; workflows show SHA-pinned actions and least-privilege scopes (contents: read), justifying 1 rather than 0. License file is complete; source attribution earns full marks.
The implementation and spec are not provided; self-consistency, dependency availability and failure messages rest only on README assertions and a smoke test expecting exit code 1 with a preview notice — scored 1.
README explicitly scopes the audience (trusted environments, harness-engineering codebases) with a WARNING, earning 2 for boundaries; trigger precision and environment fit depend on elixir/README.md which was not provided — scored 1.
Repository layout is clear; license is complete (3); the release workflow enforces tag/version match and emits sha256 (2); there is no CHANGELOG or FAQ and install notes are only links to files not provided (1).
README clearly states the product's value proposition (managing work rather than supervising agents) — 2; output usability and cost/benefit lack reviewable implementation evidence — 1.
Key README claims (demo video, CI proofs, safe PR landing) cannot be traced in the static files — 1; honest framing as an engineering preview separates fact from inference well — 2.
- The spec and implementation source are absent from the evidence; safety mechanisms (permissions, confirmation, rollback) cannot be statically verified — do not deploy based on this review alone.
- README self-describes as a 'low-key engineering preview for trusted environments'; agents autonomously open and land PRs, so validate in isolated environments against controlled repositories.
- The test docker-compose mounts Codex auth files into containers; mind credential exposure if reusing that pattern.
- The reviewed file subset is incomplete; confidence is low — re-verify against the full repository before deciding.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Build of main at be10a1b79df723d6d7612b5651c8522704dafb2e. Built on pushes to main; may contain unreleased changes.View on GitHub ↗ -
Release notes excerpt
What's Changed * Add Symphony release skill by @frantic-openai in https://github.com/openai/symphony/pull/117 * Scrub GitHub and GitLab authentication token aliases by @frantic-openai in https://github.com/openai/symphony/pull/119 * Use Bearer authentication for GitLab API requests by @frantic-openai in https://github.com/openai/symphony/pull/124 * chore: release Symphony 0.0.3 by @frantic-openai in https://github.com/openai/symphony/pull/125 Full Changelog: https://github.com/openai/symphony/compare/v0.0.2...v0.0.3View on GitHub ↗ -
Release notes excerpt
What's Changed * Fix Burrito release tag verification by @frantic-openai in https://github.com/openai/symphony/pull/101 * Add generic tracker interface with Linear adapter by @frantic-openai in https://github.com/openai/symphony/pull/102 * Add GitHub Issues tracker adapter by @frantic-openai in https://github.com/openai/symphony/pull/103 * Add Jira Cloud tracker adapter by @frantic-openai in https://github.com/openai/symphony/pull/104 * Add Asana tracker adapter by @frantic-openai in https://github.com/openai/symphony/pull/105 …View on GitHub ↗