Symphony

What Symphony Does

Symphony is an open-source orchestration service from OpenAI that turns issue tracker tickets into autonomous coding agent runs. It continuously polls Linear for eligible issues, creates isolated per-issue workspaces, and launches a coding agent session for each one. The agent works the issue — writing code, running tests, opening PRs — and Symphony tracks progress, handles retries, and cleans up when done.

The key insight: engineers manage work (issues), not agents. Symphony handles the translation from "ticket in backlog" to "PR in review."

OpenAI formally announced Symphony as an open-source spec on April 27, 2026, reporting that "some teams at OpenAI saw a 500% increase in landed pull requests during the first three weeks" of internal use — a directional metric with no published baseline. OpenAI is explicit that it does "not plan to maintain Symphony as a standalone product"; it is a reference implementation meant to be studied, forked, or rebuilt.

Category: Autonomous Agentic Engineering Tools

---

How It Works

Architecture

Symphony has six core components:

1. Workflow Loader — Reads WORKFLOW.md from the repo (YAML front matter + prompt body)
2. Config Layer — Typed getters for workflow config with defaults and env var indirection
3. Issue Tracker Client — Fetches and normalizes issues from Linear
4. Orchestrator — Owns the poll loop, dispatch decisions, concurrency, retries, and reconciliation
5. Workspace Manager — Creates and manages per-issue directories with lifecycle hooks
6. Agent Runner — Builds prompts from issue + workflow template, launches the coding agent

Optional: a Status Surface for operator visibility and structured logging.

The WORKFLOW.md Contract

All orchestration policy lives in a single file checked into the repo:

---
tracker:
  kind: linear
  team_key: ENG
  active_states: ["In Progress", "Todo"]
  terminal_states: ["Done", "Cancelled"]
workspace:
  root: ./workspaces
concurrency:
  max_sessions: 3
agent:
  executable: codex
  timeout_minutes: 60
---

You are working on issue {{identifier}}: {{title}}

{{description}}

Follow the project's AGENTS.md for coding conventions...

This means workflow behavior is version-controlled — teams review and iterate on agent instructions the same way they review code.

Execution Flow

1. Poll — Fetch eligible issues from Linear on a fixed cadence
2. Filter — Check state eligibility, blocked-by dependencies, label filters
3. Dispatch — Create workspace, build prompt, launch agent (up to concurrency limit)
4. Monitor — Stream agent updates, track session metrics
5. Reconcile — On each tick, check if issue state changed externally (e.g., cancelled)
6. Complete — Agent finishes at a handoff state (e.g., "Human Review"), workspace preserved

Important Boundary

Symphony is explicitly a scheduler/runner, not a ticket manager. The coding agent itself handles ticket writes (state transitions, comments, PR links) using tools in its runtime environment.

---

Technical Details

Retry & Recovery

• Exponential backoff on transient failures
• Restart recovery without persistent database (reconciles from filesystem + tracker state)
• Stops active runs when issue state changes make them ineligible

Recent Development (as of June 2026)

The repo remains actively maintained — commits through June 9, 2026 added a Symphony Observability web dashboard (with dashboard rows linked back to tracker issues) and opt-in label-based dispatch so projects can require an explicit label before an issue is eligible for an agent run. There are still no tagged GitHub releases; versioning lives in the spec (v1.1 added the Kata CLI runtime). Community reimplementations have appeared in other stacks, including a Go/Charm port (contrabass) and an OpenCode + Linear implementation.

What It Doesn't Do

• No multi-tenant control plane (a basic observability dashboard was added in mid-2026)
• No built-in sandboxing or approval gates
• No distributed job scheduling
• No ticket/PR management logic (that's the agent's job)
• No mandated security posture — implementations define their own trust model

---

Harness Engineering Philosophy

Symphony builds on OpenAI's concept of harness engineering — the idea that the most effective way to work with coding agents is to invest in your repo's structure:

• Strong CI/CD pipelines that agents can run against
• Clear AGENTS.md / WORKFLOW.md conventions
• Good test coverage agents can validate against
• Documentation that serves as agent context

The better your repo's "harness," the more autonomously agents can operate. Symphony is the next step: moving from managing coding agents to managing work that needs to get done.

---

Strengths

• Issue-tracker-driven — Natural integration with existing engineering workflows (Linear)
• In-repo policy — WORKFLOW.md keeps agent behavior versioned and reviewable
• Workspace isolation — Each issue gets its own directory, preventing cross-contamination
• Lightweight — No database, no web UI, just a daemon that reads issues and runs agents
• OpenAI backing — From the Codex team, designed to work well with Codex
• ~25K stars by June 2026 — 13K in the first three weeks; Linear's founder noted a spike in workspace signups when Symphony launched

Limitations

• Linear-only — v1 spec only supports Linear; no GitHub Issues, Jira, or other trackers
• Single-agent per issue — No multi-agent collaboration within an issue (unlike Gastown or Metaswarm)
• No quality gates — No cross-model review, coverage enforcement, or blocking gates
• Elixir-only reference — Spec encourages reimplementation; community ports (Go, OpenCode) exist but only Elixir ships officially
• Engineering preview, permanently — OpenAI says it will not maintain Symphony as a standalone product; it is "prototype software intended for evaluation only"
• No sandboxing — Agents run with whatever permissions the host OS provides
• Codex-oriented — JSON-RPC app-server protocol best supported by Codex, though spec v1.1's Kata CLI runtime opens the door to Claude Code and Gemini

---

What Developers Say

Reaction on Hacker News was mixed — enthusiasm for the pattern, skepticism about the spec's quality:

"This is cool. I've been waiting for something like this! My team has already been keeping significant context in tickets (sessions are just too ephemeral). I've been envisioning this as the next step. This might just make me take another look at Codex." — solarkraft, Hacker News

"The specs are inscrutable agent slop. I want it to tell me what it does and instead it just lists database fields. It mentions a state machine and then proceeds to not describe the state machine." — exclipy, Hacker News

"OpenAI is doing the Joel Spolsky move, commoditize the layer above yours. Google did it with Kubernetes back when GCP was losing on infra... The spec is free, the runtime is where the money is." — 7777777phil, Hacker News

"Complementary to something like symphony which doesn't deliver the harness you need to make working software, attractor's graph orchestration inside the loop that symphony creates can set determinative workflows." — MarkMarine, Hacker News, on pairing Symphony with StrongDM's Attractor

---

Competitive Context

Symphony occupies a unique niche: the simplest path from "issue in tracker" to "agent working on it." It trades multi-agent sophistication for operational simplicity.

---

Who Should Use Symphony

Good fit:

• Teams already using Linear who want to automate issue execution
• OpenAI Codex users looking for orchestration
• Organizations adopting "harness engineering" practices
• Teams that want version-controlled agent workflow configuration

Not a fit:

• Teams needing multi-agent collaboration on single issues
• Organizations requiring built-in security/sandboxing
• Teams using Jira, GitHub Issues, or other non-Linear trackers
• Production environments requiring approval gates

---

Bottom Line

Symphony is OpenAI's answer to "what comes after coding agents?" — not better agents, but better orchestration of agents around existing work. By connecting Linear issues to Codex sessions through a simple daemon with in-repo configuration, it removes the operational overhead of running autonomous agents. The reception confirms demand: 13K stars in three weeks, ~25K by June 2026, and OpenAI's claim of a 500% increase in landed PRs on some internal teams.

Recommended for: Linear + Codex teams that want the simplest path from issue tracker to autonomous execution, and teams adopting harness-engineering practices who are comfortable treating Symphony as a reference to fork rather than a product to depend on.

Not recommended for: Teams needing multi-agent collaboration, built-in sandboxing or approval gates, non-Linear trackers, or a vendor-supported product — OpenAI explicitly will not maintain Symphony as a standalone product. For multi-agent orchestration, cross-model review, or enterprise security, look at Metaswarm, Gastown, or Tembo.

Outlook: Symphony's lasting impact is likely the pattern, not the codebase. The spec is already being reimplemented in other stacks and other agent runtimes (Kata CLI, Claude Code, Gemini via spec v1.1), and the strategic read — commoditize the orchestration layer so the agent runtime is where the money is — suggests OpenAI's investment will flow into Codex itself, with Symphony as the free blueprint around it.

---

Research by Ry Walker Research • methodology