Symphony

Symphony is a spec with a demo attached. The reference implementation polls your issue tracker, starts a Codex agent per open task and lands pull requests, and it drives Codex only. OpenAI released it for teams practising harness engineering and said in the same breath that it will not maintain it as a product. The daily trait is that there is no daily: it runs unattended and you review PRs.

Adopt SPEC.md as a design document if you have a Codex subscription and a full Linear backlog. Do not adopt the Elixir binary. Pick Gas Town or Paperclip for a loop with someone behind it.

The README says it plainly: prototype software intended for evaluation only, presented as-is. The concrete failure is state. Issues the loop has marked blocked are held in memory only, and restarting the orchestrator clears that map, so every restart re-dispatches tasks that failed the last time, each a new Codex session on your account.

Expect to run it under something that remembers. What it does right: if the workflow file fails to reload, the loop continues on the last known good version instead of stopping or running a half-parsed one.

The reference implementation is small enough to describe completely. 1. A single WORKFLOW.md carries YAML front matter for tracker.kind, workspace.root, hooks.after_create and codex.command, and its Markdown body is the session prompt. 2. Each issue gets its own workspace. 3. agent.max_concurrent_agents defaults to 10 and agent.max_turns to 20. 4. Crashed or stalled agents are restarted, and a pull request lands with proof of work.

No benchmark is published, and the SPEC is a protocol rather than a claim. The observation: a specification that fits in one file is the rarest artefact on this board.

This is not a product, it is demand generation. OpenAI released it in April 2026 under Apache-2.0, it only drives Codex, and every task it dispatches is a Codex session billed to an OpenAI account, so the loop's job is to multiply consumption. Disclaiming maintenance up front avoids the support cost while keeping the 27,023 stars of attention.

Moat: none intended; the spec is meant to be copied. Likely outcome: the ideas fold into the Codex product and the repository goes quiet. Position: use the pattern, buy nothing, and expect a first-party version.

The demo is a board that empties itself. Procurement: the host needs Elixir and OTP installed through mise, plus codex, git and credentials for the tracker, with adapters for Linear, GitHub Issues, Jira Cloud, Asana and GitLab. One orchestrator box would serve sixty engineers, which is the right shape, but there is no SSO, no audit log and nobody on call when it stops at midnight.

It is headless by nature, so CI fit is good. Onboarding is a build from source. Not yet; if we want this, we build our own from the spec, which is what the README tells us to do.

Apache-2.0 and Elixir, which I do not write but can read. The swap point is codex.command in the front matter: it is a string, so in principle any CLI that accepts a prompt and exits goes there, though nothing but Codex is supported. hooks.after_create runs my own setup in each workspace. There is no MCP layer and no model setting; the agent brings both.

The README recommends implementing your own hardened version based on SPEC.md, which is the only vendor I have seen invite the fork in writing. I intend to take them up on it.