What Symphony actually is#

Symphony is not an app you install. It is a spec — a single SPEC.md markdown file, released by OpenAI under Apache 2.0 — that describes how a long-running service should orchestrate autonomous coding agents (OpenAI's Codex) using an issue tracker as the control plane.

The spec's own one-line definition: "A long-running automation service that continuously reads work from an issue tracker, creates isolated workspaces, and runs coding agent sessions." In v1 that tracker is Linear. Every open issue becomes a dedicated agent workspace; the service polls the board (default: every 30 seconds), claims eligible issues, spins an isolated sandbox per issue, and drives a Codex session through retries and back-off until the task lands as a pull request.

Crucially, the spec is language-agnostic and written in RFC MUST/SHOULD/MAY terms. OpenAI ships an Elixir reference implementation on the BEAM — chosen for its concurrency model — but that's a demonstration, not a dependency.

The deliverable isn't the code. It's the spec. You already own the control plane — it's your ticket board.

Why founders should care#

The pitch OpenAI makes is that this is what "code is effectively free" looks like operationally. When a competent agent can take an issue to a PR unattended, the scarce resource stops being typing and becomes deciding what to build and reviewing what came back. OpenAI reports that on some internal teams, landed PRs jumped roughly 500% in the early weeks — a number worth reading as "teams that had already restructured their work around this," not a guarantee for a cold start.

The mental model shift is the point. Instead of babysitting one agent in a chat window — the Claude Code vs. Codex CLI vs. Gemini CLI mode most of us still work in — you manage a backlog and let a supervisor loop keep an agent alive per active task. If an agent crashes or stalls, Symphony restarts it. If a new issue appears, it gets picked up. Your board becomes the queue, the dashboard, and the API all at once.

How the control-plane model works#

Issues move through a small state machine — unclaimed → claimed → running (or retry-queued) → released — enforced by a single authoritative orchestrator so two agents never grab the same ticket. Configuration lives in a repo-owned WORKFLOW.md (YAML front matter plus a templated prompt body), which means the policy for how agents behave is version-controlled next to your code.

The knobs the spec defines are boring in the best way. Illustratively, they include:

polling:
  interval_ms: 30000        # how often to poll the tracker
agent:
  max_concurrent_agents: 10 # spec default
  max_turns: 20             # per-issue turn budget
codex:
  command: codex app-server # the agent process to drive

Safety is baked in rather than bolted on: each issue gets a deterministic, isolated workspace path, and the spec mandates validating cwd == workspace_path before launching the agent subprocess, so a runaway agent can't wander your filesystem.

How to adopt it without Elixir#

You do not need to run OpenAI's implementation. The realistic on-ramp for a small team:

  1. Read SPEC.md as a design doc. It is copyable and precise. Treat it as the blueprint for your own thin orchestrator.
  2. Have Codex build it. OpenAI itself dogfooded the spec by having Codex reimplement it across TypeScript, Go, Rust, Java, and Python — every ambiguity that surfaced got pushed back into the spec. Point your agent at the same file.
  3. Start with one label. Wire a single Linear label (say, agent) to the loop, keep concurrency at 1–2, and require human review before merge.

When it's overkill — and the real catch#

Symphony earns its keep when you have a steady stream of well-scoped, independent tickets. It is overkill — and actively counterproductive — for exploratory work, tightly coupled changes, or a backlog written in one-line shorthand. If you just want to delegate a handful of tasks without running your own loop, a hosted background agent like Devin, Codex Cloud, or Jules is the lighter tool. The spec explicitly lists a rich multi-tenant control plane as a non-goal; this is deliberately a single-orchestrator tool, not a platform.

The non-obvious catch: once code is cheap, your issue tracker becomes your bottleneck. A vague ticket now produces a vague PR at machine speed. The teams reporting big gains didn't just add agents — they upgraded their issue-writing discipline, because the board is now the program.

What it means for you#

If you're a solo founder or a small team, the takeaway is smaller than the headline and more useful. You probably won't run ten Codex agents next week. But you can adopt the shape: put well-specified work on a board, let an agent take the mechanical ones to a PR, and spend your scarce hours on specification and review. Symphony's contribution is proving the loop works and handing you a free, precise blueprint. The constraint that's left is one no model can fix for you — knowing exactly what you want built.