OpenAI Symphony: turning issue-tracker work into isolated agent runs

The problem Symphony addresses: supervising agents versus managing work

Most coding-agent setups put a human in the loop at every step. Someone reads a ticket, opens a session, watches the agent, reviews the diff, and decides when the work is done. The agent is fast; the supervision is not. Symphony's README frames the shift as moving "from managing coding agents to managing work that needs to get done." That is the whole thesis.

The unit of work is an issue-tracker item, not a chat session. Symphony watches a board (the demo video shows Linear), picks up tasks, and runs each one as an isolated implementation run. The engineer's job becomes reviewing outcomes rather than steering a live session. The README describes the agents returning proof of work: CI status, PR review feedback, complexity analysis, and walkthrough videos. Acceptance happens at the PR level.

Who this is for: teams whose tickets already carry enough detail that an agent can act without a conversation. Symphony's requirements section says it "works best in codebases that have adopted harness engineering," linking to OpenAI's writing on that practice. If your tickets are one-line titles, Symphony has nothing to work with. The tool assumes the specification work is already done somewhere upstream.

How Symphony runs work: a tracker watcher, a workflow file, and isolated runs

The repository layout tells you most of the architecture. The top level holds SPEC.md, a docs/ directory, an elixir/ directory, and a .codex/ directory. SPEC.md is the normative document; the Elixir code is described as the experimental reference implementation of that spec. That split matters, because it means the project's real interface is the spec, not the Elixir module names.

The description states the service "turns issue-tracker work into isolated implementation runs and lets teams define project-specific automation through a workflow file." So there are three moving parts. A tracker integration supplies the queue of work. A workflow file, defined per project, says what should happen for that project. A run executor takes one task and produces an isolated implementation, which in the demo means a branch, a PR, and the evidence attached to it.

The isolation claim is the interesting one. Each task gets its own run rather than sharing a long-lived agent context, which is what keeps one task's half-finished reasoning from bleeding into the next. The README does not spell out the isolation boundary (container, worktree, or process), and SPEC.md is where that would be settled. Read it before assuming the boundary is stronger than it is.

The workflow file is the extension point. Project-specific automation lives there rather than in the service, which is why the same Symphony deployment can serve repositories with different review and landing rules.

Installing Symphony and getting a first run going

There are two documented paths, and they are very different in effort.

Option 1 is to have a coding agent build Symphony from the spec. The README gives the prompt verbatim, pointing at SPEC.md on the main branch. This is the path the project actually recommends for anyone who wants a non-Elixir implementation, and it is unusual: the spec is treated as the product.

Option 2 is the experimental Elixir reference implementation. The top-level README does not contain setup steps. It points at elixir/README.md for environment setup and running the service, and offers a prompt for delegating that setup to an agent:

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

Note what this means in practice. The top-level README gives you the repository URL, the license, and the two options, and nothing else operational. Ports, environment variables, tracker credentials and the workflow-file schema are not in it. They have to come from elixir/README.md and SPEC.md. If you are evaluating Symphony from the repository front page alone, you will not be able to judge whether it fits your environment.

Before running anything, read the warning: Symphony is described as "a low-key engineering preview for testing in trusted environments." Treat the first run as a lab exercise against a scratch repository and a board you do not mind an agent writing to.

Where Symphony is the wrong tool

The preview warning is the first limitation, and it is not boilerplate. A service that watches a board and lands PRs autonomously has write access to your tracker and your repository. The README scopes it to trusted environments, which implies the project does not consider the isolation boundary a security boundary against hostile input. If your issues can be filed by people outside your team, that is a different threat model than the one the README describes.

Second, the harness-engineering prerequisite is a real gate. Symphony assumes tickets are specified well enough for an agent to work without asking questions. Teams that use their tracker as a reminder list, with the detail living in someone's head, will get runs that produce plausible-looking diffs against the wrong requirement. The failure mode is not a crash; it is a confident PR that has to be rejected, which costs more review time than doing the task manually.

Third, the reference implementation is Elixir. If your team does not run Elixir services, you are choosing between operating a language you do not know and building your own implementation from SPEC.md. The README presents both as legitimate, but the second is a project, not an install.

Finally, the README does not document rollback. There is no described procedure for undoing a run that landed a bad PR, beyond normal git practice. That gap is worth resolving before the first autonomous landing.

Symphony versus a plain CI-plus-agent script

The obvious alternative is what most teams already have: a scheduled script or CI job that picks up labeled issues and invokes a coding agent, plus a human who reviews the result. The difference is where the judgement lives.

In the script approach, the logic is code in your CI configuration, and the evidence is whatever the job happens to print. Every team reinvents the review loop. Symphony moves that logic into a workflow file and standardizes the evidence: the README's demo describes CI status, PR review feedback, complexity analysis and walkthrough videos coming back with the run. That is a meaningful difference if your current setup produces a diff and nothing else.

The second difference is the run boundary. A CI-triggered agent typically runs in the CI runner's context, and consecutive tasks can share a workspace. Symphony's stated model is one isolated implementation run per task. If you have been bitten by an agent picking up stale state from a previous job, that is the specific thing Symphony claims to fix.

The trade-off runs the other way too. A CI script is something your team can debug with the tools it already has. Symphony adds a service, a workflow-file format and a spec to keep in sync with the implementation. For a team running five agent tasks a week, that overhead is not obviously worth it.

Maintenance, versioning and the Apache-2.0 licence

The repository is not archived. The last push was on 2026-07-24, which is the same timestamp as the v0.0.2 release. Before that, v0.0.1 landed on 2026-07-18. Two releases, six days apart, both at 0.0.x. That version numbering is honest about the state of the project, and it should set your expectations for API and workflow-file stability between upgrades.

Because the last push and the latest release share a timestamp, there is nothing in the repository history after that date. Plan for a project that may sit still for a while, and pin to a specific commit rather than tracking main if you deploy it.

Licensing is Apache-2.0, which is permissive and includes an explicit patent grant. That is the standard choice for infrastructure you might embed in a commercial product. Two practical notes, not legal advice: Apache-2.0 requires you to preserve the LICENSE and NOTICE files, and the repository ships a NOTICE file, so check what it attributes before redistributing. If you build your own implementation from SPEC.md, the spec is in the same repository under the same licence, which is the cleaner path for a commercial fork than copying the Elixir code.

Editorial conclusion

Symphony suits teams that already run coding agents against a real issue tracker and want the agent loop to own task pickup, proof collection and PR landing. It is the wrong tool for a repository where nobody has written down acceptance criteria, because the workflow file is where that judgement has to live. Before adopting it, read SPEC.md end to end and confirm which tracker states map to which run phases, since the README does not document that mapping. Also confirm the elixir/README.md setup steps against your own Elixir toolchain, because the top-level README defers all environment instructions to that file.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes