Am 27. April 2026 hat OpenAI Symphony unter Open-Source-Lizenz veröffentlicht: eine Spezifikation, die ein Projektmanagement-Board wie Linear in eine Steuerebene für Codex-Coding-Agenten verwandelt. Jedes offene Ticket bekommt einen eigenen Agenten, der Agent läuft bis zum fertigen Pull Request, und das Team greift nur noch zum Review ein. Dieser Leitfaden zeigt, was die Spec tatsächlich definiert, wie die Elixir-Referenzimplementierung funktioniert und wo sie sich im eigenen Stack auszahlt.
Die meisten Agent-Frameworks fühlen sich heute noch wie aufgeräumter Chat an. Symphony argumentiert stärker: Die Arbeitseinheit ist nicht ein Prompt, sondern ein Ticket. Wenn ein Ticket sauber beschrieben ist, kann ein Agent die ganze Schleife von Todo bis zum gemergten PR fahren, und das Team verbringt seinen Tag mit Reviews statt mit dem Anstupsen eines Chat-Fensters. OpenAI nennt eine Steigerung der gemergten PRs um 500 % in einigen internen Teams in den ersten drei Wochen.
Die 30-Sekunden-Version
Was Symphony tatsächlich ist
Symphony ist kein SaaS-Produkt, und OpenAI plant nicht, es so zu pflegen. Es sind zwei Dinge in einem öffentlichen Repository:
- SPEC.md, eine einzige Markdown-Datei, die beschreibt, wie sich ein Dienst zur Orchestrierung von Coding-Agenten verhalten soll: wie er aus dem Issue-Tracker liest, wie er einen Agenten durch Retries und Back-off führt und wie er eine Aufgabe bis zum Pull Request bringt.
- Eine Referenzimplementierung in Elixir auf der BEAM-VM, die die Spec end-to-end gegen Linear, GitHub und Codex demonstriert.
Die Autoren (Alex Kotliarskyi, Victor Zhu und Zach Brock) verstehen Symphony explizit als Referenz, nicht als Plattform. Der erwartete Workflow ist: Spec lesen, forken und im eigenen Stack nachbauen.
In einigen Teams bei OpenAI stieg die Zahl der gemergten PRs in den ersten drei Wochen um 500 %. Sobald Engineers keine Codex-Sessions mehr beaufsichtigen, sinken die gefühlten Kosten pro Änderung, und die Ökonomie von Code-Änderungen verschiebt sich grundlegend.
Das Linear-Board als Zustandsmaschine
Die wichtigste Designentscheidung in Symphony ist, das Linear-Board als endliche Zustandsmaschine zu behandeln. Jedes Ticket hat einen Status, und der Orchestrator interessiert sich nur für diesen Status:
| Status | Was Symphony tut | Wer handelt |
|---|---|---|
| Todo | Legt einen frischen Agent-Workspace für das Ticket an | Symphony |
| In Progress | Agent recherchiert, editiert, lässt Tests laufen, öffnet einen Draft-PR | Codex-Agent |
| Review | Markiert den PR als bereit zum Review und benachrichtigt Reviewer | Menschliche Reviewer |
| Merging | Mergt den PR, schließt das Ticket, baut den Workspace ab | Symphony + GitHub |
Da das Board die Quelle der Wahrheit ist, ist der Agent zwischen Läufen zustandslos. Stürzt der Orchestrator ab, kann er nach dem Neustart das Board erneut lesen und exakt rekonstruieren, was gerade passieren sollte. Dieselbe Eigenschaft macht eine Job-Queue robust, hier auf Coding-Agenten angewandt.
Warum Elixir und BEAM
Die Referenzimplementierung in Elixir ist für eine OpenAI-Veröffentlichung ungewöhnlich. Sie ist auch die richtige Wahl für dieses Problem.
Supervisor-Bäume passen zum Agent-Lebenszyklus
BEAM/OTP liefert das Supervisor-Muster ab Werk: Jeder Coding-Agent läuft als Kindprozess unter einem Supervisor, und ein Crash (out of memory, API-Timeout, unerwarteter Fehler mitten im Lauf) wird abgefangen, der Agent mit sauberem Zustand neu gestartet. Genau das braucht ein langlaufender Orchestrator, und genau dort scheitern die meisten Python-Frameworks.
Concurrency ist billig
BEAM-Prozesse sind günstig. Jedes Ticket kann seinen eigenen Prozess samt Mailbox bekommen, ohne dass die Maschine zuckt. Damit wird das Versprechen "jedes offene Ticket bekommt einen Agenten" bezahlbar statt nur erstrebenswert.
Die Spec wurde durch Portierung gehärtet
OpenAI ließ Codex selbst die Spec in TypeScript, Go, Rust, Java und Python implementieren. Jede Mehrdeutigkeit, die dabei auffiel, wurde in SPEC.md zurückgespielt. Das Ergebnis ist ein strafferes, weniger sprachgebundenes Dokument, als man es von Single-Implementation-Specs gewohnt ist.
Die Agent-Schleife auf einer Seite
Innerhalb eines Agent-Prozesses fährt Symphony eine klar geführte Schleife. Sie ist kurz genug, um sie in fünf Schritten aufzuschreiben:
- 1Ticket übernehmen und einen isolierten Workspace dafür klonen.
- 2Codex einen Plan vorschlagen lassen, ihn ausführen, Tests laufen lassen und iterieren, bis sie grün sind oder ein Budget aufgebraucht ist.
- 3Einen Draft-PR öffnen, Commits pushen und das Diff zurück an das Linear-Ticket posten.
- 4Ticket auf Review setzen und auf menschliches Feedback warten.
- 5Review-Kommentare per Codex einarbeiten, Tests erneut laufen lassen und entweder ausliefern oder eskalieren.
Die Schleife ist absichtlich langweilig. Der Engineering-Aufwand in Symphony steckt in den Rändern: Retries, Back-off, Timeouts, Isolation und der Supervisor, der Agenten bei Problemen neu startet. Genau dort scheitern Chat-artige Agenten in Produktion typischerweise.
Wodurch sich das von einem Chat-First-Agenten unterscheidet
Der Kontrast lohnt sich, weil er erklärt, warum Symphony überhaupt funktioniert.
- Chat-First-Agenten setzen voraus, dass jemand zuschaut. Der Mensch liefert Kontext, korrigiert bei Hängern und entscheidet, wann etwas fertig ist.
- Symphony-Agenten nehmen an, dass der Mensch woanders beschäftigt ist. Das Ticket trägt den Kontext, die Test-Suite trägt die Fertig-Bedingung, der Reviewer wird nur dann gerufen, wenn es etwas zu reviewen gibt.
Es ist derselbe Sprung, den wir in der Orchestrierungs-Ära des agentischen Codings beschrieben haben. Symphony ist die sauberste offene Spec, die diese These end-to-end belegt. Sie passt natürlich zu Router-Designs wie in dem Sakana-Conductor-Leitfaden für Multi-Agenten-Orchestrierung: Symphony entscheidet, an welchem Ticket gearbeitet wird, ein Router entscheidet, welcher Worker welche Teilaufgabe übernimmt.
Wo es sich auszahlt – und wo nicht
Es zahlt sich aus, wenn
- Ihr Team Linear-Tickets bereits so detailliert schreibt, dass ein Agent darauf handeln kann. Schwammige Tickets bleiben schwammig.
- Sie eine vernünftige Test-Suite haben. Ohne sie hat der Agent kein Signal, wann die Arbeit fertig ist.
- Sie viele kleine, ähnliche PRs ausliefern (Renames, Dependency-Updates, Copy-Edits, klar abgegrenzte Bugfixes).
Es zahlt sich nicht aus, wenn
- Der Wert Ihres Engineerings vor allem in Design-Gesprächen und Architektur-Entscheidungen liegt, nicht in PRs.
- Die Testabdeckung schwach ist und Mergen ohne Review riskant bleibt, egal wer den Diff geschrieben hat.
- Sie die Review-Last nicht stemmen können: Ein autonomer Agent produziert PRs schneller, als ein kleines Team sie lesen kann.
Versteckte Kosten: Review-Bandbreite
So probieren Sie es ohne großes Risiko aus
- 1Lesen Sie SPEC.md komplett. Sie ist absichtlich kurz.
- 2Stellen Sie die Elixir-Referenzimplementierung gegen ein Sandbox-Linear-Projekt und ein einzelnes unkritisches Repo bereit.
- 3Wählen Sie einen Tickettyp mit hohem Volumen und guter Testabdeckung (Dependency-Updates eignen sich gut). Lassen Sie Symphony ihn fahren.
- 4Messen Sie zwei Dinge: Time-to-PR und Review-Stunden. Bewegen sich beide zu Ihren Gunsten, erweitern Sie die Tickettypen einzeln.
- 5Erst danach sollten Sie die Spec in Ihre Stack-Sprache portieren. Die Elixir-Variante zu forken, reicht für viele Teams.
Falls Sie das breitere Bild der Coding-Agenten noch sortieren, erklärt unser OpenClaw-101-Leitfaden für Einsteiger die Bausteine (Tools, Skills, Berechtigungen, Speicher), die eine Schicht unter Symphony liegen.
Fazit
Symphony ist klein im Code und groß in den Folgen. Indem Linear zur Zustandsmaschine, Codex zum Worker und ein BEAM-Supervisor zum Sicherheitsnetz wird, zeigt OpenAI, dass Orchestrierung, nicht Prompts, der Teil des Agent-Engineerings ist, der wirklich skaliert. Ob Sie genau diese Spec übernehmen oder nicht: Das Design ist es wert, kopiert zu werden – ein Board, dem Sie ohnehin vertrauen, ein Agent, den Sie neu starten können, und ein Review-Schritt, der in menschlichen Händen bleibt. Das ist der Weg vom cleveren Demo zum Coding-Agenten, auf den sich Ihr Team verlassen kann.