Symphony: An Elixir Orchestration Layer That Turns Issue Trackers Into Autonomous Coding Runs

What Symphony Actually Does

Symphony is a service that connects an issue tracker to coding agents. The README describes it as turning project work into isolated, autonomous implementation runs. Instead of an engineer opening a ticket, assigning it to Codex, then reviewing the diff line by line, Symphony watches the board, picks up new work, and dispatches an agent to handle it. The agent does not just write code. It has to produce proof of work before anything is merged. That proof includes CI status, PR review feedback, complexity analysis, and walkthrough videos. Only when the agent's output is accepted does Symphony land the PR. The target user is a team that wants to manage work at a higher level, not supervise a coding agent. The README frames this as the natural next step after adopting harness engineering, which is OpenAI's term for giving agents structured environments and checkpoints. The demo video shows the flow on a Linear board, and Linear is the tracker named in the material. Nothing in the README suggests support for GitHub Issues, Jira, or any other tracker.

The Mechanism: Watch, Spawn, Verify, Land

The core loop is visible in the demo and the README. Symphony monitors a Linear board for new work. When it finds a task, it spawns a coding agent, presumably Codex, to implement it. The agent works in an isolated run, which means it does not touch the main branch directly. After the agent finishes, it submits evidence: a PR with CI status, review feedback, a complexity analysis, and a walkthrough video. Symphony then presents that evidence for acceptance. If accepted, Symphony lands the PR. The key design choice is that the agent's work is not trusted on its own. It must pass external checks before merge. This is a gate that separates Symphony from a simple script that runs an agent and merges whatever comes out. The isolation also means each task runs in its own environment, so a failed agent run does not contaminate the next one. The README does not specify how the agent is invoked, what language model it uses, or how the acceptance decision is made. It could be a human clicking approve, or it could be an automated rule. The material does not say. What is clear is that the workflow is event-driven: new issue, spawn, verify, merge. That is the entire mechanism, and it is deliberately thin.

Two Ways to Get It Running

The README offers two options. The first is to tell your favorite coding agent to build Symphony from a specification file. The spec lives at https://github.com/openai/symphony/blob/main/SPEC.md. You paste that URL into a coding agent and ask it to implement the service in any language you prefer. This is an unusual distribution method. There is no packaged binary, no Docker image, and no install script in the README. The second option is to use the experimental reference implementation written in Elixir. The instructions are in elixir/README.md, which is not reproduced in the material you gave me. The README suggests you can also ask a coding agent to set it up for you, using the same URL. The project's primary language is Elixir, and the latest release is v0.0.2, pushed on 2026-07-24. That is two days after v0.0.1. The version numbers are below 1.0, which matches the 'engineering preview' warning. If you want to run it today, you need to clone the repository, read elixir/README.md, and follow whatever setup steps are there. The material does not give you a single command to run.

The Warning That Should Shape Your Decision

The README carries a warning block that says Symphony is a low-key engineering preview for testing in trusted environments. That is the single most important fact in the entire document. It means the project is not intended for production use, not hardened, and not safe to run against a public or hostile repository. The phrase 'trusted environments' implies you should only run it where you control the codebase, the CI, and the agent's access. If you point Symphony at a repo with weak test coverage, or at a CI that does not produce a clear pass/fail signal, the agent's proof of work becomes meaningless. A walkthrough video is not a substitute for a test suite. The warning also suggests that the maintainers expect failures. They are not promising reliability. They are asking you to be careful. That is a refreshingly honest position, but it also means you should not treat this as a stable tool. The version history supports that: two releases in six days, both at 0.0.x. The project is in active, early flux.

Limitations and Failure Modes

The biggest limitation is that Symphony only works with Linear. The README names Linear explicitly in the demo description, and no other tracker is mentioned. If your team uses GitHub Issues, Jira, or anything else, you cannot use Symphony as-is. You would need to modify the Elixir implementation or build your own from the spec. The second limitation is the acceptance step. The README does not explain how acceptance is determined. If a human has to review every PR, then Symphony does not actually remove supervision; it just moves it from the coding phase to the review phase. The value then is that engineers review finished work instead of watching the agent work, which is a real shift, but not full autonomy. If acceptance is automated, the README does not say what criteria are used. That gap is a risk. A third failure mode is the proof-of-work requirement itself. If CI is flaky, or if the agent can game the checks, then the gate is weak. The material does not describe any mechanism for validating the walkthrough video or the complexity analysis. Those are qualitative artifacts. A team could end up with a PR that passes CI but implements the wrong thing, and Symphony would land it. The project is a framework, not a safety net.

The Alternative: Direct Agent Supervision or a Custom Orchestrator

The obvious alternative is the workflow Symphony replaces: an engineer runs Codex locally, reviews the diff, and merges manually. That approach has no orchestration layer, no automatic spawning from the issue tracker, and no proof-of-work gate. It puts the human in the loop for every step, which is slower but gives full control. The second alternative is to build your own orchestrator using the SPEC.md file. That is actually the README's first recommendation. The spec is the real product here; the Elixir implementation is just one reference. If you have specific requirements, such as support for a different tracker, or a custom acceptance rule, you can implement the spec in a language your team already knows. That is a fundamentally different approach from adopting the Elixir code. You are not running a vendor's software; you are implementing a protocol. The trade-off is that you carry the maintenance burden. The Elixir implementation is experimental, so you might find it easier to write your own than to debug theirs. The choice is between using a thin, untested reference and building from a spec that OpenAI itself treats as the source of truth.

Maintenance, Licensing, and Upgrade Cost

The project is licensed under Apache-2.0, which means you can use, modify, and distribute it freely, as long as you preserve the license notice. That is a permissive license, so there is no legal barrier to forking. The maintenance cost is harder to pin down. The repository has only two releases, both in July 2026, and the last push was on 2026-07-24. The project is not archived, so OpenAI is still working on it. But the README explicitly calls it an engineering preview, which means the API, the workflow file format, and the Elixir code can change without notice. The spec at SPEC.md is the only stable reference, and even that could change. If you build on the Elixir implementation, you should expect to track upstream changes closely. If you implement the spec yourself, you avoid that churn but you own the code. There is no mention of a migration path between versions, no changelog, and no upgrade guide in the material. The upgrade cost is therefore unknown. For a project this young, the safest assumption is that every update is a breaking change. You should also note that the README says Symphony works best in codebases that have adopted harness engineering. That is a precondition, not a nice-to-have. If your codebase lacks agent-friendly harnesses, Symphony will not fix that; it will amplify the weakness.

Editorial conclusion

Adopt Symphony if you run a trusted, well-tested codebase and want to experiment with letting coding agents work without per-task supervision. Do not adopt it for production or for repositories that lack strong CI and review practices, because the preview is explicitly for trusted environments. Before you start, verify that your issue tracker is Linear, that your CI can produce a reliable status signal, and that you can tolerate the risk of agents landing PRs after only automated checks. The project is two weeks old and Apache-2.0 licensed, so expect breaking changes and sparse support.

Official sources

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