OpenAI Open-Sources Symphony, a Spec That Turns Linear Into an Agent Orchestrator

OpenAI has open-sourced Symphony, an orchestration layer for its Codex coding agent that turns a project-management board like Linear into a control plane for autonomous agents — and internal teams using it saw a 500% increase in landed pull requests within the first three weeks.

The project, published April 27, 2026, by engineers Alex Kotliarskyi, Victor Zhu, and Zach Brock, lives on GitHub and has already collected over 15,000 stars as of April 23. Symphony is not a product. It is, technically, a SPEC.md file — a written specification that defines a service capable of orchestrating coding agents to complete project work autonomously, with a reference implementation written in Elixir.

From human attention bottleneck to ticket-level supervision

Symphony emerged from an unusual internal experiment. Six months ago, the team behind it decided to build a repository with no human-written code: every line had to be generated by Codex. That effort, documented in an earlier post on harness engineering, succeeded — but it exposed a new bottleneck.

Coding agents, whether accessed through web apps or the CLI, remain interactive tools. Each engineer would open a few Codex sessions, assign tasks, review output, and steer the agent. In practice, most people could manage three to five sessions at a time before context switching became painful. Beyond that, productivity dropped.

"We'd effectively built a team of extremely capable junior engineers, then assigned our human engineers to micromanaging them," the team writes. "That wasn't going to scale."

The insight was reframing the problem. Pull requests and coding sessions are means to an end; software workflows are actually organized around deliverables — issues, tasks, tickets, milestones. So the team stopped supervising agents directly and let them pull work from the task tracker.

How the system works

Symphony continuously watches a Linear board and guarantees that every active task has an agent running in its own isolated workspace until the work is done. If an agent crashes or stalls, Symphony restarts it. If new work appears, Symphony picks it up. The default global concurrency limit is 10 agents, with a 30-second polling interval and per-state concurrency controls.

The workflow uses ticket statuses as a state machine. Agents only start on unblocked tasks, so execution unfolds as a directed acyclic graph. In one example the team cites, a React upgrade was marked blocked on a migration to Vite; agents started the React work only after the Vite migration completed.

Agents can also file their own work. During implementation or review, they notice improvements outside the current task's scope — a performance issue, a refactoring opportunity — and open new issues for humans to evaluate and schedule. Many of those follow-up tasks get picked up by agents too.

Because the orchestrator runs on devboxes and never sleeps, work can be filed from anywhere. One engineer on the team made three significant changes from the Linear app on his phone, from a cabin on poor wifi.

The stakes are straightforward: the economics of code change when engineers no longer invest human effort in driving implementation. Speculative tasks become trivial to spin up. Product managers and designers can now file feature requests directly into Symphony and receive a review packet that includes a video walkthrough of the feature running in the real product — no repo checkout, no Codex session management.

Symphony also addresses the fragile last mile in large monorepos, the kind OpenAI runs internally. The system watches CI, rebases when needed, resolves conflicts, and retries flaky checks. By the time a ticket reaches the Merging status, the team has high confidence the change will land on the main branch without human babysitting.

Tradeoffs the team acknowledged

The shift came with costs. Moving from interactive steering to ticket-level assignment meant losing the ability to nudge agents mid-flight. Sometimes an agent produced something that completely missed the mark. The team's response was to add guardrails rather than patch results manually — end-to-end tests, driving the app through Chrome DevTools, QA smoke tests, and significantly improved documentation.

Not every task fits. Ambiguous problems and work requiring strong judgment still go to engineers working directly with interactive Codex sessions — which, the team notes, are usually the most interesting tasks left for humans.

The team also learned that treating agents as rigid nodes in a state machine fails. "Models get smarter and can solve bigger problems than the box we try to fit them in," they write. Early versions only asked Codex to implement the task; that proved too limiting. Given tools like the gh CLI and skills to read CI logs, Codex now closes old PRs and pulls reports on completed versus abandoned work. The approach evolved toward giving agents objectives rather than strict transitions — much like a manager assigning a goal to a direct report.

A spec built by agents, for agents

The repository's most striking feature is what Symphony actually is. Open the repo and you find a specification document: a language-agnostic definition of the problem and intended solution, covering workflow loading, issue normalization, orchestration state, workspace management, retry backoff, and observability.

The first version of Symphony was a Codex session running in tmux, polling Linear and spawning sub-agents. The second lived inside the team's main repository. Once basic functionality existed, the team used Symphony to build Symphony. They then asked Codex to implement the spec in TypeScript, Go, Rust, Java, and Python to identify ambiguities and simplify the system. "It succeeded in every language," the team writes. The reference implementation stayed in Elixir — chosen, the team says, because when code is effectively free, you can pick languages for their strengths, like Elixir's concurrency primitives.

Symphony connects to Codex through app server mode, a built-in headless mode exposing a documented JSON-RPC API for starting threads and reacting to turns. To avoid exposing the Linear access token to subagents, the system uses dynamic tool calls to expose a raw linear_graphql function that executes arbitrary requests against Linear without MCP and without leaking credentials into containers.

The implicit development workflow humans always followed — pick up an issue, move it to In Progress, open a PR, move it to Review, attach videos — is now captured in a version-controlled WORKFLOW.md file that Symphony enforces. If the team decides agents should attach self-reflection to finished work, they add a step to the file and Symphony guides agents through it.

Why OpenAI released it

Internal adoption came first: after a demo showing the system managing tasks and attaching proof-of-work videos, the Symphony project channel grew and teams across the organization started using it organically. Outside OpenAI, Linear founder Karri Saarinen highlighted a spike in workspaces created when Symphony was released.

The company is explicit that it will not maintain Symphony as a standalone product. It is a reference implementation demonstrating what Codex App Server can do when paired with workflow tools. "As coding agents become better at reasoning and following instructions, we suspect the bottleneck at other companies will shift from writing code toward managing agentic work, too," the team writes. Their suggested path for other engineering organizations: point your favorite coding agent at the spec and build your own version.