Symphony: a spec, a preview warning, and four proofs of work

The repository is a specification with a reference implementation beside it

Start with what is in the tree, because it sets expectations. There are eight top-level entries: .codex/, .github/, LICENSE, NOTICE, README.md, SPEC.md, docs/ and elixir/. There is no service at the root, no package manifest at the root, and no Dockerfile.

The README then offers two ways in, and the first one is not an installation. It asks you to tell your favourite coding agent to build Symphony in a programming language of your choice, from a specification:

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

The second option is the experimental reference implementation, with setup instructions in elixir/README.md, or again delegated to an agent:

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

So the canonical artefact is SPEC.md and the Elixir code is a reference for it. That is a deliberate shape, and it has a consequence worth stating: the thing you depend on is a document, not a library, and a document can change without a release being cut. If you build your own implementation, pin the specification revision you built against.

A Linear board becomes isolated runs, and the agent has to show its work

The demo description is the densest statement of what the system does. 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. The summary the README puts on top is that engineers do not need to supervise Codex, they can manage the work at a higher level.

Four things are worth pulling out of that.

The unit of work is a run, and runs are isolated. That is the word the project uses twice, in the summary and in the description, and it is the claim the rest of the design exists to support.

The issue tracker named is Linear, though the project description says issue-tracker work in general, so Linear is the demonstrated example rather than a documented requirement list.

Proof of work is a list of four specific artefacts rather than a sentence of self-assessment: a CI result, the review feedback, an analysis of how complex the change turned out to be, and a recorded walkthrough. A design in which an unattended agent has to produce a video of what it did is doing something quite deliberate about auditability.

And the landing of the pull request is gated on acceptance rather than on the agent finishing. That is the difference between a run that completes and a run that completes and is admitted.

One caveat: this is the project's description of its own demo video, so read it as the intended contract rather than as a verified one.

The workflow file is where a team makes it theirs

The repository description contains the sentence that tells you what is configurable: this service turns issue-tracker work into isolated implementation runs and lets teams define project-specific automation through a workflow file.

That is a small clause doing a lot of work. A system that spawns agents against your repository needs to know which board to watch, what counts as a unit of work, what an agent may touch, and what has to be true before a change lands. None of that can be baked into a reference implementation, so it lives in a file the team writes.

Which makes that file the most important thing to read after the specification, and also the thing the README does not describe. There is no schema, no field list and no example in the text of the README, and it does not say whether the file is versioned in your repository or configured per environment. Those answers are not in the README, which links to SPEC.md and elixir/README.md.

For an adopter that is the concrete first task: find out what the workflow file can express, because the difference between a useful run and a runaway one will live in it.

The only safety statement is a warning about trusted environments

There is one warning box in the README and it is worth reading slowly. Symphony is a low-key engineering preview for testing in trusted environments.

Four words in that sentence carry the weight. Low-key is a statement about maturity rather than about function, and it is the only maturity statement offered. Engineering preview says the same thing more formally. Trusted environments says the opposite of what you want to hear about autonomous agents opening pull requests: this is meant for a repository and a team where an agent going wrong is survivable.

Nothing else in the README speaks to the operational questions that follow from that. There is no statement about authentication for the service, no description of how an isolated run is contained, and no discussion of what the agent can reach.

The honest reading is not that the project is careless, but that it is early and says so once. If your repository is production code with real users behind it, the warning is the specification for what to expect, and the isolation claim is the thing to test before you rely on it.

It assumes a harness exists, and Symphony is the step after that

The Requirements section is three sentences and one of them is a precondition. Symphony works best in codebases that have adopted harness engineering, and the project's own framing is that Symphony is the next step, moving from managing coding agents to managing work that needs to get done.

Read that as a prerequisite rather than a preference. Symphony is a layer on top of that: it takes the work item, runs it autonomously, collects proof, and waits for acceptance.

The consequence is about who this is for. If your team has never run a coding agent against your repository, Symphony is not where you start, and nothing in this repository will get you there. If you have, then Symphony is asking a different and more interesting question: not how do we use agents, but how do we stop supervising them.

There is a related detail in the tree. A .codex/ directory sits at the top level, which is agent configuration for one specific coding agent, and the README's demo describes agents not needing supervision of Codex in particular. So the reference implementation is written with that agent in mind even though the spec is language-neutral and asks to be implementable in a language of your choice.

Version 0.0.3, a nightly tag, and no stable release

The release list is short. There is v0.0.2 from 2026-07-24, then v0.0.3 and a rolling tag called nightly, both published on 2026-09-15, and the last push to the repository was on 2026-09-15.

Three observations follow. The version is a zero-zero series, which by convention means no stability promise is being made. There is a nightly tag alongside the numbered releases, so there is a moving reference in addition to the ones you can pin. And the listed releases fit in about seven weeks, from 2026-07-24 to 2026-09-15, which is what a project at this stage looks like rather than a project with a slow release rhythm.

What that means in practice is that the numbered tags are where you pin, and the specification is what you actually read, because a spec and an implementation version independently can agree or disagree. The homepage is also worth noting: it is an OpenAI blog post about open source Codex orchestration with Symphony, not a documentation site, so the repository's docs/ directory is the documentation.

None of that is a criticism of a preview. It is the information you need in order to decide whether a moving artefact is acceptable in your workflow, and the answer differs sharply between experimenting on a repository you can throw away and running it where changes land.

Editorial conclusion

Adopt Symphony if your team already runs coding agents through a harness and your issue tracker work is well specified enough to hand to a run without supervision, because that is the case the project describes and the case the warning assumes. Do not adopt it as a service to depend on: the top level of the repository is a specification, a directory of docs, an Elixir reference implementation and a NOTICE file, the newest release is v0.0.3, and the README's own warning limits it to trusted environments. Read SPEC.md before anything else, since that is the artefact both install paths point at and the one that can change independently of any code release. And decide for yourself what CI status, review feedback, a complexity analysis and a walkthrough video actually certify, because those four are the project's description of its own demo rather than a documented acceptance contract.

Frequently asked questions

Official sources

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