Modi

Was ein Modus ist

Ein Modus ist eine Eigenschaft eines Bereichs, gespeichert als eine Spalte der Bereichszeile. Jedes Gespräch in einem Bereich teilt ihn, Threads eingeschlossen: Ein Thread erbt den Modus seines Bereichs wie jedes andere Gespräch. Derselbe Agent kann deshalb in verschiedenen Bereichen gleichzeitig in verschiedenen Modi sein. Wechselst du den Modus eines Bereichs, ändert das den nächsten Zug, ohne den Agenten anzufassen.

Es gibt genau vier: chat, review, plan, orchestrate. Das Enum selbst trägt keine Richtlinie. Was ein Modus zusichert, steht einmal in einem Fähigkeitsprofil, und jede Durchsetzungsschicht projiziert daraus:

Werkzeugfläche — welche Werkzeuge in diesem Modus überhaupt existieren, ausgedrückt als maximale Freigabestufe, eine Zulassungsliste, eine Sperrliste und eine Menge abgelehnter Effektklassen.
Erforderliches Ausgabe-Verb — was der Lauf aufrufen muss, um überhaupt etwas geliefert zu haben.
Abgelehnte Effektklassen — was die Schutzregeln für Aktionen rundweg verweigern.
Worktree-Lage — ob in den Worktree geschrieben werden darf. Durchgesetzt wird das, indem die verändernden Werkzeuge aus der Fläche genommen werden. Genau das gilt auf jedem Host. Hat der Host eine OS-Sandbox, schneidet dieselbe Lage zusätzlich die Schreibregeln des Dateisystems: Ein Nur-Lese-Modus hängt den Worktree schreibgeschützt ein. Das ist eine zweite Ausfertigung der Zusicherung. Die Arbeit leistet das Entfernen der Werkzeuge.
System-Prompt-Block — ein erzeugter Fähigkeitsvorspann aus der tatsächlich materialisierten Werkzeugliste, dazu von Hand geschriebene Hinweise.

Jede Durchsetzungsschicht projiziert aus diesem einen Profil. Werkzeugfläche, Schutzregeln, Worktree-Lage und Prompt können deshalb nicht voneinander abweichen.

Die vier Modi

Chat – angezeigt als „Agent“

Der Vorgabemodus und der einzige ohne zusätzliche Einschränkungen: die volle Werkzeugfläche bis zur Ausführungsstufe, ein beschreibbarer Worktree, keine abgelehnten Effektklassen und kein Abschlussvertrag. Nimm ihn für Implementierung, Fehlerbehebungen, Fragen an die Codebasis und jede einmalige Aufgabe.

Zur Bezeichnung: Im Composer erscheint der Modus als „Agent“, nicht als „Chat“.

Plan – schreibgeschützt, ein Lieferergebnis

Der Plan-Modus macht den Worktree schreibgeschützt und nimmt die Schreibwerkzeuge vollständig aus der Fläche. Die Einschränkung ist damit strukturell und nicht bloß eine Anweisung. Der Agent liest, sucht und recherchiert und liefert genau eines: einen submit_plan-Aufruf, der einen typisierten Abhängigkeitsgraphen trägt, ein Ziel plus Knoten mit Schlüsseln, Titeln, Beschreibungen und den Knotenschlüsseln, von denen jeder abhängt.

Der Plan erscheint als kompakte Zeile im Gespräch und öffnet Plan Studio in einem Tab daneben. Die Freigabe kompiliert den Graphen zu einer Orchestrierung, führt die erzeugte Arbeit aus und schaltet den Bereich, in dem der Plan entstand, zurück auf den Agent-Modus.

Endet ein Lauf im Plan-Modus, ohne je submit_plan aufzurufen, schiebt die Schleife zuerst einen Hinweis ein: Der Plan existiert erst, wenn dieser Aufruf gelingt. Der Hinweis erlaubt ausdrücklich den ehrlichen Ausstieg „hier ist kein Plan nötig“, denn der Plan-Modus ist eine Einstellung des Bereichs, und eine schlichte Frage darin soll keinen Scheinplan erzwingen.

Es gibt einen zweiten, getrennten Ausgang: exit_plan_mode. Es ist ein hartes Freigabetor und kein Ausgabe-Verb. Ein Agent, der es statt submit_plan aufruft, hat nichts geliefert. Der erste Aufruf öffnet eine dauerhafte plan_exit-Freigabe, gibt pending zurück, und der Bereich bleibt schreibgeschützt. Weitere Aufrufe bleiben pending und öffnen kein zweites Tor. Erst nach erteilter Freigabe schaltet ein folgender Aufruf den Bereich auf Chat. Eine Ablehnung lässt den Agenten eine neue Anfrage für einen überarbeiteten Plan öffnen.

Den Plan-Modus verlässt du selbst über das Dropdown im Composer (oder Umschalt+Tab). Über exit_plan_mode wird mit dem MCP-Tool decide_approval entschieden. Zeilen „Agentenfreigabe“ im Posteingang sind etwas anderes: Bestätigungsfragen pro Zug von einem laufenden Agenten.

Review – schreibgeschützt, kein Vertrag

Der Review-Modus dient der PR-Prüfung. Er macht den Worktree schreibgeschützt, begrenzt die Werkzeugfläche auf unterhalb der Ausführungsstufe und setzt eine kuratierte Zulassungsliste aus Review-, Ticket- und Kommunikationswerkzeugen. Ein Bereich, der für einen Pull Request geöffnet wird, entsteht automatisch im Review-Modus.

Die Ausgabe des Agenten sind strukturierte Befunde, Review-Knoten, und, sobald ein Review abgeschlossen wird, ein Verdikt. Ein Knoten trägt eine Art (bug, suggestion, recommendation, question oder ticket), eine Priorität von P0 (blockiert die Veröffentlichung) bis P3 (wünschenswert), eine selbst eingeschätzte Konfidenz, einen optionalen Anker (Datei plus Zeilenbereich; Notizen über das ganze Repository haben keinen) und einen Lebenszyklusstatus, der von open zu consensusReady wechselt, sobald eine andere Person, nie der Autor, ihn bestätigt. Fehlt die Priorität oder die Konfidenz, oder liegt sie außerhalb des zulässigen Wertebereichs, wird der Befund an der Lesegrenze verworfen, bevor er das Verdikt verfälscht.

Das Verdikt ist Ship, Hold oder Block. Die Ergebnisse je Achse, die darin aufgehen, machen es nur strenger: Eine Achse mit Gate, die fehlschlägt, erzwingt block, und eine Achse mit Gate, die nicht laufen konnte, erzwingt mindestens hold. Fehlende Belege setzen ein Gate nie auf Grün.

Anders als Plan und Orchestrate trägt Review keinen Abschlussvertrag. Befunde sammeln sich über add_review_node und werden mit finalize_review veröffentlicht. Beide dürfen legitim kein einziges Mal aufgerufen werden: Ein Pipeline-Agent im Review-Modus kann dort sein, um stattdessen ein Ticket abzuschließen.

Orchestrate – schreibgeschützt, schlägt ein Team vor

Der Orchestrate-Modus macht aus einem Ziel einen Plan für das ganze Team. Wie der Plan-Modus ist er schreibgeschützt und kann keine Dateien schreiben. Über der Recherchefläche hat er ein einziges privilegiertes Verb, propose_orchestration, das einen strukturierten Vorschlag ausgibt: Rollen, einen Baum aus Untertickets, einen Syntheseschritt und ein Budget. Der Prompt nennt nur die Werkzeuge auf der Fläche. Das Modell verbringt deshalb keine Züge damit, Einstellungen oder Ticketarbeit zu erzählen, die es nicht aufrufen kann.

Nichts im Vorschlag läuft, bis du ihn freigibst. Bei der Freigabe stellt ein deterministischer Schritt die Agenten ein, legt die Tickets und ein Projekt an und startet eine erzeugte Pipeline. Freigeben bleibt Menschen vorbehalten. Dafür gibt es kein MCP-Tool, ein Agent kann also vorschlagen und seinen eigenen Plan nie freigeben. Erneute Vorschläge eines Agenten unterliegen einer Abklingzeit von zwei Minuten. Aufeinanderfolgende Neuplanungen werden abgelehnt, mit der Aufforderung, sie zu bündeln. Siehe Orchestrierung.

Zwei Regeln, die du kennen solltest

Das eigene Ausgabe-Verb eines Modus lässt sich nie verweigern. submit_plan und propose_orchestration sind in der Werkzeugfläche fest verankert und im Voraus freigegeben, am Werkzeugfilter, am Freigabetor und an den Schutzregeln für Aktionen vorbei. Der Autonomie-Regler des Bereichs kann das Lieferergebnis eines Modus also nicht zum Schweigen bringen. ask_user des Harness ist aus demselben Grund verankert. Genau so erreicht ein Lauf dich, und ein Tor davor würde einen Lauf verklemmen, der etwas fragen muss. Es liegt auf der Lesestufe, jeder Nur-Lese-Modus behält es also, und es ist vom Freigabe-Wrapper ausgenommen. Eine Rückfrage vor der Rückfrage wird abgelehnt, wenn niemand zum Freigeben verbunden ist, und nähme dem Agenten genau das Fragen.

Nur-Lese-Modi sperren weder den Netzwerkzugriff noch Geheimnisse. Die Effektklassen, die Review, Plan und Orchestrate ablehnen, sind die, die die Welt verändern: Dateien löschen, Schreiben außerhalb des Worktrees, Commits, Pushes, Pull Requests anlegen und veröffentlichen, Schreibzugriffe der Anbieter-Synchronisierung, Paketinstallationen, Prozesse starten, Änderungen am Arbeitsbereich und Kapselsteuerung. Netzwerkausgang und Zugriff auf Geheimnisse bleiben absichtlich bei ihren Vorgaben. Recherche ist der ganze Sinn eines Nur-Lese-Modus.

Einen Modus wählen und wechseln

Das Modus-Dropdown im Composer bietet drei Optionen: Agent (chat), Plan und Orchestrate. review ist nicht wählbar. Das System setzt es, wenn ein PR-Review-Bereich entsteht, und Pipeline-Schritte tun dasselbe.

Ein Pipeline-Knoten, der einen Bereich öffnet, kann den Modus dieses Bereichs mit dem Schlüssel extras['mode'] festlegen (chat, review oder plan). Der Schlüssel muss exakt passen. Jede andere Schreibweise, auch orchestrate, wird stillschweigend ignoriert, und der Bereich erhält die Vorgabe des Bodys (review im Body, der den Bereich anlegt). Ein Agenten-Schritt tritt einem Bereich bei, den er nicht angelegt hat, und setzt dessen Berechtigungen nicht neu.

Die Auflösung selbst ist einfach. Der Dispatcher liest die Spalte mode des Bereichs. Eine Ausführung ohne Bereich löst zu chat auf: ein One-Shot, ein CLI-Aufruf oder eine Bereichs-ID aus einem anderen Arbeitsbereich, die in der Datenbankdatei dieses Arbeitsbereichs schlicht nicht vorkommt. Ein Moduswechsel gilt ab dem nächsten Zug.

Wo die Zusicherung wirklich gilt

Die Werkzeugfläche eines Modus baut und erzwingt der eingebaute Harness. Nur dieser Transport kann ein Werkzeug unsichtbar machen, statt es bloß zu verweigern, jeden Aufruf vor der Ausführung durch ein Tor schicken und einen Abschlussvertrag beobachten.

Auf dem Transport Claude Code wird ein Modus außer Chat als --permission-mode plan übergeben. Claude hält sich daran per Konvention. Seine eigenen Werkzeuge zum Lesen, Schreiben und Bearbeiten laufen ungesehen, und seine Shell-Befehle prüft nur ein Hook, der die Befehlszeile liest. Für diesen Transport ist der Modus eine Vorgabe und keine Grenze von Control Center. Siehe Das Agentenmodell.

Die Zulassungslisten beschränken Werkzeuge ab der Schreibstufe. Die Lesestufe des eingebauten Harness erreicht weiterhin Werkzeuge, die keine Liste nennt. Auf Claude Code wird ein Werkzeug, das die Zulassungsliste auslässt, verweigert, ob der Server es hat oder nicht.