Symphony: eine Spezifikation, um Tickets in autonome Code-Läufe zu verwandeln

Alles Wissenswerte über openai/symphony: eine offene Spezifikation und eine Referenzimplementierung, um Arbeit von einem Board zu lesen, jede Aufgabe in einem Arbeitsbereich zu isolieren und Programmier-Agenten ohne fortlaufende interaktive Aufsicht zu betreiben.

Was Symphony ist

Symphony ist eine Dienstspezifikation zur Orchestrierung von Programmier-Agenten. Sie liest kontinuierlich Arbeit aus einem Issue-Tracker — Linear in der ersten Version der Spezifikation —, erstellt einen isolierten Arbeitsbereich pro Aufgabe und führt dort eine Code-Agenten-Sitzung aus.

Das Repository von OpenAI sollte nicht mit einem generischen Multi-Agenten-Framework oder einem fertigen SaaS-Produkt verwechselt werden. Das Herzstück ist SPEC.md, eine sprachunabhängige Draft-v1-Spezifikation; zudem enthält es eine experimentelle Referenzimplementierung in Elixir. OpenAI beschreibt sie als zurückhaltende “Engineering-Vorschau”, die für vertrauenswürdige Umgebungen gedacht ist.

Ihr Ziel ist es, die Kontrollebene zu verändern: Statt einzelne Codex-Sitzungen zu beaufsichtigen, verwaltet ein Team Tickets, Review-Zustände und Abnahmekriterien. Ein erfolgreicher Lauf kann in einem vom Workflow definierten Zustand enden — zum Beispiel Human Review — und muss die Arbeit nicht zwingend zusammenführen oder abschließen.

Der Ursprung: von Harness Engineering zur Arbeitsverwaltung

OpenAI kündigte Symphony am 27. April 2026 an. Der Launch-Artikel stellt es als den Schritt nach dem Harness Engineering dar: Sobald ein Repository über Tests, Dokumentation, Werkzeuge und für einen Agenten geeignete Guardrails verfügt, verschiebt sich der Engpass auf die Koordination vieler Aufgaben, ohne ständig zwischen Sitzungen zu wechseln.

Das Team erklärt, dass es diesen Stil zunächst für ein internes Projekt verwendete, das vollständig mit von Codex generiertem Code entwickelt wurde. Symphony verwandelt das Projekt-Board — im Beispiel Linear — in eine Steuerungsebene, damit ein Agent Tickets aufnehmen, Änderungen erstellen, CI verfolgen, Review-Kommentare bearbeiten und Belege für die menschliche Überprüfung hinterlassen kann.

Das Projekt ist offiziell von OpenAI und wird unter der Apache-2.0-Lizenz veröffentlicht. Das README zeigt zum Zeitpunkt der abgerufenen Abfrage rund 24.700 Sterne, 2.400 Forks und 167 Abonnenten; das sind sich ändernde GitHub-Zahlen, kein Maß für die Produktionsadoption.

Philosophie und Prinzipien

Das Ticket ist die Arbeitseinheit. Symphony entscheidet über Eignung, Zuweisung, Wiederholungen und Wiederherstellung anhand des Tracker-Zustands, nicht anhand manuell geöffneter Sitzungen.

Ein Arbeitsbereich pro Aufgabe. Die Befehle des Agenten sind auf das zugehörige Arbeitsverzeichnis beschränkt; der Bereich bleibt zwischen Läufen erhalten und wird bereinigt, wenn die Aufgabe einen Endzustand erreicht.

Richtlinie versioniert zusammen mit dem Code. WORKFLOW.md enthält den Prompt und die Laufzeitkonfiguration, sodass jedes Team Ticket-Regeln, Validierung und Auslieferung innerhalb seines eigenen Repositorys versionieren kann.

Orchestrierung, nicht Mikromanagement. Der Dienst plant und beobachtet; der Agent führt über seine eigenen Werkzeuge meist Kommentare, PR-Links und Ticket-Übergänge aus.

Projekt-Guardrails vor Autonomie. OpenAI vertritt die Ansicht, dass das Muster am besten funktioniert, wenn das Repository bereits über solide Tests, Dokumentation und automatisierte Kontrollen verfügt.

Wie es funktioniert

Die Spezifikation teilt das System in Schichten. Workflow Loader liest WORKFLOW.md; die Konfigurationsschicht validiert Werte und Umgebungsreferenzen; der Tracker-Adapter normalisiert Aufgaben; der Orchestrator steuert Polling, Nebenläufigkeit, Wiederholungen und Abgleich; der Workspace-Manager bereitet das Verzeichnis pro Ticket vor; und der Agent kommuniziert über stdio mit einem Code-App-Server.

Linear / Issue-Tracker → Orchestrator → isolierter Arbeitsbereich pro Ticket
                                       → Code-Agent
                                       → CI, Review und Belege
                                       → in WORKFLOW.md definierter Auslieferungszustand

Der Dienst hält einen einzigen Orchestrierungszustand im Speicher, führt das Polling mit begrenzter Nebenläufigkeit aus, stoppt Jobs, die nicht mehr geeignet sind, und wendet bei vorübergehenden Fehlern exponentiellen Backoff an. Er muss zudem mindestens strukturierte Protokolle bieten, um mehrere gleichzeitige Läufe zu betreiben.

Hauptkomponenten

SPEC.md: ein portabler, sprachneutraler Verhaltensvertrag. Sie verwendet RFC-2119-Terminologie (MUST, SHOULD usw.) und macht die Entscheidungen explizit, die jede Implementierung treffen muss.
WORKFLOW.md: die eigene Richtlinie des Repositorys: YAML-Front-Matter für die Konfiguration und ein Prompt-Textkörper für Anweisungen, Validierungen und Auslieferungszustand.
Tracker-Adapter: in v1 liefert Linear die Quelle für Aufgaben, Zustände und Metadaten; die Spezifikation verlangt eine Normalisierung, bevor der Orchestrator handelt.
Workspace-Manager: erzeugt deterministische Pfade pro Aufgabe, wendet Lifecycle-Hooks an und bewahrt die Bereiche zwischen Läufen.
Agent Runner: baut den Prompt aus Ticket und Workflow, startet den Agenten-Client und gibt Aktualisierungen an den Orchestrator zurück.
Zustandsoberfläche: optional; kann ein Terminal, ein Panel oder eine andere menschliche Ansicht sein. Die Spezifikation schreibt keine umfangreiche UI vor.

Das Ökosystem

Symphony ist darauf ausgelegt, mit dem App-Server von Codex zu arbeiten, wobei SPEC.md vermeidet, dessen Details in ein festes Protokoll zu verwandeln, und stattdessen verlangt, die generierte oder aktuelle Dokumentation dieses Servers zu konsultieren.

Das Repository bietet zwei Wege: eine eigene Implementierung in der bevorzugten Sprache anhand der Spezifikation zu bauen, oder die experimentelle Elixir-Referenz auszuprobieren. Diese Trennung ist wichtig: Die Spezifikation ist das primäre Gut; die Referenz sollte nicht als fertige, universelle Lösung behandelt werden.

Die Community hat bereits Interpretationen geschaffen. broomva/symphony präsentiert sich als Rust-Implementierung, die Linear, GitHub oder Markdown abfragt und Agenten in Arbeitsbereiche pro Ticket entsendet; es handelt sich um ein unabhängiges, von OpenAIs Spezifikation inspiriertes Projekt, keine von OpenAI gepflegte Software. Auch Contrabass tauchte auf, eine weitere Go-Implementierung, die auf Hacker News gezeigt wurde.

Schnelleinstieg

Vorbereitung

Das README empfiehlt, zunächst Praktiken des Harness Engineering zu übernehmen: nützliche automatisierte Tests, aktuelle Dokumentation, Werkzeuge zur Inspektion von CI und klare Regeln dafür, wie eine Änderung akzeptiert wird.

Danach gibt es zwei Optionen:

Einen Programmier-Agenten bitten, Symphony gemäß SPEC.md in der gewählten Sprache zu implementieren.
Die Referenzimplementierung verwenden und elixir/README.md folgen, um die Umgebung vorzubereiten und das Binary mit einer projekteigenen WORKFLOW.md auszuführen.

Typischer Ablauf

WORKFLOW.md mit geeigneten Zuständen, Regeln, Validierungen, Werkzeugen und dem Punkt der menschlichen Übergabe verfassen.
Linear und Host-Zugangsdaten für Tracker und Agenten verbinden.
Den Dienst starten, damit er Aufgaben im definierten Rhythmus abfragt und separate Arbeitsbereiche reserviert.
Den Agenten implementieren, Tests ausführen, den PR erstellen oder aktualisieren und Kommentare gemäß der Repository-Richtlinie verarbeiten lassen.
Das Belegpaket überprüfen und aus dem gewählten Workflow akzeptieren, korrigieren oder abbrechen.

Häufige Fallstricke und Lösungen

Mit mehrdeutigen Tickets beginnen. OpenAI räumt ein, dass nicht jede Aufgabe passt: Probleme mit starker Ermessensentscheidung oder unklarer Definition benötigen weiterhin interaktive Engineering-Sitzungen.
Annehmen, dass Arbeitsbereichsisolation einer vollständigen Sandbox entspricht. Die Spezifikation isoliert Verzeichnisse pro Aufgabe, verlangt aber keine starken Sandbox-Kontrollen über den Agenten und das Host-Betriebssystem hinaus.
Die Richtlinie außerhalb des Repositorys belassen. Der Zweck von WORKFLOW.md besteht darin, dass sich Regeln, Prompt und Konfiguration zusammen mit dem Code weiterentwickeln. Zwei Kopien können Verwirrung über die Quelle der Wahrheit stiften; es gibt eine spezifische Diskussion zu diesem Punkt.
Automatisch mergen ohne Auslieferungsstufe. Symphony erlaubt es, dass Erfolg in menschlicher Überprüfung endet; jedes Team muss festlegen, welche Kontrollen einen Merge ermöglichen.
Tracker-Zugangsdaten als Nebensächlichkeit behandeln. Der Agent kann Tickets über native Werkzeuge bearbeiten; Geheimnisse sollten über Host-Referenzen bereitgestellt und auf das notwendige Minimum beschränkt werden.

Sicherheit und Vertrauensmodell

Die Spezifikation verlangt, dass jede Implementierung ihre Vertrauens- und Sicherheitshaltung dokumentiert, schreibt aber keine einheitliche Genehmigungs-, Sandbox- oder Betreiberrichtlinie vor. Sie erkennt ausdrücklich an, dass manche Implementierungen auf vertrauenswürdige Umgebungen abzielen, während andere strengere Kontrollen erfordern.

Symphony ist konzeptionell ein Planer/Runner und Ticket-Leser. Tracker-Schreibvorgänge — Übergänge, Kommentare und PR-Links — werden meist von den nativen Werkzeugen des Agenten ausgeführt. Wenn Zugangsdaten über Host-Geheimnisreferenzen übergeben werden, benötigt der Kindprozess des Agenten keine zweite direkte Authentifizierung beim Tracker.

Die sichere Praxis besteht daher darin, Umgebungen zu trennen, Zugangsdaten zu begrenzen, CI und menschliche Überprüfung vor Endzuständen zu verlangen und keinen autonomen Ablauf über nicht vertrauenswürdige Repositories oder Boards zu aktivieren. Diese Kontrollen sind mit der Spezifikation und dem Preview-Hinweis konsistent; sie ersetzen keine Sicherheitszertifizierung von OpenAI.

Wie die Community reagierte

Die sichtbare Resonanz kombiniert technisches Interesse und Vorsicht. Auf Reddit erhielt die Ankündigung in r/OpenAI 44 Upvotes, und ein Kommentar charakterisierte es eher als Projektmanagement denn als “Orchestrierung”; das ist eine individuelle Meinung, beschreibt aber gut den operativen Ebenenwechsel, den das Projekt anstrebt.

Eine Autorin bzw. ein Autor veröffentlichte eine auf der Spezifikation basierende Rust-Implementierung und gab an, 24 Tickets über den Zyklus Implementierung, PR, automatisierte Überprüfung und menschliche Genehmigung verarbeitet zu haben. Es ist ein nicht auditierter persönlicher Bericht, keine offizielle Symphony-Metrik.

Die GitHub-Diskussionen umfassen abgeleitete Implementierungen, Werkzeuge, die WORKFLOW.md erzeugen, und Sicherheitsbefunde für die Elixir-Referenz. Sie belegen, dass Experimente mit der Spezifikation existieren, nicht dass diese Lösungen von OpenAI bewertet oder genehmigt wurden.

Symphony im Vergleich zu anderen Ansätzen

Ansatz	Überprüfbare Überschneidung	Überprüfbarer Unterschied
Eine interaktive Codex-Sitzung	Beide nutzen einen Programmier-Agenten, um ein Repository zu ändern.	Symphony holt Arbeit aus einem Tracker, plant persistente Läufe und bewahrt eine versionierte Auslieferungsrichtlinie.
Traditionelle CI-Automatisierung	Beide reagieren auf Zustände und führen wiederholbare Prozesse aus.	Symphony weist einem Agenten eine Aufgabe und einen Arbeitsbereich zu und erlaubt ihm, innerhalb einer Repository-Richtlinie zu argumentieren und Werkzeuge zu nutzen.
`broomva/symphony`	Implementiert das Muster aus Ticket, isoliertem Arbeitsbereich und Agentensitzung.	Es ist eine Community-Rust-Implementierung, die die erklärten Arbeitsursprünge erweitert; sie ist nicht die Referenz von OpenAI.
Contrabass	Stützt sich auf die Spezifikation und nutzt Agentenorchestrierung für Engineering-Aufgaben.	Es ist ein Drittanbieter-Go/Charm-Stack-Projekt, präsentiert als Show HN.

Anwendungsfälle und wem dieses Repository helfen kann

Teams mit gut definierten Boards, die Aufgaben mit niedrigem oder mittlerem Risiko in überprüfbare Änderungsvorschläge verwandeln möchten.
Repositories mit gutem Harness — Tests, CI, Konventionen und Dokumentation —, die dem Agenten objektive Erfolgssignale geben können.
Teams, die unter Kontextwechseln leiden, während sie mehrere Agentensitzungen koordinieren, und die Warteschlange, Zustände und Ergebnisse lieber selbst steuern.
Entwicklerinnen und Entwickler interner Plattformen, die das Muster in einer anderen Sprache oder einem anderen Tracker implementieren möchten und die Spezifikation als Vertrag nutzen.

Es ist keine generische Lösung für jeden Backlog: mehrdeutige, risikoreiche oder kontinuierlich fachkundiges Urteilsvermögen erfordernde Aufgaben benötigen weiterhin direkte menschliche Führung.

Ressourcen

Repository: https://github.com/openai/symphony
Spezifikation: https://github.com/openai/symphony/blob/main/SPEC.md
Elixir-Implementierung: https://github.com/openai/symphony/tree/main/elixir
OpenAI-Ankündigung: https://openai.com/index/open-source-codex-orchestration-symphony/
Diskussionen: https://github.com/openai/symphony/discussions
Community-Rust-Implementierung: https://github.com/broomva/symphony

Hinweis: Dieser Artikel wurde aus der Spezifikation, dem Repository, der offiziellen Ankündigung und öffentlichen Gesprächen zusammengestellt, abgerufen am 17. August 2026. Symphony erklärt sich selbst als Draft v1 und experimentelle Vorschau; Details können sich ändern.