// the find
openai/symphony
Symphony turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents.
Symphony is OpenAI's orchestrator for autonomous coding agents: it watches a tracker (Linear, Jira, Asana, GitHub, GitLab), spawns isolated Codex runs against tickets, and lands the resulting PRs once CI and review checks pass. It's aimed at teams already running agent-driven development who want to stop babysitting individual agent sessions and manage the work queue instead.
The Elixir/OTP choice actually earns its keep here — agent_runtime_supervisor.ex uses supervision trees to isolate each run, so one agent crashing doesn't take down others, which is a better fit than most orchestrators bolted onto a request/response web framework. The five tracker integrations (Asana, Jira, Linear, GitHub, GitLab) all follow the same adapter/agent_tool/client split, and each has a live e2e test suite in CI, not just mocked unit tests. They also ship SPEC.md as a first-class artifact separate from the Elixir code, explicitly so teams can regenerate Symphony in another language — an unusually honest way to decouple the design from one implementation.
The README calls this a 'low-key engineering preview for testing in trusted environments,' and the suggested distribution path — ask your coding agent to implement the spec, or use the 'experimental reference implementation' — is not something you can npm/hex install and trust in CI today. It also assumes you've already adopted 'harness engineering' as a prerequisite, so there's real setup cost before you get anything running. The core workflow (agent lands PRs autonomously) is coupled tightly to Codex via codex/app_server.ex; if your team standardizes on a different coding agent, it's unclear how much of this you actually get to reuse versus rewrite.