Eine Orchestrierung ausführen

Diese Anleitung zeigt, wie du aus einem großen Ziel einen Plan für das ganze Team machst, der von selbst läuft. Wie das funktioniert, steht unter Orchestrierung.

Wann du eine Orchestrierung nutzt

Nimm eine Orchestrierung, wenn die Bitte größer ist als ein Agent und du die genauen Schritte noch nicht kennst. Für eine einzelne Aufgabe schreibst du einem Agenten in einem Bereich; für einen Ablauf, den du von Hand festhalten kannst, baust du eine Pipeline-Vorlage.

Schritt 1: Den Plan anfordern

Öffne (oder lege an) einen Bereich und ein Anker-Ticket. Jeder Vorschlag braucht eins (propose_orchestration verlangt ticket_id); der gemeinsame Bereich ergibt sich aus diesem Ticket.
Stell das Modus-Dropdown im Composer optional auf Orchestrate. Dieser Modus beschränkt den Agenten auf Lesen und Vorschlagen — Gedächtnis, den Code-Graph, Lesezugriffe auf Repo und Tickets, propose_orchestration und die Playbook-Werkzeuge —, damit er nicht anfängt, Code zu schreiben, statt zu planen.
Erwähne deinen Orchestrator mit @ (meist der CEO-Agent) und nenne das Ziel in klaren Worten:

@ceo Recherchiere das Wettbewerbsumfeld für einen offline-first Meeting-Recorder und schreib ein einseitiges Positionierungspapier.

Der Orchestrator antwortet im Bereich mit einer strukturierten Vorschlagskarte: die Rollen, die er braucht, die Arbeit aufgeteilt in untergeordnete Tickets, eine optionale Recherche- und Diskussionsphase, einen Syntheseschritt, der das Lieferergebnis erzeugt, und ein Budget.

Weil der Vorschlag ein typisiertes Objekt ist, prüft die App ihn, bevor irgendetwas läuft: wohlgeformte Rollen, deklarierte Ausgabeschemata, ein DAG ohne Zyklen. Ein Vorschlag, der die Prüfung nicht besteht, lässt sich nicht freigeben.

Schritt 2: Den Vorschlag prüfen und bearbeiten

Die Karte im Gespräch bietet drei Aktionen: Plan genehmigen, Ablehnen und Öffnen — das öffnet den Plan in Plan Studio als Editor-Tab. Die Karte selbst lässt sich nicht bearbeiten.

Um etwas zu ändern, drücke Öffnen und arbeite im Knoteninspektor rechts:

Titel, Beschreibung, Rolle, Hängt ab von und Ausgabeschema (JSON) jedes Arbeitsschritts. Rolle meint hier, welcher der vorhandenen Rollenschlüssel des Plans den Schritt besitzt — eine Rolle lässt sich im Inspektor nicht an einen namentlich genannten Agenten binden, die Einstellungsliste lässt sich dort nicht bearbeiten, und das Budget auch nicht.

Zwei Dinge sind schreibgeschützt: Strukturknoten (Recherche, Diskussion, Synthese) und jeder Knoten, dessen Arbeit schon gelaufen ist. Bearbeiten geht nur, solange die Orchestrierung noch proposed ist.

Drücke Schätzen in der Freigabeleiste, um vor der Festlegung Bereiche für Kosten, Dauer und Wirkungsradius zu sehen. Den ganzen Editor beschreibt In Plan Studio arbeiten.

Schritt 3: Freigeben

Gib den Plan frei, von der Karte im Gespräch oder von der Freigabeleiste in Plan Studio. Das ist die einzige Entscheidung, die du triffst. Die Freigabe ist Menschen vorbehalten — ein MCP-Tool dafür gibt es nicht, ein Agent kann also vorschlagen und überarbeiten, seinen eigenen Plan aber nie freigeben.

Ab hier wandelt ein deterministischer Materialisierer (eine reine Funktion, kein LLM) den Vorschlag in eine echte Pipeline um und legt das Gerüst an:

stellt neue Rollen ein (und speichert die IDs der eingestellten Agenten, damit ein Absturz mitten in der Freigabe ohne doppelte Einstellungen weiterlaufen kann)
bündelt die Rollen zu einem Team
legt ein Projekt an und ordnet das übergeordnete Ticket darunter ein
startet den Pipeline-Lauf, der alles antreibt

Der Status wechselt auf approved, dann auf executing.

Schritt 4: Den Lauf beobachten

Die untergeordneten Tickets laufen als Pipeline-Schritte; hast du eine Diskussionsrunde eingeschaltet, schreibt jede Rolle zuerst eine Position. Der Fortschritt erscheint dort, wo du schon hinsiehst:

dem übergeordneten Ticket, an dem die Orchestrierung hängt
dem gemeinsamen Bereich, in dem das Team spricht und die Planzeile den Zustand jedes Knotens führt
der Detailansicht des Pipeline-Laufs, mit dem gewohnten Wasserfall und den Kosten je Schritt — siehe Pipeline-Läufe überwachen
dem Projekt, unter dem das übergeordnete Ticket liegt

Sind die untergeordneten Tickets fertig, wechselt der Status auf synthesizing, und der Syntheseschritt erzeugt das Lieferergebnis. Dieser Text erscheint im gemeinsamen Bereich, das übergeordnete Ticket wird abgeschlossen, danach completed.

Vorzeitig stoppen

Drücke Orchestrierung abbrechen auf der Karte im Gespräch oder Lauf abbrechen in der Freigabeleiste von Plan Studio. Der Abbruch räumt die noch laufende Arbeit ab.

Eine Orchestrierung schlägt fehl, wenn die Materialisierung scheitert oder wenn der Lauf der erzeugten Pipeline scheitert (Recherche, Diskussion, Synthese oder Persistieren — diese Schritte laufen bei Fehler nicht weiter). Erzeugte Schritte vom Typ Arbeit laufen bei Fehler immer weiter, ein fehlgeschlagenes untergeordnetes Ticket lässt den Lauf also nicht scheitern. Es gibt keinen Fehlschlag wegen überschrittenem Budget und keine Schwelle „jedes untergeordnete Ticket fehlgeschlagen“.