OpenAI open-sources Symphony to run coding agents from your project board

Symphony is an open-source orchestration service from OpenAI that turns issue trackers into autonomous coding workflows. Instead of sitting inside your IDE and micromanaging an AI line by line, you log tasks on a Linear board and let Symphony dispatch background agents to implement them from scratch.

Once an agent finishes the work, it provides proof of delivery: test results, review feedback, complexity notes, and an end-to-end walkthrough video. You simply review the artifacts and approve the pull request.

How it turns issues into pull requests

Traditional coding assistants operate on a one-on-one conversational basis. Symphony shifts developers to a higher vantage point: engineers specify intent and architecture, while the scheduling layer drives Codex instances to write and verify the code in isolated workspaces.

The orchestrator polls your project board and manages agent lifecycles using strict priority rules. By default, it supports up to 10 concurrent agents with per-state throttling. It also includes built-in stall detection that automatically kills and retries any agent that sits idle for more than 5 minutes.

Inside a single run, an agent can iterate up to 20 consecutive turns. Instead of replaying the original system prompt every step, it preserves context on the active thread to avoid wasting tokens. Once the implementation passes checks, the agent posts its CI run, PR review notes, and screen recordings for sign-off.

According to internal testing, OpenAI ran a three-person experiment building a codebase with zero hand-written code. Codex generated around one million lines of code and merged 1,500 pull requests over five months, averaging roughly 3.5 merged PRs per engineer each day. Symphony is the scheduling framework born out of that harness engineering workflow.

Setup and repo-based configuration

Symphony is released under the Apache 2.0 license on GitHub at openai/symphony. It includes a complete architectural specification in SPEC.md alongside a reference implementation built in Elixir.

Rather than relying on external dashboards or databases, Symphony keeps its brain inside your repository. Everything lives in a single WORKFLOW.md file tracked by git. The top section holds YAML configuration for polling intervals and concurrency limits, while the body uses Liquid templates to inject board issue data directly into Codex prompts. Symphony watches this file for changes, letting you update policies on the fly without restarting the service.

The runtime maintains pure in-memory state, relying entirely on the issue tracker API as its single source of truth. OpenAI notes this is an engineering preview intended for trusted environments, meaning security boundaries and sandbox isolation are left to the host team's setup. If you do not want to use the Elixir implementation, you can feed SPEC.md into your preferred coding agent and ask it to port Symphony to your runtime of choice.

Why it matters

We think Symphony is a practical glimpse into how engineering teams will operate once AI agents handle the bulk of routine software construction. If you run a disciplined team that already maintains modular code and clear specs on Linear, it is worth testing on secondary repos to knock out well-scoped tickets.

That said, the prerequisite is steep. Symphony relies heavily on harness engineering: without airtight automated test suites and deterministic CI, autonomous agents cannot meaningfully prove their code actually works. It will not magically fix messy architectures, but for well-scoped chores, it fundamentally changes how much ground a tiny team can cover.