Mehrere KI-Agenten koordinieren: Claude, Codex und Gemini im Control Room (früher War Room)

Was ein AI Control Room tatsächlich ist

Ein Control Room ist ein benannter Raum im rechten Zusatzpanel. Das Panel schalten Sie mit Alt+Strg+B ein und aus (⌥⌘B auf dem Mac). Ein Mitglied fügen Sie über die Schaltfläche Control Room in der Pane-Kopfzeile hinzu, wo Sie einen Raum auswählen oder anlegen, oder über „Add all active panes“ im Tab Members.

Sobald ein Agent beitritt, wird eine Begrüßungsnachricht in seinen Pane getippt. Im Tab Members erscheint dann ein Mitglieds-Chip mit dem Badge „kein Handshake“, bis der Agent seinen ersten Tool-Aufruf macht, danach mit einem Statuspunkt.

Ein Raum ist ein gemeinsamer MCP-Server, mit dem sich beide Agent-Prozesse verbinden. Entscheidend ist die Mitgliedschaft, nicht die räumliche Nähe. Ein Pane mit Claude Code in einem Workspace und ein Codex-Pane in einem anderen Projektordner können sich einen Raum teilen, denn ein Control Room ist ein Nachrichtenkonzept und kein Split-Pane-Layout.

Sie können mehrere Räume gleichzeitig betreiben, jeden mit eigener Mitgliederliste und eigenem Transkript. Ein Pane gehört immer nur zu einem Raum. Um einen Agent umzuziehen, nutzen Sie die Schaltfläche Control Room in seiner Pane-Kopfzeile und wählen den anderen Raum.

Das Panel hat zwei Tabs: Members (Name, Ordner, Agent-Symbol und Verbindungsstatus jedes Mitglieds) und Discussion (Eingabefeld plus Transkript). Im Eingabefeld wählen Sie als Moderator ein Ziel (einen Agent oder „Alle“) und einen Modus.

Probe sendet eine Nachricht. Execute fügt einen Prompt in das Terminal genau dieses einen Agents ein und führt ihn dort aus. Die Agents haben dieselben zwei Tools in Gegenrichtung, sie können also einem Peer eine Probe-Nachricht schicken oder ihm eine Execute-Nachricht übergeben.

Für wen sich ein Control Room eignet

Wenn Sie einen Agent auf einem Repo betreiben, überspringen Sie das. Ein einzelner Claude-Code- oder Codex-Pane ist einfacher, und ein Control Room fügt eine Oberfläche hinzu, die Sie nie anfassen.

Sinnvoll wird er, sobald sich eine Aufgabe auf zwei Verantwortliche aufteilt: eine Änderung am Backend-Vertrag, die das Frontend abnehmen muss, ein Bug, der zwei Microservices in zwei getrennten Arbeitskopien betrifft, oder ein Agent, der implementiert, während ein zweiter den Diff prüft, bevor er ausgeliefert wird.

Er setzt außerdem voraus, dass Sie es akzeptieren, wenn ein CLI-Agent jeweils einige Minuten lang mit wenig Aufsicht Befehle ausführt. Der Modus Execute existiert, damit ein Übergabe-Prompt im Terminal eines Peers getippt und ausgeführt wird, ohne dass Sie ihn neu eintippen. Wenn Sie lieber jede Zeile lesen, die ein Agent ausführt, bleiben Sie im Modus Probe oder verzichten auf Execute.

Er lohnt sich nur mit Agents, die MCP-Tool-Aufrufe unterstützen. MXterm Pro schreibt seinen MCP-Server bei jedem Start der App in die Konfiguration von Claude Code (~/.claude.json), OpenAI Codex (~/.codex/config.toml) und OMP. Grok übernimmt den Eintrag, den MXterm in die Datei ~/.claude.json von Claude Code schreibt (geprüft mit Grok 1.0.34).

Gemini CLI bekommt den Server pro Projekt, geschrieben in .gemini/settings.json, sobald dort ein Gemini-Pane geöffnet wird. Welcher Agent es auch ist, er muss in einem MXterm-Pro-Pane laufen, denn das Token pro Pane, mit dem er sich gegenüber dem Server ausweist, stammt aus diesem Pane (aus seiner Umgebung bei Claude Code, Codex und OMP, aus dem Eintrag in settings.json bei Gemini). So erreicht der Agent die mxt_room-Tools.

Jeden anderen CLI-Agent müssen Sie von Hand auf die MCP-Adresse und das Token des Panes verweisen, und ob das funktioniert, ist nicht verifiziert.

Wie Agents tatsächlich miteinander sprechen

Die Begrüßungsnachricht weist jeden Agent an, zuerst mxt_room.list_peers aufzurufen. Sein erster erfolgreicher Control-Room-Aufruf bestätigt die Verbindung. Bis dahin sehen andere Mitglieder den Agent als noch nicht verbunden und können ihm keine Nachricht schicken.

Die vier Tools sind list_peers, send, read_inbox und claim. list_peers zeigt, wer im Raum ist. send schickt eine Nachricht an einen Peer oder an den Moderator, mit dem Modus „probe“ für Diskussion oder dem Modus „execute“, um eine ausführbare Aufgabe zu übergeben. read_inbox holt ab, was für den Agent in der Warteschlange liegt. claim reserviert Dateien, die ein Agent gleich bearbeitet, nur als Hinweis.

Eine Probe-Nachricht wird nicht vollständig in das Terminal des empfangenden Agents eingefügt. Eine einzelne Probe-Nachricht in der Warteschlange mit 280 Zeichen oder weniger, in einer Zeile und ohne « », wird in einen einzeiligen Hinweis eingebettet („[Control Room] Peer "X" sent probe message: « ... »“), sodass der Agent keinen zweiten Tool-Aufruf braucht. Ist die Nachricht länger, hat sie mehrere Zeilen oder liegt sie zusammen mit anderen in der Warteschlange, bekommt der Agent stattdessen einen Hinweis, read_inbox aufzurufen.

Die Größenbegrenzung und der Umweg über die Inbox verhindern, dass der Austausch zwischen Agents unbemerkt das Kontextfenster eines Agents aufbläht, was beim Einfügen einer ganzen Peer-Unterhaltung passieren würde.

Die Zustellung wartet, bis der Pane untätig ist. Die Ausgabeaktivität wird verfolgt, und ein Hinweis wird erst nach etwa 3 Sekunden Stille getippt.

Wenn Sie im Pane eine Zeile getippt, aber nicht abgeschickt haben oder in den letzten 6 Sekunden im fokussierten Pane eine Taste gedrückt haben, hält MXterm Pro die Zustellung zurück, bis Sie die Zeile abschicken oder löschen oder im Pane auf Jetzt zustellen klicken. Der Tab Members zeigt in der Zwischenzeit die Anzahl zurückgehaltener Nachrichten, damit eine eingereihte Nachricht nie mitten in dem landet, was Sie gerade tippen.

Auch Sie, der Mensch, der MXterm Pro bedient, sind ein Peer. „Moderator“ ist ein fester Peer, den jeder Agent per Probe ansprechen kann, wenn er eine Entscheidung braucht, die ein Peer-Agent nicht allein treffen kann. Eine Execute-Nachricht an den Moderator wird sofort abgelehnt, weil es dort kein Terminal gibt, in dem sie laufen könnte.

Text, den MXterm Pro im Auftrag eines Peers in einen Pane tippt, wird von ANSI-Escape-Sequenzen und Steuerzeichen befreit, und eine inline angezeigte Probe-Nachricht verliert außerdem die Begrenzer « ». Die vollständige Nachricht bleibt unverändert in der Inbox. Das verringert die Wahrscheinlichkeit, dass Peer-Text als Anweisung gelesen wird oder aus der zitierten Darstellung im Hinweis ausbricht; es ist keine Sicherheitsgrenze.

Ein durchgespieltes Beispiel: Zwei Agents verhandeln einen API-Vertrag

Ein typischer Ablauf: ein Pane mit Claude Code im Backend-Repo und ein Codex-Pane im Frontend-Repo (oder beide in einem Workspace). Fügen Sie beide Agents über die Schaltfläche Control Room in der Kopfzeile jedes Panes zum Raum hinzu oder über „Add all active panes“ im Tab Members. Jeder bekommt eine Begrüßungsnachricht und zeigt das Badge „kein Handshake“, bis er seinen ersten Tool-Aufruf macht.

Im Claude-Pane tippen Sie etwa: „Das Frontend braucht created_at in der Antwort von /users. Besprechen Sie die Vertragsänderung mit Ihrem Control-Room-Peer, bis Sie sich einig sind, und übergeben Sie ihm die Änderung dann im Modus execute.“

Claude schickt Codex eine Probe-Nachricht, Codex liest seine Inbox und antwortet, und das Hin und Her läuft im Transkript des Tabs Discussion ab. Sie sehen es live, statt etwas von Hand weiterzureichen.

Sobald sie sich einig sind, schickt Claude Codex eine Execute-Nachricht mit der konkreten Änderung. Sie wird in den Pane von Codex eingefügt und läuft dort, nicht in dem von Claude.

Das Entfernen wirkt sofort. Wenn Sie auf das X am Chip eines Mitglieds klicken (oder das Menü Control Room seines Panes nutzen), schlägt jede weitere Nachricht, die ein Peer an dieses Mitglied zu senden versucht, mit „not in the Control Room“ fehl. Die Mitgliedschaft wird sofort widerrufen, nicht nur in der Oberfläche ausgeblendet.

Git-Worktree-Isolierung hält Agents aus dem Branch der anderen heraus

Die Worktree-Isolierung ist ein eigenes, optionales Kontrollkästchen im Composer für neue Tabs, standardmäßig ausgeschaltet. Aktivieren Sie Features in git worktrees isolieren, wird in einem Git-Repo jeder Agent-Pane in diesem neuen Tab in einem eigenen Worktree unter <repo>/.worktrees/<slug> angelegt statt im Repo-Root.

In einem Ordner, der kein Git-Repo ist, fallen die Panes mit einem Hinweis auf den normalen Ordner zurück. Reine Shell-Panes bleiben in beiden Fällen im Repo-Root.

MXterm Pro trägt .worktrees/ in die .gitignore des Repos ein. Jeder Agent-Pane bekommt außerdem einen neuen Branch swarm/<adjective>-<noun>, zum Beispiel swarm/brave-otter.

Das hilft, sobald zwei Agents im selben Raum dasselbe Repository bearbeiten. Ein git Worktree pro Agent verringert die Wahrscheinlichkeit, dass die halbfertige Änderung oder der Branch-Wechsel eines Agents mitten in der Aufgabe im Diff eines Peers auftaucht. Die entstandenen Branches mergen Sie weiterhin selbst, denn MXterm Pro führt Worktrees nicht automatisch zusammen.

Der Bericht-Export (.md)

Klicken Sie in der Kopfzeile des Tabs Discussion neben Clear auf Report (.md), und MXterm Pro schreibt einen Markdown-Bericht, nicht nur ein rohes Chat-Protokoll.

Die Datei beginnt mit einer Mitgliedertabelle (Agent-Name, Modell bzw. Agent-ID, Arbeitsverzeichnis). Es folgt ein Dialogabschnitt, der aufeinanderfolgende Nachrichten unter einer Überschrift mit Zeitstempel pro Agent-Beitrag gruppiert. Jede Execute-Nachricht und jede an einen benannten Peer gesendete Probe-Nachricht ist mit ⚡ EXECUTE oder 📢 PROBE und ihrem Ziel markiert. Beitritte, Austritte und andere Raumereignisse erscheinen als Systemereigniszeilen.

Die Terminal-ID jedes Panes lässt die Datei absichtlich weg, da dieser Wert zugleich das MCP-Bearer-Token des Panes ist und der Bericht dafür gedacht ist, an andere weitergegeben zu werden, etwa an ein Teammitglied, an ein Ticket oder in Ihre eigenen Notizen.

Der Export steht in beiden Tarifen im vollen Umfang zur Verfügung. MXterm Pro begrenzt die Zahl der Agents, die Sie in einen Raum setzen können, nicht den Export selbst.

Free und Pro im Vergleich

Standardmäßig begrenzt der Free-Tarif einen Control Room auf 2 Mitglieder. Wenn Sie versuchen, ein drittes hinzuzufügen, blockiert MXterm Pro den Beitritt clientseitig und fordert Sie zum Upgrade auf. Es lässt ihn nicht stillschweigend zu, um erst später zu scheitern.

Pro hebt die Grenze auf: unbegrenzt viele Agents pro Raum. Die Zahl der Räume war nie begrenzt. Der Export Report (.md) ist in beiden Tarifen gleich, denn die Grenze gilt für die Raumgröße und nicht dafür, was Sie mit einem fertig aufgebauten Raum tun können.

Control Room im Vergleich zu manuellen Multi-Terminal-Setups, Warp und Multi-Agent-Frameworks

iTerm2 und tmux sind die Basis: kostenlos oder Open Source, solides Teilen von Panes, vollständig skriptbar, und Sie müssen keiner Instanz außer Ihrem eigenen Rechner vertrauen. Was sie nicht bieten, ist ein Nachrichtenbus.

Wenn sich zwei Agents in zwei Panes abstimmen müssen, sind Sie der Nachrichtenbus. Sie kopieren einen Fehler aus einem Pane, fügen ihn in den anderen ein und behalten im Kopf, wer was zugesagt hat. Nichts zeichnet den Austausch auf, außer Sie sichern Ihren eigenen Scrollback.

Warp ist ein ausgereiftes KI-Terminal mit eigener Multi-Agent-Orchestrierung: Ein übergeordneter Agent startet und koordiniert untergeordnete Agents, die Claude Code oder Codex ausführen können. Das Muster ist: starten und delegieren. Der Control Room funktioniert anders: Sie starten jeden Agent selbst in seinem eigenen Pane, und die Agents schicken sich und Ihnen, dem Moderator, über einen gemeinsamen Raum Nachrichten.

Frameworks wie AutoGen oder CrewAI sind für die Orchestrierung zwischen Agents gebaut, wohl mit mehr Struktur als ein Nachrichtenbus aus Probe und Execute. Es sind aber Python-Bibliotheken, die Sie skripten und aus einem Notebook oder einem CLI-Einstiegspunkt starten. Echte PTY-Terminal-Panes, in denen Sie die Ausgabe mitlaufen sehen, hineinspringen und mitten im Gespräch tippen können, bekommen Sie dort nicht.

Das AI Control Room Terminal bietet dagegen etwas Spezielleres: echte Terminal-Panes, in denen jeder Agent eine laufende CLI-Sitzung ist statt eines gekapselten API-Aufrufs, dazu einen Nachrichtenbus und einen Moderator-Platz dazwischen, angedockt in dem Fenster, in dem Sie Ihre Terminals ohnehin betreiben.

Er ist eine Alternative zum Weiterreichen von Hand zwischen Panes. Er ist kein Ersatz für ein skriptbares Orchestrierungs-Framework, falls Sie genau dieses Problem haben.

Grenzen, die Sie vor dem Start kennen sollten

Der Control Room startet von sich aus keine Debatte: Sie müssen einen Agent per Prompt auffordern, seinen Peer anzusprechen und weiterzumachen. Er ist ein Nachrichtenbus mit einer Oberfläche darum, kein autonomer Multi-Agent-Planer.

Ein reiner Shell-Pane kann einem Raum beitreten, führt aber keinen MCP-Client aus, daher deaktiviert das Eingabefeld das Senden einer Execute-Nachricht an diesen Pane. Ein dort eingefügter Prompt würde nur als wörtliche Shell-Befehle laufen. Ein Shell-Pane ist im Raum ein Zuschauer, kein echter Peer.

Jeder zusätzliche Agent ist ein weiterer vollständiger CLI-Prozess mit eigenem Modellkontingent, ein Raum mit vier Agents führt also vier getrennte Agent-Sitzungen aus. Heben Sie sich Räume mit mehreren Agents für Aufgaben auf, die eine zweite Sichtweise brauchen, nicht für die alltägliche Arbeit mit einem Agent.

Erste Schritte

Fügen Sie zwei Agents über die Schaltfläche Control Room in der Kopfzeile jedes Panes zu einem Raum hinzu. Das öffnet auch das rechte Panel auf dem Tab Control Room (Alt+Strg+B oder ⌥⌘B auf dem Mac). Beginnen Sie mit zwei Agents in zwei verschiedenen Ordnern, damit Sie einmal eine Probe- und eine Execute-Nachricht ablaufen sehen, bevor Sie etwas Ehrgeizigeres versuchen. Die Control-Room-Seite gibt den Überblick, die Doku zu Agents und Control Room die Referenz.

Die Grenze von 2 Mitgliedern im Free-Tarif wird erst zur Einschränkung, wenn eine Aufgabe einen dritten Beteiligten braucht.