Wie mehrere Agenten miteinander kommunizieren, wird derzeit an vielen Stellen neu entworfen. Google hat mit A2A ein eigenes Protokoll für die Kommunikation zwischen Agenten veröffentlicht. Anthropic hat MCP, um Agenten mit Werkzeugen und Daten zu verbinden. Jedes ernstzunehmende Agenten-Framework hat irgendein Übertragungsformat zwischen Agenten: JSON-RPC, Function Calls, strukturierte Nachrichten mit typisierten Payloads. Hinter all dem steckt die Annahme, dass Agenten zum Kommunizieren ein Protokoll brauchen. Etwas Maschinenlesbares. Etwas mit einem Schema.
Nun leben Clive-Agenten aber ohnehin in Terminals. Sie lesen Text, sie tippen Text. Wenn die Terminalausgabe des einen Agenten die Terminaleingabe des anderen ist, brauchen Sie kein neues Protokoll. Sie brauchen SSH. Das Adressierungsmodell ist so einfach, wie es aussieht:
clive "clive@devbox check disk usage and report"
Der äußere Clive liest clive@devbox aus dem Aufgabentext heraus, löst den Host auf (über eine optionale YAML-Registry oder automatisch), öffnet eine SSH-Verbindung in einem neuen tmux-Pane und leitet die Aufgabe weiter. Der innere Clive, also der auf devbox, nimmt die Aufgabe entgegen, führt sie in seinem eigenen Habitat mit seinen eigenen Werkzeugen aus und meldet zurück.
Aus Sicht des äußeren Agenten ist der Agenten-Pane einfach ein weiterer Pane. Er liest den Bildschirm, sieht Text und tippt, wenn es passt. Dieselbe Schleife, die lynx, mutt oder eine Shell steuert, steuert auch eine entfernte Clive-Instanz. Die Architektur braucht dafür keinen Sonderfall.
Verkettung ergibt sich von selbst:
clive "clive@gpu render the video then clive@web upload it to S3"
Zwei Adressen, zwei Agenten-Panes, vom Planner in eine Reihenfolge gebracht. Jede entfernte Instanz ist autonom: Sie hat ihre eigenen Werkzeuge, ihr eigenes Modell, ihr eigenes Urteil.
Das Konversationsprotokoll
Eines ändert sich allerdings, wenn ein Agent mit einem anderen Agenten spricht statt mit einem CLI-Werkzeug: Es kommt darauf an, wer gerade an der Reihe ist.
Beim Steuern von grep tippt der Agent und liest sofort das Ergebnis. Beim Steuern eines anderen Clive muss der Agent wissen, ob die Gegenstelle noch arbeitet, eine Frage hat oder fertig ist. Ohne dieses Signal würde der äußere Agent entweder laufende Arbeit unterbrechen oder Token verschwenden, indem er einen unveränderten Bildschirm immer wieder liest.
Die Lösung ist ein Textprotokoll, aber Text im wörtlichsten Sinn. Der innere Clive schreibt Zeilen nach stdout:
TURN: thinking ← I'm working, don't type
PROGRESS: step 2 ← status update
QUESTION: "which format?" ← I need input
CONTEXT: {"result": "summary here", "files": ["report.pdf"]}
TURN: done ← finished
Der äußere Agent liest diese Zeilen genauso wie jede andere Terminalausgabe. TURN: thinking heißt warten. TURN: waiting heißt antworten. TURN: done heißt: das Ergebnis aus CONTEXT holen und weitermachen. Während thinking-Phasen überspringt der Executor den LLM-Aufruf ganz. Solange der innere Agent arbeitet, gibt es für den äußeren nichts zu entscheiden.
Das ist kein strukturiertes Protokoll in dem Sinn, in dem A2A oder MCP strukturiert sind. Es ist Text auf einem Bildschirm. Der äußere Agent liest ihn mit demselben Parser wie alles andere. Der innere Agent schreibt ihn mit print(). Das „Protokoll“ besteht aus einer Handvoll Schlüsselwörter und einem JSON-Blob.
Bringen Sie Ihr eigenes LLM mit
Ein Detail hat größere Folgen, als man zunächst meint: Die entfernte Clive-Instanz verwendet Ihre API Keys, nicht eigene.
Beim Öffnen der SSH-Verbindung werden die Umgebungsvariablen mit den API Keys (ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY) über SSH SendEnv weitergereicht. Dafür braucht es eine passende AcceptEnv-Direktive in der Konfiguration des SSH-Daemons auf dem entfernten Host. Der entfernte Clive liest die Keys aus seiner Umgebung und nutzt sie für die Inferenz. Auf entfernten Hosts wird kein Key gespeichert. Es gibt keine zentrale Schlüsselverwaltung und keinen Token-Brokering-Dienst.
Die Intelligenz ist damit dezentral. Jeder Knoten in der Topologie bringt sein eigenes Gehirn mit, genauer gesagt: Er borgt sich Ihres für die Dauer der Sitzung. Wenn die SSH-Verbindung geschlossen wird, sind die Keys weg. Auf der Festplatte des entfernten Hosts waren sie nie.
Was das für das Deployment heißt, lohnt sich auszubuchstabieren: Jede Maschine mit Python, tmux und SSH (so konfiguriert, dass es die weitergereichten Umgebungsvariablen akzeptiert) wird zum Clive-Knoten. Keine Registrierung. Keine API Keys, die auf entfernten Hosts eingerichtet werden müssten. Die Keys des Betreibers reisen mit der Sitzung, und der entfernte Host liefert die Umgebung: die installierten Werkzeuge, das Dateisystem, die Position im Netzwerk.
Die Kostenkurve
Die Kommunikation zwischen Agenten ist das Schlagzeilen-Feature, aber für den Alltag zählt die Arbeit darunter mehr. Die ursprüngliche Clive-Architektur rief das LLM in jedem Zug auf, bei jeder Aufgabe. Das ist korrekt, aber teuer. Die meisten Aufgaben brauchen das nicht. Das heutige Routing arbeitet in drei Stufen:
Stufe 0: Regex. Beginnt die Aufgabe mit ls, curl, grep, jq oder einem von rund 40 gängigen Befehlen, geht sie direkt an die Shell. Null LLM-Aufrufe. Kosten: keine.
Stufe 1: Schneller Klassifikator. Ein kleines, billiges Modell bestimmt die Absicht: Ist das eine Frage, ein direkter Befehl, eine Skriptaufgabe oder etwas, das einen vollständigen Plan braucht? Ein LLM-Aufruf, kleines Modell. Die meisten Aufgaben erledigen sich hier.
Stufe 2: Vollständiger Planner. Komplexe Aufgaben mit mehreren Schritten bekommen den vollständigen DAG-Planner. Mehrere Teilaufgaben, parallele Ausführung, Nachverfolgung der Abhängigkeiten. Hier verdient sich das volle Modell sein Geld.
Bei der Ausführung gilt dasselbe Prinzip. Teilaufgaben im Skriptmodus erzeugen in einem LLM-Aufruf ein Shell-Skript und führen es mechanisch aus. Der interaktive Modus greift nur, wenn die Aufgabe tatsächlich Beobachtung verlangt: beim Browsen, Debuggen oder Erkunden unbekannter Systeme. Der Unterschied bei den Token liegt ungefähr beim Faktor 2,5.
Das Turn-State-Protokoll überträgt das auf Agenten-Panes. Wenn der innere Clive TURN: thinking meldet, ruft der äußere Clive sein LLM nicht auf. Er schläft und liest den Bildschirm nach zwei Sekunden erneut. Eine Agenten-Konversation mit dreißig Sekunden Arbeit des inneren Agenten kostet den äußeren Agenten in diesem Zeitraum null Token.
Das Leitprinzip: LLM dort, wo Urteilsvermögen gefragt ist, Shell überall sonst. Rekursiv über Agenten hinweg angewendet.
Die Topologie
Interessant wird das durch die Richtung, in die es führt. Das Adressierungsmodell ist flach. clive@host ist eine Adresse. Jede per SSH erreichbare Maschine ist ein gültiger Host. Die Topologie ist das, was Ihre SSH-Konfiguration zulässt:
your laptop
└── tmux session "clive"
├── pane: shell (local)
├── pane: agent-devbox (ssh → devbox → clive)
├── pane: agent-gpu (ssh → gpu-cluster → clive)
└── pane: agent-prod (ssh → bastion → prod → clive)
Jeder entfernte Clive hat seine eigenen Werkzeuge, seine eigene Netzwerkposition, sein eigenes Dateisystem. Die GPU-Maschine hat CUDA. Der Produktionsserver hat Zugriff auf die Datenbank. Ihr Laptop hat Ihren Browser. Der äußere Clive orchestriert, jeder innere Clive führt mit dem aus, was lokal verfügbar ist.
Diese Multi-Agenten-Topologie ergibt sich von selbst, wenn Agenten in Terminals leben und SSH die Verbindung zwischen den Habitaten ist. Kein Service Mesh. Kein Agenten-Registry-Dienst. Kein Message Broker. Nur clive@host und die Unix-Werkzeuge, die seit dreißig Jahren sichere entfernte Ausführung erledigen.
Der Code liegt unter github.com/ikangai/clive.
Aus dem Englischen übersetzt: zum Originalbeitrag