Orchestrierung

Ein einzelner Agent kann eine Sache gut. Manche Aufträge sind größer: „recherchiere den Markt für X und schreib ein Positionierungspapier“, „liefere dieses Feature von Anfang bis Ende aus“, „prüfe dieses Modul und behebe, was du findest“. Eine Orchestrierung ist der Weg von Control Center für genau das. Ein Orchestrator, meist dein CEO-Agent, schlägt einen Plan für das ganze Team vor, du gibst ihn einmal frei, und eine deterministische Materialisierung macht daraus eine Pipeline, die die Arbeit erledigt.

Sie steht zwischen den zwei Wegen, auf denen du Arbeit schon erledigen kannst:

Wenn du willst …	Nimm
Eine Aufgabe an einen Agenten geben	Eine Nachricht in einem Bereich
Einen Ablauf, den du schon kennst, von Hand festhalten	Eine Pipeline-Vorlage
Das Ziel nennen und das Team den Plan finden lassen	Eine Orchestrierung

Aufbau eines Vorschlags

Gibst du dem Orchestrator ein Ziel, liefert er einen strukturierten OrchestrationProposal: einen typisierten Plan, den die App prüfen und ausführen kann, statt freier Prosa. Ein Vorschlag enthält:

Ziel: deine Bitte auf hoher Ebene, neu formuliert.
Rollen: wer die Arbeit macht. Jede Rolle ist entweder ein bestehender Agent, den du wählst, oder eine Neueinstellung, die die Orchestrierung bei der Freigabe anlegt.
Untergeordnete Tickets: die Arbeit, aufgeteilt in einen DAG aus Tickets.
Recherche (optional): eine Recherchephase, die zuerst läuft und den Rest speist.
Diskussion (optional): eine begrenzte Runde, in der jede Rolle vor Beginn der Arbeit eine strukturierte Position schreibt.
Synthese: der letzte Schritt, der das Lieferergebnis erzeugt.
Budget: ein erklärter Kostendeckel.

Wo du ihn prüfst

Zwei Oberflächen zeigen dieselbe Orchestrierung.

Die Vorschlagskarte steht in dem Gespräch, das den Plan erzeugt hat. Es ist eine Nachricht, die sich über den ganzen Lebenszyklus neu zeichnet — vorgeschlagen, in Ausführung, abgeschlossen — mit den Aktionen zum Freigeben und Abbrechen darauf.

Plan Studio ist der Editor: eine DAG-Leinwand, ein Knoteninspektor, eine Schublade für Revision und Diff und die Freigabeleiste mit der Schätzung. Er öffnet sich direkt von dieser Karte als Editor-Tab. In der Seitenleiste gibt es absichtlich keinen Eintrag „Pläne“; /plans und /plans/:kind/:id gibt es als Direktlinks zum Teilen.

Die Freigabe ist Menschen vorbehalten. Ein MCP-Tool dafür gibt es nicht. Ein Agent kann vorschlagen (propose_orchestration), einen Plan einreichen (submit_plan) oder ein Playbook instanziieren (run_playbook); freigeben kann nur ein Mensch. Von Agenten angestoßene Revisionen sind zusätzlich auf eine Abklingzeit von zwei Minuten begrenzt, damit eine Neuplanungsschleife sich bündelt, statt den Verlauf zu fluten.

Was du vor der Freigabe ändern kannst, ist das, was der Knoteninspektor hergibt: ein untergeordnetes Ticket umbenennen oder neu schreiben, wechseln, welche Rolle es besitzt, seine Abhängigkeiten neu setzen, sein Ausgabeschema bearbeiten oder den Knoten ganz löschen. Strukturknoten (Recherche, Diskussion, Synthese) und Knoten, die schon ausgeführt wurden, sind schreibgeschützt. Eine Rolle lässt sich vom Editor aus nicht an einen bestimmten, namentlich genannten Agenten binden, und das Budget lässt sich dort nicht ändern.

Zwei Editoren an einem Plan löst optimistische Nebenläufigkeit. Jede Bearbeitung trägt die base_revision, gegen die sie entstanden ist. Basiert sie auf einer veralteten Revision, wird sie mit „the plan moved on“ abgelehnt. Die Änderung eines anderen wird dabei nicht still überschrieben. Zurückspulen löscht nichts: Es hängt den älteren Vorschlag als neue Revision an, und die Revisionszeitleiste wächst nur.

Ehrliche Schätzungen oder keine

Die Schätzung in der Freigabeleiste entsteht aus der echten Historie abgeschlossener Läufe jeder Rolle, als Interquartilband (p25–p75). Die Kostensummen addieren die schätzbaren Knoten; die Dauer ist der kritische Pfad durch den DAG, denn parallele Zweige überlappen sich.

Ein Knoten, dessen Rolle keine Historie abgeschlossener Läufe hat, meldet sampleSize: 0 und Null-Bereiche. Das erscheint genau so, als unbekannt, und nie als erfundener Punktwert. Eine Schätzung, der du nicht trauen kannst, ist schlechter als gar keine. Haben manche Knoten Historie und andere nicht, ist die Summe als „teilweise“ markiert. Der Wirkungsradius erscheint nur, wenn ein Knoten Herkunftsverweise symbol oder file erklärt hat; ohne sie bleibt er „unbekannt“. Aus dem Fließtext wird nichts abgeleitet.

Eine Freigabe, danach deterministische Ausführung

Der Kern ist: Der Agent plant; eine deterministische Funktion führt aus. Wenn du freigibst, wandelt der OrchestrationMaterializer, eine reine Funktion ohne LLM und ohne I/O, den Vorschlag in eine echte Pipeline um. Bei demselben Vorschlag und denselben aufgelösten Rollen entsteht immer derselbe DAG. Darauf kommt es an, weil die erzeugte Pipeline alles mitbekommt, was die Engine schon kann: Anhalten und Fortsetzen über Neustarts, die Wiederherstellung nach einem Absturz, Kosten- und Token-Summen je Lauf und die Laufdetailansicht.

Die Freigabe legt auch das Gerüst an, das die Arbeit braucht:

stellt jede als neu markierte Rolle ein (und speichert die IDs der eingestellten Agenten, damit ein Absturz mitten in der Freigabe ohne doppelte Einstellungen weiterlaufen kann)
ein Team, das die Rollen bündelt
ein Projekt, unter dem das übergeordnete Ticket liegt
die Pipeline-Vorlage samt Lauf, die alles antreibt

Der Lebenszyklus

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

Status	Bedeutung
`proposed`	Der Plan ist fertig und wartet auf deine eine Freigabe im Voraus
`approved`	Du hast freigegeben; die Materialisierung läuft (Einstellungen, Team, Projekt, Pipeline)
`executing`	Die erzeugte Pipeline läuft: untergeordnete Tickets, Diskussion, Arbeit
`synthesizing`	Die untergeordneten Tickets sind fertig; der Syntheseschritt erzeugt das Lieferergebnis
`completed`	Fertig: Das übergeordnete Ticket ist abgeschlossen, und das Lieferergebnis steht im gemeinsamen Bereich
`failed`	Die Materialisierung ist gescheitert, oder der Lauf der erzeugten Pipeline ist gescheitert
`cancelled`	Du hast abgebrochen

Eine monotone Revisionsnummer begleitet den Vorschlag, solange der Orchestrator ihn im Status proposed überarbeitet. Die App merkt sich, welche Revision du freigegeben hast. propose_orchestration lehnt eine Revision ab, sobald der Status nicht mehr proposed ist.

Eine Orchestrierung hängt immer an einem übergeordneten Ticket und teilt sich einen Diskussions-Bereich. Der ganze Aufwand bleibt an einem Arbeitselement hängen, und das Team spricht in einem Bereich.

Was am Ende geschieht

Ein Listener, der am Leben gehalten wird, beobachtet die erzeugte Pipeline und schreibt ihren Endzustand auf die Orchestrierung und das übergeordnete Ticket zurück. Abschluss und Fehlschlag tauchen so dort auf, wo du schon hinsiehst. Die Orchestrierung braucht keine eigene Ausführungs-Engine.

Eine Orchestrierung kannst du jederzeit abbrechen. Der Abbruch räumt die noch laufende Arbeit ab.

Siehe auch

Pipelines und Automatisierung: die Engine, auf der eine materialisierte Orchestrierung läuft
Tickets und Delegation: das übergeordnete Ticket, an dem eine Orchestrierung hängt
Das Agentenmodell: die Rollen, die eine Orchestrierung besetzt oder einstellt
Eine Orchestrierung ausführen
In Plan Studio arbeiten