OpenAI hat Symphony als Open-Source-Spezifikation für die Orchestrierung von Codex-Agenten veröffentlicht. Symphony beschreibt einen Ansatz, bei dem ein Projekt- oder Issue-Tracker wie Linear zur Steuerungsebene für Coding-Agenten wird: Jede offene Aufgabe erhält einen eigenen Agenten-Workspace, Agenten arbeiten fortlaufend an Tickets, und Menschen prüfen die Ergebnisse.
Ausgangspunkt war laut OpenAI ein interner Workflow, in dem Repositorys ohne von Menschen geschriebenen Code aufgebaut wurden und Codex als vollwertiger Teamkollege eingesetzt wurde. Nachdem dieser Ansatz funktioniert hatte, wurde Context Switching zum nächsten Engpass: Ingenieurinnen und Ingenieure konnten in der Praxis nur wenige gleichzeitige Codex-Sitzungen sinnvoll steuern, bevor Produktivität durch das Wechseln zwischen Sitzungen, manuelles Nachsteuern und das Beheben hängender Aufgaben sank.
Symphony verlagert die Organisation daher von interaktiven Sessions und Pull Requests auf Deliverables wie Issues, Tasks und Tickets. In der beschriebenen Arbeitsweise ordnet Symphony jeder offenen Linear-Aufgabe einen dedizierten Agenten zu, überwacht das Task-Board kontinuierlich und startet Agenten bei Abstürzen oder Stillständen neu. Arbeit wird damit von einzelnen Sessions und auch von einzelnen Pull Requests entkoppelt; manche Tickets erzeugen mehrere PRs über verschiedene Repositorys hinweg, andere bestehen nur aus Analyse oder Investigation ohne Codeänderungen.
OpenAI beschreibt, dass sich auf dieser Basis auch größere Arbeitseinheiten modellieren lassen. Agenten können zunächst etwa Codebasis, Slack oder Notion analysieren und einen Implementierungsplan erstellen. Anschließend kann daraus ein Aufgabenbaum mit Abhängigkeiten entstehen. Agenten beginnen nur mit nicht blockierten Aufgaben, sodass parallele Ausführung entlang eines DAG möglich wird. Als Beispiel nennt OpenAI ein React-Upgrade, das als blockiert durch eine vorherige Migration auf Vite markiert wurde.
Agenten können nach dieser Darstellung auch selbst neue Arbeit anlegen, wenn sie während Implementierung oder Review zusätzliche Verbesserungen erkennen, etwa Performance-Probleme, Refactoring-Möglichkeiten oder Architekturänderungen. Diese Folgeaufgaben werden später bewertet und eingeplant. OpenAI hebt dabei hervor, dass der kognitive Aufwand für explorative oder mehrdeutige Arbeit sinkt, weil Tickets günstig angelegt, Prototypen ausprobiert und unerwünschte Ergebnisse verworfen werden können.
Bei einigen Teams stieg die Zahl der gelandeten Pull Requests laut OpenAI in den ersten drei Wochen um 500 Prozent. Zugleich beschreibt das Unternehmen eine Veränderung in der Arbeitsweise: Weil Ingenieurinnen und Ingenieure weniger Zeit mit der direkten Beaufsichtigung einzelner Codex-Sitzungen verbringen, sinken die wahrgenommenen Kosten einzelner Codeänderungen. Auch Personen außerhalb der eigentlichen Entwicklung, etwa Produktmanagement oder Design, können demnach Feature-Anfragen direkt in Symphony einstellen und als Ergebnis ein Review-Paket mit Video-Durchlauf der Funktion im realen Produkt erhalten.
In großen Monorepos soll Symphony zudem beim letzten Schritt bis zum Merge helfen. Das System beobachtet CI, führt Rebase-Vorgänge aus, löst Konflikte, wiederholt fehlgeschlagene oder flaky Checks und begleitet Änderungen durch die Pipeline. Wenn ein Ticket den Status Merging erreicht, soll die Wahrscheinlichkeit hoch sein, dass die Änderung ohne manuelle Betreuung in den Hauptbranch gelangt.
OpenAI beschreibt aber auch Grenzen und Trade-offs. Durch die Verlagerung von interaktivem Steuern auf Ticket-Ebene geht die Möglichkeit verloren, Agenten während der Ausführung ständig nachzujustieren. Manche Ergebnisse verfehlten das Ziel vollständig. Diese Fehlschläge wurden nach eigener Darstellung genutzt, um das System robuster zu machen, etwa durch zusätzliche Guardrails, Skills, End-to-End-Tests, Steuerung über Chrome DevTools, QA-Smoke-Tests sowie präzisere Dokumentation. Nicht jede Aufgabe eigne sich für den Symphony-Stil; insbesondere mehrdeutige Probleme oder Arbeit mit hohem Urteils- und Erfahrungsanteil sollen weiterhin direkt in interaktiven Codex-Sitzungen bearbeitet werden.
Außerdem habe sich ein starres Modell mit Agenten als festen Zustandsknoten als ungeeignet erwiesen. Frühere Versionen beschränkten Codex zu stark auf reine Implementierung. Deshalb wurden den Agenten zusätzliche Werkzeuge gegeben, darunter gh CLI und Fähigkeiten zum Lesen von CI-Logs. So können sie laut OpenAI auch mehrere PRs verwalten, Review-Feedback einarbeiten, alte PRs schließen oder Berichte zu abgeschlossener und abgebrochener Arbeit erstellen. Statt strikter Zustandsübergänge setzt der Ansatz daher stärker auf Zielvorgaben.
Technisch besteht Symphony im Kern aus einer SPEC.md-Datei, die Problem und Lösungsansatz definiert. Die Referenzimplementierung wurde in Elixir geschrieben; die Grundidee soll sich aber bereits in einem einfachen Markdown-Dokument ausdrücken lassen. OpenAI beschreibt, dass die erste Version lediglich aus einer Codex-Sitzung in tmux bestand, die Linear abfragte und für neue Aufgaben Subagenten startete. Später wurde das System in ein bereits agentenfreundlich aufgebautes Haupt-Repository integriert. Danach wurde Symphony mit Symphony weiterentwickelt.
Für die Veröffentlichung wurde die Idee in eine eigenständige SPEC.md ausgelagert und erneut von Codex implementiert. Für die Referenzimplementierung fiel die Wahl auf Elixir wegen seiner Eigenschaften für die Orchestrierung und Überwachung nebenläufiger Prozesse. OpenAI berichtet, Codex habe die Elixir-Implementierung in einem Durchgang erstellt; anschließend seien Spezifikation und Umsetzung iterativ verfeinert worden. Zur Schärfung der Spezifikation ließ OpenAI Codex Symphony zudem in TypeScript, Go, Rust, Java und Python umsetzen, um Mehrdeutigkeiten zu finden und das System zu vereinfachen.
Der Kernansatz wurde dabei von internen Abhängigkeiten gelöst und auf einen einfachen Grundsatz reduziert: Für jede offene Aufgabe soll garantiert ein Agent in einem eigenen Workspace laufen. Ergänzend wird der Entwicklungsprozess in einer WORKFLOW.md-Datei dokumentiert, also etwa Arbeiten an einem Issue, Checkout des Repositorys, Statuswechsel, Verknüpfung von PRs und Anhängen von Videos. Symphony soll sicherstellen, dass Agenten diesem dokumentierten Ablauf folgen.
Genutzt wurde dabei auch Codex im App Server Mode, einem headless Modus mit JSON-RPC-API für programmatische Interaktion. OpenAI bezeichnet diesen Modus als besser skalierbar und bequemer als CLI- oder tmux-basierte Steuerung. Für den Zugriff auf Linear wurden laut Beitrag Dynamic Tool Calls verwendet, um eine raw linear_graphql-Funktion bereitzustellen, ohne Access Tokens an Subagenten oder Container weiterzugeben.
OpenAI kündigt an, Symphony bewusst nur als minimale Orchestrierungsschicht offen zu legen und nicht als eigenständiges Produkt zu pflegen. Die Spezifikation und das Repository sind als Referenzimplementierung gedacht, die an eigene Umgebungen angepasst werden kann. Im Mittelpunkt stehe weiterhin Codex samt App Server; Symphony diene dazu, Codex mit Workflow-Werkzeugen wie Linear zu verbinden.
