OpenAI Open‑Sources Symphony, a SPEC.md for Autonomous Coding Agent Orchestration

What’s new

OpenAI has published Symphony, a specification file (SPEC.md) that describes how to turn a project‑management board into a control plane for multiple autonomous coding agents. The reference implementation, written in Elixir, continuously monitors an issue tracker, creates a dedicated agent for each open task, and ensures that the agent runs until the task is marked complete. If an agent crashes or stalls, Symphony restarts it automatically. The system also allows agents to open new issues when they discover refactoring opportunities or implementation gaps, but every generated issue must be approved by a human before execution proceeds.

The release is not a packaged product; it is a blueprint that any organization can adapt. By publishing the SPEC.md and the Elixir reference code, OpenAI invites teams to build their own orchestrators that fit existing tooling such as GitHub Issues, Jira, or Azure Boards.

Developer experience

From session juggling to task orchestration

Previously, developers who used Codex‑style agents opened a handful of interactive sessions, manually switched between them, and kept mental track of which session was responsible for which piece of code. Most engineers reported a comfortable limit of three to five concurrent sessions before the cognitive load became a bottleneck.

Symphony replaces that model with a task‑centric workflow:

1. Issue creation – A human creates an issue that describes a deliverable (e.g., “Add OAuth support”).
2. Agent assignment – Symphony reads the issue, spawns an agent, and hands over the full description.
3. Autonomous execution – The agent may break the work into subtasks, open new tickets, or generate a PR. All of this happens without further human interaction.
4. Human review – Once the agent marks the task as done, a reviewer inspects the generated code, accepts or rejects it, and closes the issue.

Because the orchestration logic lives in a SPEC.md file, teams can customize the mapping between issue fields and agent behavior without touching the runtime code. For example, a company that uses Jira can add a rule that any issue with the label backend‑critical triggers a higher‑priority agent pool.

Elixir as the runtime backbone

Elixir’s lightweight processes and built‑in supervision trees make it a natural fit for this kind of always‑on orchestration. The reference implementation creates a supervisor for each active task; if the child process (the coding agent) exits unexpectedly, the supervisor restarts it automatically. This pattern mirrors the way OTP handles fault tolerance in telecom systems, but applied to software development pipelines.

Developers who are not familiar with Elixir can still benefit because the SPEC.md is language‑agnostic. The file merely declares:

• Inputs (issue title, description, labels)
• Outputs (status updates, PR URLs, new issue IDs)
• Triggers (state changes on the board)

A thin adapter layer translates those declarations into calls to the chosen issue‑tracker API. OpenAI provides adapters for GitHub and Jira in the repository, and the community has already contributed connectors for Azure DevOps and Linear.

Performance considerations

Running many agents concurrently does increase CPU and memory usage, but the Elixir VM is designed for high concurrency with low overhead. In OpenAI’s benchmark, a typical Symphony node handling 50 simultaneous agents on an m6i.large instance (2 vCPU, 8 GiB RAM) consumed roughly 45 % of the CPU and 1.2 GiB of RAM. Scaling out is straightforward: add more nodes behind a load balancer, and the SPEC.md can specify a sharding key (e.g., project ID) so that tasks are evenly distributed.

User impact

Faster iteration cycles

By eliminating the need for developers to manually switch between Codex sessions, Symphony reduces the average time from task definition to code review by 30 % in OpenAI’s internal pilots. The reduction comes from two sources: fewer context switches for engineers and the ability of agents to run in parallel without human coordination overhead.

Lower risk of broken code

Because agents only produce output that is later reviewed, the cost of a mistake is limited to the reviewer’s time. The orchestration layer also enforces that every PR is associated with a completed issue, making it easier to trace the origin of a change and to roll back if necessary.

Seamless integration with existing CI/CD pipelines

Symphony emits standard GitHub Actions or Azure Pipelines triggers when an issue reaches the ready for review state. Teams can therefore keep their existing quality gates—linting, unit tests, security scans—intact. The only addition is a review gate that checks the agent’s output before merging.

Customizable governance

Since the SPEC.md is under version control, organizations can audit and evolve their orchestration policies just like any other code. Adding a rule that “any issue labeled security‑critical must be reviewed by two senior engineers” is a one‑line change to the spec file, and the change propagates automatically to all Symphony nodes.

Getting started

1. Clone the repository: git clone https://github.com/openai/symphony.git
2. Review the SPEC.md reference to understand the required fields.
3. Choose an adapter (GitHub, Jira, etc.) and configure the API tokens.
4. Deploy the Elixir application on a server or container platform of your choice. The repo includes Dockerfiles for quick start.
5. Create a test issue in your tracker and watch Symphony spin up an agent.

The community has already posted tutorials for popular stacks, such as Running Symphony on Fly.io and Integrating with Azure Boards.

Outlook

OpenAI positions Symphony as a reference implementation, not a commercial product. This openness encourages experimentation: teams can replace the Elixir core with Rust or Go if they prefer, or they can embed additional safety checks (e.g., static analysis before an agent’s PR is opened). The release signals a shift from “agent‑in‑the‑loop” to “orchestrator‑in‑the‑loop,” where the orchestration layer handles the heavy lifting of task distribution and fault tolerance, while developers focus on reviewing and guiding the outcomes.

Author: Sergio De Simone, senior software engineer, currently leading iOS and macOS development at BigML, Inc.