Symphony (OpenAI) — Summary

Symphony is an open-source language-agnostic specification for an AI coding agent orchestration service, published by OpenAI with an Elixir/OTP reference implementation. It solves the problem of turning software project work into isolated, autonomous implementation runs: Symphony continuously polls an issue tracker (Linear), creates per-issue workspace directories, launches Codex in App Server mode inside each workspace, and keeps the agent working until the issue reaches a handoff state ("Human Review") or terminal state ("Done"). The core innovation is the WORKFLOW.md contract — a single YAML-front-matter file teams version in their repository that defines the polling interval, issue states, workspace setup hooks, agent command, approval policy, and the workflow prompt template. Symphony is explicitly a "scheduler/runner" not an agent framework; the business logic lives in the workflow prompt and the coding agent's tools. The Elixir reference implementation uses OTP supervision trees for crash recovery. Compared to seeds: closest to kiro in being a complete runtime environment rather than a CLAUDE.md augmentation, but Symphony is open-source, language-agnostic-by-spec, uses Codex (not a proprietary IDE), and targets Linear-driven team workflows rather than individual developer spec-to-code cycles.

Symphony (OpenAI) — Overview

Origin

OpenAI. GitHub: https://github.com/openai/symphony. Apache-2.0 license. Language: Elixir. Status: "low-key engineering preview for testing in trusted environments."

Philosophy

From the README:

"Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents."

From the SPEC.md:

"Symphony is a long-running automation service that continuously reads work from an issue tracker (Linear in this specification version), creates an isolated workspace for each issue, and runs a coding agent session for that issue inside the workspace."

Important boundary stated explicitly:

"Symphony is a scheduler/runner and tracker reader. Ticket writes (state transitions, comments, PR links) are typically performed by the coding agent using tools available in the workflow/runtime environment."

Design principles from SPEC.md

1. Language-agnostic specification — SPEC.md is the normative document; Elixir is just the reference implementation. Teams are invited to "implement Symphony according to the following spec" in any language.
2. In-repo workflow contract — WORKFLOW.md is versioned with the codebase; no external configuration server.
3. Workspace isolation — per-issue directories; agents work only inside their workspace.
4. Bounded concurrency — max_concurrent_agents: 10 default.
5. Exponential backoff recovery — transient failures retry with backoff; blocked issues are exposed in runtime state.
6. Restart recovery without persistent DB — tracker + filesystem state is sufficient to reconstruct scheduler state after restart.

Harness engineering prerequisite

"Symphony works best in codebases that have adopted harness engineering. Symphony is the next step — moving from managing coding agents to managing work."

The referenced OpenAI harness engineering guide is a prerequisite.

Symphony (OpenAI) — Architecture

Distribution

• Git clone + build — not an npm package or pip package
• Install: git clone → mise install → mix setup → mix build
• Required runtime: Elixir/OTP (managed via mise), Linear API key, Codex CLI

Core components (from SPEC.md)

WORKFLOW.md contract

A YAML-front-matter Markdown file checked into the target repo:

tracker:
  kind: linear
  project_slug: "symphony-0c79b11b75ea"
  active_states: [Todo, In Progress, Merging, Rework]
  terminal_states: [Closed, Cancelled, Done]
polling:
  interval_ms: 5000
workspace:
  root: ~/code/symphony-workspaces
hooks:
  after_create: |
    git clone --depth 1 https://github.com/openai/symphony .
agent:
  max_concurrent_agents: 10
  max_turns: 20
codex:
  command: codex --config shell_environment_policy.inherit=all --config 'model="gpt-5.5"'
  approval_policy: never
  thread_sandbox: workspace-write

Abstraction layers

1. Policy Layer — repo-defined WORKFLOW.md
2. Orchestration Layer — issue dispatch, workspace management
3. Runtime Layer — Codex process management
4. Tracker Layer — Linear integration

Agent runtime

Codex in App Server mode (codex app-server). Symphony serves a linear_graphql tool to the Codex session so it can write back to Linear without needing a full Linear MCP server.

Elixir implementation

elixir/ directory contains the OTP supervision tree. The mix run entry produces ./bin/symphony binary accepting a WORKFLOW.md path argument.

Symphony (OpenAI) — Components

Core service components

Codex skills (5, optional)

Located in elixir/ (can be copied to target repo):

• commit — commit changes
• push — push to remote
• pull — pull from remote
• land — land a PR
• linear — raw Linear GraphQL operations via linear_graphql app-server tool

WORKFLOW.md prompt template

Jinja2 template in the --- body section, receiving issue context variables:

• {{ issue.identifier }}
• {{ issue.title }}
• {{ issue.state }}
• {{ issue.labels }}
• {{ issue.url }}
• {{ issue.description }}
• {{ attempt }} (retry count for loop continuation)

App-server tool (1)

linear_graphql — served by Symphony to the Codex session; allows raw Linear GraphQL operations (comments, state transitions, PR links) from within the agent session.

Hooks (workspace lifecycle, in WORKFLOW.md)

• after_create — shell script run after workspace directory created (e.g., git clone)
• before_remove — shell script run before workspace directory removed

Status surface (optional)

The Elixir implementation includes a terminal dashboard and JSON API at runtime exposing:

• Active runs
• Blocked runs (awaiting operator input)
• Retry queue state

Symphony (OpenAI) — Uniqueness & Positioning

Differs from seeds

Most distinct from all 11 seeds — no direct archetype match. Closest conceptually to taskmaster-ai (issue-tracker-driven task management) but Symphony replaces the task management UI with a fully automated daemon that monitors Linear and dispatches Codex autonomously.

Key differentiators:

1. Language-agnostic specification — SPEC.md with RFC 2119 normative language invites community reimplementations in any language. No other framework in the corpus ships a formal spec document separate from the implementation.

2. Issue-tracker-as-spec — the Linear ticket IS the specification. No separate requirements.md or design.md files. The WORKFLOW.md prompt template receives issue data as Jinja2 variables. This is a fundamentally different spec model from kiro's EARS notation or BMAD's design docs.

3. Background daemon orchestration — Symphony is the only framework that runs as a continuous background service polling an external tracker, rather than being invoked per-task. This changes the human interaction model: engineers manage their Linear board, not their agents.

4. Workspace-isolated per-issue agent processes — each Linear ticket gets its own directory and Codex process with workspace-write sandbox. More rigorous isolation than git-worktree approaches in other frameworks.

5. OpenAI provenance — the only OpenAI-authored framework in the corpus. Uses Codex (not Claude Code) as the agent runtime.

Observable failure modes

• Requires Linear subscription (tracker lock-in)
• Requires "harness engineering" setup as a prerequisite
• Elixir/OTP is an unusual tech stack for most JavaScript/Python shops
• "Engineering preview for trusted environments" — not production-hardened
• Blocked agents are lost on restart (in-memory only)

Competitive positioning

Symphony targets engineering teams that want to remove agent supervision from individual developers entirely, replacing it with standard project management (Linear board). This is a fundamentally different usage pattern from every other framework — it's a team infrastructure tool, not a developer productivity tool.