Ich kopierte immer wieder den Bericht eines Agenten in einen anderen Chat und brachte die Antwort zurück. Ein Agent prüfte und verteilte die Arbeit, der andere führte sie aus. Beide konnten ihren Teil übernehmen, aber die Verbindung zwischen ihnen war ich. Ich wollte weiter entscheiden, worauf es ankommt, ohne jede Nachricht selbst weiterzuleiten.
Der Austausch braucht Zustand: Agent Talks gibt den beiden Sitzungen einen benannten lokalen Kanal. Ein Orchestrator schickt eine Aufgabe, ein Worker meldet das Ergebnis oder ein Hindernis, und der Orchestrator prüft es. Der Kanal hält fest, wer gerade handeln darf. Verschiedene Namen ermöglichen mehrere unabhängige Paare.
Die öffentliche Version ist ein kleines Python-Werkzeug mit SQLite und MCP, dem Model Context Protocol für Agentenwerkzeuge. Beide Codex-Sitzungen laufen auf demselben Rechner unter demselben Benutzerkonto. Ihre Werkzeugprozesse lesen dieselbe Datenbank. Ein Netzwerk-Broker oder zusätzliches Modell ist nicht beteiligt.
Eine Zuständigkeit zur Zeit: Zu Beginn ist der Orchestrator zuständig. Eine Aufgabe übergibt an den Worker, ein Bericht gibt die Kontrolle zurück. Revisionsnummern verhindern Antworten auf einen veralteten Stand. Eine Anfrage-ID sorgt dafür, dass eine identische Wiederholung die gespeicherte Nachricht zurückgibt, statt sie doppelt zu senden.
Während der andere Agent zuständig ist, bleibt ein Werkzeugaufruf offen. Er prüft den lokalen Zustand ohne Modellanfragen. Erst wenn der Agent ein Ergebnis verarbeitet, wird wieder Modellarbeit nötig. Ein Zeitlimit erlaubt keine neue Arbeit. Ein beendeter Chat muss weiterhin vom Benutzer fortgesetzt werden.
Die Prüfung bleibt beim Orchestrator: Nach einem Bericht kann der Orchestrator das Ergebnis untersuchen, mit dem Benutzer besprechen oder die nächste Aufgabe vergeben. Eine abgeschlossene Chatantwort muss den Kanal nicht schließen. Wartet der Worker nach einer erhaltenen Aufgabe ohne Bericht, gibt das Werkzeug die Kontrolle mit einem Wiederherstellungshinweis zurück. Es behauptet damit keinen Abschluss.
Verlorene Sitzungen lassen sich ersetzen: Dieselbe Sitzung kann sich erneut registrieren und ihr Token zurückbekommen. Eine neue Sitzung darf eine Rolle erst nach Bestätigung des Benutzers übernehmen. Das alte Token wird ungültig, der Verlauf bleibt erhalten, und ein offener Kanal geht zur Prüfung an den Orchestrator zurück. Beide Rollen lassen sich einzeln oder gemeinsam ersetzen. Auch das Schließen braucht eine Bestätigung.
Laufende Befehle brauchen weiterhin Aufmerksamkeit. Ein Sitzungswechsel beendet keine zuvor gestarteten Hintergrundprozesse. Vor einer erneuten Aufgabenvergabe muss der Orchestrator unvollständige Arbeit prüfen. Die Wiederherstellung ordnet die Kommunikation, beweist aber nicht den Zustand des Arbeitsverzeichnisses.
Die Kontrolle hat Grenzen: Die Codex-Hooks prüfen die Sitzungsidentität und blockieren erfasste Arbeitswerkzeuge außerhalb des eigenen Zuges. Sie prüfen keine Aufgabenbedeutung und schaffen keine Sandbox. Agenten mit demselben Benutzerkonto können weiterhin dessen Dateien lesen und ändern. Nachrichten werden lokal im Klartext gespeichert und können über den Agentenkontext an dessen Modellanbieter gelangen.
Die Installation bleibt überschaubar: INSTALL-PROMPT.md führt einen Coding-Agenten durch Einrichtung, Tests und das Ergänzen der MCP- und Hook-Konfiguration. Andere Einstellungen bleiben erhalten. Die Hook-Freigabe übernimmt der Benutzer in Codex. Diese Veröffentlichung enthält Quellcode, aber kein Debian-Paket, keinen entfernten Dienst und keine Messaging-Brücke.
Die Tests prüfen Zugwechsel, konkurrierende Änderungen, Wiederholungen, Bestätigungen und Wiederherstellung mit echten MCP-Unterprozessen. Sie beweisen weder das Urteilsvermögen eines Agenten noch das Hook-Verhalten jeder Hostversion. Der praktische Gewinn ist, dass die Agenten ihre Aufgaben und Berichte selbst austauschen und ich ihre tatsächliche Arbeit prüfen kann.