OpenAI open-sourced Symphony on May 17 — a SPEC.md plus an Elixir reference implementation for orchestrating autonomous coding agents off a project-management task board. Symphony continuously watches the board (issues, tasks, tickets, milestones), assigns each active task to a dedicated agent that runs autonomously until the task is done, and surfaces the result for a human to accept or reject. github.com/openai/symphony. OpenAI's framing: "the cost of an agent making mistakes is significantly reduced, since it primarily involves reviewing completed work and rejecting it" — batched async review rather than interactive in-flight correction.
The architectural choice that separates Symphony from existing agent frameworks is the control plane. LangGraph models state as a graph the orchestrator owns; AutoGen treats it as an inter-agent conversation; CrewAI uses an explicit role/task assignment. Symphony parasites whatever issue tracker the team already uses as the control plane — every task that exists in the team's board is an agent input, and the agent's output flows back as ticket updates. That's a non-trivial design point: it eliminates the bespoke orchestrator UI and reuses the human review workflow teams already operate. It also constrains the agent's task surface to "what fits in an issue," which is a useful prior. Notable implementation detail: Elixir, not Python or TypeScript. Elixir's OTP supervision-tree semantics map cleanly to long-running per-agent processes that need restart and isolation.
Position this against the rest of the May orchestrator week. Anthropic shipped Routines (Claude Code workflows on Anthropic's cloud, repo-event-triggered, no published pricing). BerriAI open-sourced LiteLLM Agent Platform (Kubernetes self-hosted, MIT, multi-provider). Now OpenAI ships Symphony (SPEC plus Elixir reference, issue-tracker control plane). Three different orchestration philosophies released within nine days. Symphony's specific bet is that the agent orchestrator should disappear into the team's existing PM tooling rather than be a new surface — different competition framing than "we operate the cloud" (Routines) or "you operate the Kubernetes" (LiteLLM). Whether the SPEC.md becomes a real interop standard or stays an OpenAI-only convention depends on whether community implementations land for non-Codex agents.
Monday: if your team already runs an issue tracker (Linear, GitHub Issues, Jira) and has been considering autonomous coding agents, Symphony's model is worth a serious look — the integration story is "your existing board, plus an agent watching it." The Elixir reference implementation is the gate — if you don't have BEAM expertise, you either treat it as a model to reimplement in your preferred runtime or wait for community ports. The near-term question is whether Symphony becomes a SPEC that Codex Mobile, Codex CLI, and third-party agents converge on, or whether it stays a Codex-only orchestrator. Watch the GitHub repo for non-Codex adapter PRs and the SPEC.md for protocol-versus-implementation language in the next four to six weeks.