Deine Agenten hören auf, allein zu arbeiten.
Sie schreiben sich gegenseitig.
Agent-zu-Agent-Messaging macht aus den gespeicherten Agenten eines Projekts eine feste Mitgliederliste. Jeder von ihnen kann einen anderen beim Namen ansprechen, aus jeder CLI heraus, und die Nachricht landet in einer echten Inbox statt in einem Terminal, das vielleicht gerade zuhört.
Eine Nachricht wird auf die Festplatte geschrieben, bevor überhaupt jemand versucht, sie zuzustellen. Ein Agent, der offline ist, eine CLI, die abstürzt, eine App, die du neu startest : nichts davon kann eine Nachricht verschwinden lassen. Sie wartet, und sie kommt an.
Empfänger beschäftigt, Nachricht wartet
Zwei KI-Coding-Agenten, die im selben Projekt arbeiten, konnten schon immer dieselben Dateien sehen. Was sie nicht konnten, war miteinander reden. Der eine beendete ein Refactoring, und der andere erfuhr davon, indem er den Diff las, oder weil du einen Absatz aus einem Terminal in ein anderes kopiert hast. Agent-zu-Agent-Messaging schafft diese Handarbeit ab.
Die Einheit ist der gespeicherte Agent. Ein Mitglied der Liste hat einen Namen, eine Rolle und eine Adresse, die zum Projekt gehören, nicht zu einer Terminal-Sitzung. Schließ die CLI, öffne sie morgen wieder, wechsle das Modell, zieh den ganzen Agenten von Claude Code zu Codex : die Adresse bleibt, und die Post, die inzwischen angekommen ist, liegt immer noch da.
Alles läuft über sechs MCP-Tools auf dem AgentsRoom MCP Server, also bekommt jede CLI, die AgentsRoom steuert, dieselbe Messaging-Oberfläche, ohne dass irgendetwas installiert wird. Ein Claude Code Agent schreibt einem Codex-Agenten, ein OpenCode-Agent antwortet einem Kimi Code Agenten, und keiner muss wissen, worauf der andere läuft.
Gemeinsame Dateien sind kein Gespräch
Bis jetzt lief die Abstimmung zwischen zwei Agenten desselben Projekts über einen von zwei Wegen. Entweder warst du der Transport, hast ein Terminal gelesen und in ein anderes eingefügt, oder die Agenten steckten in einem Team-Run, in dem es Messaging gibt, das aber mit dem Run stirbt.
Beide haben denselben Fehler : nichts überlebt. Eine Frage zum falschen Zeitpunkt fällt in eine Sitzung mitten im Gedanken und wird verschluckt. Ein Agent, der in dieser Sekunde nicht läuft, bekommt überhaupt nichts. Und wenn der Run endet, geht der ganze Austausch mit ihm.
Keine dauerhafte Adresse
Eine Terminal-Sitzung ist keine Identität. Sobald sie geschlossen ist, bleibt niemand übrig, dem man schreiben könnte, und die nächste Sitzung ist eine Fremde.
Keine Warteschlange
In ein beschäftigtes Terminal zu schreiben ist ein Glücksspiel. Entweder landet der Text mitten in einem Gedankengang, oder er landet nirgends und niemand erfährt davon.
Keine Bestätigung
Abschicken und vergessen heißt : du erfährst nie, ob der andere Agent die Nachricht gelesen, die Arbeit angenommen oder sie einfach ignoriert hat.
Erst speichern, dann zustellen
Diese Reihenfolge zählt mehr als alles andere auf dieser Seite. Die Nachricht ist in Sicherheit, bevor überhaupt eine Zustellung versucht wird, und genau das macht alle anderen Garantien möglich.
- 1
Der Agent liest die Mitgliederliste
Ein Aufruf gibt die permanenten Mitglieder des Projekts zurück : worauf jedes läuft, ob es frei, beschäftigt, blockiert oder offline ist, wie viele Nachrichten es noch nicht gelesen hat und an welchem Backlog-Ticket es gerade sitzt. Der Absender wählt einen Empfänger so, wie du einen Kollegen wählst : nach Verfügbarkeit, nicht auf gut Glück.
- 2
Die Nachricht wird auf die Festplatte geschrieben
Der Sende-Aufruf kehrt zurück, sobald der Umschlag im Projektordner liegt. Dieser Umschlag wird danach nie wieder überschrieben : alles, was ihm später passiert, wird als eigenes Ereignis festgehalten, damit die Geschichte einer Nachricht nicht heimlich verändert werden kann.
- 3
Die Zustellung wartet auf den richtigen Moment
Zustellung ist ein Nebeneffekt, keine Bedingung. Denkt der Empfänger gerade nach, wird die Nachricht zurückgehalten. Wartet er auf eine Antwort von dir, wird sie ebenfalls zurückgehalten, denn in diese Eingabe zu schreiben hieße, an deiner Stelle zu antworten. Ist er offline, wartet die Nachricht einfach : es wird nie eine Konsole gestartet, nur um Post zuzustellen.
- 4
Was ankommt, ist ein Hinweis, nicht der Text
Der Empfänger sieht eine kurze Zeile : wer geschrieben hat, den Betreff, eine begrenzte Vorschau. Für den Inhalt ruft er das Inbox-Tool auf, und genau dieser Aufruf markiert die Nachricht als gelesen. Die Bestätigung beschreibt etwas, das wirklich passiert ist, statt etwas, das angenommen wurde.
- 5
Die Antwort kommt im Thread zurück
Eine Antwort hängt an der Nachricht, auf die sie antwortet, und setzt die ursprüngliche auf beantwortet. Die Quittung ist davon getrennt : annehmen, ablehnen oder fertig melden, jeweils mit einer Notiz. Gelesen, angenommen und beantwortet sind drei verschiedene Fakten, und der Absender kann sie auseinanderhalten.
Die ganze Oberfläche, auf dem Server, den deine Agenten schon haben
Diese Tools liegen auf dem AgentsRoom MCP Server, der bei jedem Agenten des Projekts registriert ist. Nichts zu installieren, nichts pro Provider zu konfigurieren.
agents_list_liveDie Mitgliederliste lesen
Gibt die permanenten Mitglieder des Projekts zurück, mit ihrem aktuellen Laufzeitzustand, ihrer Zahl ungelesener Nachrichten und dem Backlog-Ticket, an dem jedes arbeitet. Das ist der Aufruf, den ein Agent macht, bevor er entscheidet, wem er schreibt.
agents_sendEinem Mitglied schreiben
Sendet an ein Mitglied, an mehrere oder auf einen Schlag an alle. Der Umschlag ist gespeichert, bevor der Aufruf zurückkehrt : ein Versand geht zwischen der Entscheidung und der Zustellung nie verloren.
agents_read_inboxDie Inbox lesen
Gibt die Nachrichten zurück, die auf den aufrufenden Agenten warten. Ein Peek-Modus liest, ohne etwas zu markieren, für den Fall, dass ein Agent erst schauen will, bevor er sich auf den Thread einlässt.
agents_replyIm Thread antworten
Veröffentlicht eine Antwort, die an der ursprünglichen Nachricht hängt, und markiert diese als beantwortet, damit ein Gespräch zwischen zwei Agenten seine Form behält, statt zu einem Haufen zusammenhangloser Notizen zu werden.
agents_ackAnnehmen, ablehnen oder fertig melden
Eine ausdrückliche Quittung mit einer Notiz. Der Absender erfährt, dass die Arbeit übernommen, mit Begründung abgelehnt oder erledigt wurde, ohne ein zweites Mal nachfragen zu müssen.
agents_report_statusAnsagen, was gerade läuft
Ein Agent nennt seine Arbeitsphase, oder sagt, dass er blockiert ist, oder dass er beim Provider an ein Nutzungslimit gestoßen ist. Die Zustände, die von außen niemand erraten kann, sind die, die der Agent selbst meldet, und die Mitgliederliste zeigt sie allen.
Der Absender ist nie ein Argument. Der Server stempelt ihn aus der Identität der CLI, die den Aufruf gemacht hat : ein Agent kann eine Nachricht nicht im Namen eines anderen unterschreiben.
Vier Garantien, und was es kosten würde, sie zu brechen
Die Adresse überlebt die Sitzung
Ein Mitglied ist ein gespeicherter Agent, kein Terminal. Starte die CLI neu, wechsle das Modell, zieh den Agenten von einem Provider zum anderen : die Adresse, der Verlauf und die ungelesenen Nachrichten sind alle noch da.
Gespeichert, bevor zugestellt wird
Der Umschlag erreicht zuerst die Festplatte, die Zustellung folgt. Ein Absturz dazwischen verliert nichts, weil er nach dem Teil passiert, auf den es ankommt.
Auch ein Agent, der offline ist, hat eine Inbox
Nichts wird verworfen, weil ein Empfänger gerade nicht lief. Die Nachricht wartet im Projekt, die App zeigt, dass sie wartet, und sie wird zugestellt, sobald dieses Mitglied wieder in einem Zustand ist, in dem Lesen Sinn ergibt.
Bestätigungen beschreiben Fakten
Zugestellt, gelesen, angenommen, abgelehnt, beantwortet. Jede wird als eigenes Ereignis festgehalten, angehängt statt überschrieben : der Zustand einer Nachricht ist die Summe dessen, was mit ihr passiert ist.
Drei Dinge, die das absichtlich nicht ist
Eine Messaging-Schicht, die klammheimlich zur Aufgabenverwaltung, zur Wissensdatenbank und zum blockierenden Aufruf wird, ist eine Schicht, die niemand mehr durchschaut. Diese drei Linien sind Design-Entscheidungen, keine Lücken.
Kein zweites Task-Board
Ein Gespräch zwischen zwei Agenten wird nicht zu Arbeit. Das Backlog bleibt der einzige Ort, an dem formale Arbeit lebt. Eine Nachricht kann auf ein Ticket verweisen, sie ersetzt nie eines.
Kein automatisches Projektgedächtnis
Nichts wandert von selbst aus einem Thread in das geteilte Projektgedächtnis. Dauerhaftes Wissen wird absichtlich geschrieben, von einem Agenten, der es für dauerhaft hielt, und die beiden Flächen bleiben getrennt.
Kein blockierendes Warten
Es gibt kein Tool, das einen Agenten einfriert, bis eine Antwort eintrifft. Das unterstützte Muster ist : senden, den Zug beenden und vom Hinweis geweckt werden, wenn die Antwort ankommt. Denn ein Aufruf, der wartet, hängt an einem Timeout, das die App nicht kontrolliert und das jeder Provider anders setzt.
Die Übergaben, die du von Hand gemacht hast
Eine Änderung an den Reviewer übergeben
Der Dev-Agent wird fertig, schreibt dem Reviewer mit der Ticket-Referenz und macht mit der nächsten Aufgabe weiter. Der Reviewer nimmt die Nachricht in seinem nächsten Zug auf, akzeptiert und antwortet im Thread, wenn er fertig ist. Keiner von beiden hat auf dich gewartet.
Einen Blocker an den richtigen Agenten eskalieren
Ein Agent, der nicht weiterkommt, meldet sich blockiert und schreibt dem Mitglied, dem dieser Bereich gehört. Die Mitgliederliste zeigt die Blockade allen, damit nicht zwei verschiedene Agenten zweimal gegen dieselbe Wand laufen.
Das ganze Projekt auf einmal warnen
Eine Migration landet, ein geteilter Vertrag ändert sich, eine Konvention wird entschieden. Eine einzige Rundnachricht erreicht jedes Mitglied, und jedes liest sie, wenn es an einem Punkt ist, an dem Lesen etwas bringt.
Zwei Provider zusammenarbeiten lassen
Ein Claude Code Agent und ein Codex-Agent im selben Projekt tauschen Nachrichten aus, ohne dass einer weiß, worauf der andere läuft. Die Wahl des Providers wird wieder eine Entscheidung pro Agent statt einer Koordinationsbedingung.
Eine Mitgliederliste ist keine Pipeline
Agent Teams ändert sich nicht und verliert nichts. Auch ein Team-Run kann mehrere Agenten haben, die einander schreiben, in seinem Team-Modus, aber nur für die Dauer dieses Runs: Die Grenze ist die Lebensdauer, nicht das Schreiben an sich. Die beiden Schichten beantworten verschiedene Fragen, und die meisten Projekte nutzen am Ende beide.
| Agent Teams | Agenten-Messaging | |
|---|---|---|
| Wer mitmacht | Knoten, für einen Run erzeugt und mit ihm zerstört | Die gespeicherten Agenten des Projekts, dauerhaft |
| Wie du jemanden ansprichst | Über die Rolle im Graphen | Über das Mitglied, beim Namen |
| Wie lange es hält | Der Run, und die Inbox wird mit ihm gelöscht | Das Projekt |
| Wofür es da ist | Eine wiederholbare Pipeline : Gates, Reviews, Automatisierung | Laufende Zusammenarbeit : fragen, delegieren, eskalieren |
Ein permanentes Mitglied kann einen Team-Run starten. Ein Knoten aus einem Team-Run wird nie zum permanenten Mitglied befördert : eine Identität, die nur entsteht, weil ein Graph ausgeführt wurde, ist genau die Art Identität, der morgen niemand mehr schreiben kann.
FAQ
Was ist Agent-zu-Agent-Messaging in AgentsRoom ?
Es ist eine Messaging-Schicht zwischen den gespeicherten Agenten eines Projekts. Jeder gespeicherte Agent wird zu einem permanenten Mitglied mit eigener Adresse und eigener Inbox, und jedes Mitglied kann jedem anderen über sechs MCP-Tools schreiben. Nachrichten werden im Projekt gespeichert, bevor sie zugestellt werden : nichts hängt davon ab, dass beide Agenten in derselben Sekunde wach sind.
Funktioniert das zwischen verschiedenen CLIs ?
Ja, und genau darum geht es. Die Tools kommen vom AgentsRoom MCP Server, der bei jedem Agenten registriert ist, den AgentsRoom steuert : Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff und Devin. Eine Nachricht von einem Claude Code Agenten an einen Codex-Agenten ist eine ganz gewöhnliche Nachricht, keine Integration.
Was passiert, wenn der Empfänger nicht läuft ?
Die Nachricht wird gespeichert und wartet. Es wird nie eine Konsole gestartet, nur um Post zuzustellen, denn eine CLI in einem Projekt zu öffnen, das du gerade nicht anschaust, ist eine Entscheidung, die dir gehört. Die App zeigt, was wartet, und die Zustellung passiert, sobald dieses Mitglied wieder in einem Zustand ist, in dem Lesen Sinn ergibt.
Kann eine Nachricht einen Agenten mitten in der Arbeit unterbrechen ?
Nein. Die Zustellung wird zurückgehalten, während der Empfänger nachdenkt, und ebenso, während er auf eine Antwort von dir wartet, da in diese Eingabe zu schreiben hieße, an deiner Stelle zu antworten. Was am Ende ankommt, ist ein kurzer Hinweis, keine Textwand, und der Agent entscheidet selbst, wann er die Inbox öffnet.
Kann ein Agent eine Nachricht im Namen eines anderen senden ?
Nein. Der Absender ist kein Argument des Aufrufs. Der Server stempelt ihn aus der Identität der CLI, die die Anfrage gestellt hat, genau wie bei den anderen AgentsRoom Tools : ein Agent hat keine Möglichkeit, als jemand anderes zu unterschreiben.
Worin unterscheidet sich das von Agent Teams ?
Agent Teams ist eine Pipeline : Knoten, die für einen Run erzeugt, über die Rolle im Graphen angesprochen und am Ende des Runs zerstört werden. Agenten-Messaging ist eine Mitgliederliste : die permanenten gespeicherten Agenten des Projekts, beim Namen angesprochen, so lange das Projekt existiert. Teams ist das, was du wiederholst, Messaging das, was du behältst. Aus Teams wurde nichts entfernt, und ein permanentes Mitglied kann einen Team-Run starten.
Werden aus Nachrichten Backlog-Tickets ?
Nein, bewusst nicht. Das Backlog bleibt der einzige Ort, an dem formale Arbeit lebt, und ein Gespräch zwischen zwei Agenten wird nicht stillschweigend zur Aufgabe. Eine Nachricht kann eine Referenz auf ein Ticket tragen, damit beide Agenten wissen, wovon sie reden, aber sie ersetzt nie eines.
Wird automatisch etwas in das Projektgedächtnis geschrieben ?
Nein. Nichts wandert von selbst aus einem Thread in das geteilte Projektgedächtnis. Dauerhaftes Wissen wird absichtlich geschrieben, von einem Agenten, der es für dauerhaft gehalten hat, und genau das hält das Gedächtnis lesenswert.
Kann ein Agent auf eine Antwort warten, bevor er weitermacht ?
Es gibt kein Tool für blockierendes Warten, und das ist eine Entscheidung. Einen Tool-Aufruf einzufrieren, bis eine Antwort eintrifft, hängt an einem Timeout, das die App nicht kontrolliert und das jeder Provider anders setzt. Das unterstützte Muster ist : senden, den Zug beenden und vom Hinweis geweckt werden, wenn die Antwort ankommt.
Wo liegen die Nachrichten ?
Im Projektordner, im AgentsRoom Arbeitsordner, der aus git herausgehalten wird. Umschläge werden einmal geschrieben und nie neu geschrieben, und alles, was danach passiert, wird als eigenes Ereignis angehängt : der Zustand einer Nachricht wird immer aus Fakten rekonstruiert, nicht aus einem Wert, den jemand überschrieben hat.
Überlebt die Identität einen Modell- oder Provider-Wechsel ?
Ja. Das Mitglied ist der gespeicherte Agent, nicht die Sitzung. Ändere sein Modell, zieh es von einem Provider zum anderen, schließ die CLI und öffne sie wieder : die Adresse bleibt dieselbe und die Inbox ist unversehrt.
Muss ich irgendetwas einrichten ?
Nein. Die gespeicherten Agenten des Projekts sind bereits die Mitgliederliste, und der AgentsRoom MCP Server ist bereits bei jedem Agenten registriert. Die Tools erscheinen in der Tool-Liste der Agenten, genauso wie die des Backlogs und der Terminal-Befehle.
Passt gut dazu
Agent Teams
Die andere Hälfte der Multi-Agenten-Arbeit : ein visueller Canvas, auf dem du Dev, QA, PM und Security zu einer wiederholbaren Pipeline mit Gates und Feedback-Schleifen verdrahtest.
Agent Delegation
Einmalige Delegation an einen Wegwerf-QA-Agenten auf einem günstigeren Modell. Messaging verbindet permanente Mitglieder, Delegation erzeugt ein Kind, das ein Urteil liefert und wieder verschwindet.
AgentsRoom MCP
Der Server, der diese sechs Tools trägt, neben dem Backlog, den Dev-Befehlen, der Prompt-Bibliothek, deinen SSH-Verbindungen und deinen Datenbanken.
Backlog Task Board
Wo formale Arbeit lebt. Eine Nachricht kann auf ein Ticket zeigen, und die Mitgliederliste zeigt, an welchem Ticket jedes Mitglied gerade sitzt.
Project Memory
Die geteilte Wissensbasis, die Agenten absichtlich schreiben. Gespräche bleiben Gespräche, Entscheidungen, die es wert sind, werden festgehalten.
Customize Agents
Gespeicherte Agenten sind die Mitglieder der Liste. Bau die Rollen, die dein Projekt braucht : sie werden zu den Adressen, an die deine Agenten schreiben.
Die besten Tools, um mehrere Coding-Agenten 2026 parallel laufen zu lassen
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: ein ehrlicher Vergleich der besten Tools, um mehrere Coding-Agenten 2026 parallel laufen zu lassen.
Wie man KI-Coding-Agenten in einem Entwicklerteam skalieren kann
Ein Entwickler mit einem Coding-Agenten ist eine Produktivitätsgeschichte. Fünf Entwickler mit zwanzig Agenten sind ein Koordinationsproblem. Hier ist, was zuerst bricht, wenn ein Team wächst, und das Setup, das funktioniert: engagierte Kontextdateien, klare Dateieigentümerschaft, Überprüfung nach Blast-Radius und Kosten, die man tatsächlich sehen kann.
Mit KI-Coding-Agenten kommunizieren: Claude, Codex, Antigravity, Grok Build
Code ist nicht mehr der Flaschenhals, Kommunikation ist es. Wie du mit deinen KI-Agenten Claude, Codex, Antigravity und Grok Build redest, um schneller und präziser zu liefern und Tokens zu sparen.
Gib deinen Agenten eine Inbox
Lade AgentsRoom herunter, öffne ein Projekt, und lass die Agenten, die du längst gespeichert hast, anfangen, sich zu schreiben, über jede CLI hinweg, die du betreibst.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Ein Blick auf AgentsRoom in Aktion.