Agenten-Kommunikation & Observability: warum stille Fehler gefährlich sind

Die KI-Agenten-Teams hinter bernd-zuther.de und ketovavaria.de stimmen sich über zwei Kanäle ab: einen schnellen Nachrichtenkanal für den laufenden Dialog und ein gemeinsames Austauschverzeichnis im Dateisystem für dauerhafte Übergaben. Im Alltag funktioniert das gut. Eine Beobachtung aus dem Betrieb hat aber gezeigt, wo die Schwachstelle liegt: Ein Nachrichtenkanal kann ausfallen, ohne dass es jemand merkt.

Zwei Kanäle für die Agenten-Kommunikation

Wenn mehrere KI-Agenten an verschiedenen Websites und Aufgaben arbeiten, müssen sie Informationen austauschen: Übergaben, Rückfragen und Statusmeldungen. Dafür nutzen die Agenten-Teams hinter bernd-zuther.de und ketovavaria.de zwei Wege. Über einen Nachrichtenkanal laufen Meldungen direkt zwischen den Teams. Parallel dazu gibt es ein gemeinsames Austauschverzeichnis im Dateisystem, in dem Übergaben als Dateien abgelegt werden. Welche konkreten Dienste dahinterstehen, ist ein reines Implementierungsdetail und für das eigentliche Thema dieser Seite nicht entscheidend.

Die beiden Kanäle haben unterschiedliche Stärken. Der Nachrichtenkanal ist schnell und eignet sich für den laufenden Dialog. Das Austauschverzeichnis ist langsamer, dafür aber dauerhaft: Was dort liegt, lässt sich später noch nachlesen und nachvollziehen. Dass beide Wege parallel bestehen, war im Alltag praktisch. Wie wichtig das ist, hat sich aber erst bei einer Betriebsbeobachtung gezeigt.

Die Beobachtung: Ein Kanal, der einfach schweigt

Im laufenden Betrieb ist aufgefallen, dass ein Nachrichtenkanal zeitweise keine Meldungen mehr übertragen hat. Es gab dabei keine Fehlermeldung, keinen Alarm und keinen Absturz. Die Arbeit lief einfach weiter, als wäre alles in Ordnung.

Genau das macht die Beobachtung lehrreich. Der Kanal ist nicht laut ausgefallen. Er hat einfach nichts mehr gesagt. Ein Agent, der keine Nachricht bekommt, kann nicht unterscheiden, ob es nichts zu sagen gab oder ob der Kanal tot ist.

Laute und stille Fehler

Grob lassen sich Fehler in zwei Gruppen einteilen. Laute Fehler machen sich sofort bemerkbar: ein Prozess stürzt ab, eine Fehlermeldung erscheint, ein Dienst ist nicht erreichbar. Sie sind ärgerlich, aber ehrlich, denn man weiß sofort, dass etwas zu tun ist.

Stille Fehler sind tückischer. Das System läuft scheinbar normal weiter, nur ein erwartetes Signal bleibt aus. So ein Fehler bleibt liegen, bis er an anderer Stelle Folgen hat, und dann ist die eigentliche Ursache oft schwer zu finden. Für ein System, in dem sich autonome Agenten auf Rückmeldungen voneinander verlassen, ist das besonders gefährlich. Kein Mensch sitzt daneben und wundert sich, dass es so ruhig ist. Die Agenten setzen ihre Arbeit fort und gehen dabei von Annahmen aus, die längst nicht mehr stimmen.

Warum Observability bei Multi-Agenten-Systemen entscheidend ist

Klassisches Monitoring prüft oft nur, ob ein Dienst läuft. Bei einem schweigenden Kanal reicht das nicht, denn der Dienst kann formal laufen und trotzdem nichts übertragen. Observability heißt hier vor allem: Das Ausbleiben eines erwarteten Signals muss selbst zu einem Signal werden. Wer nur auf Fehlermeldungen wartet, übersieht genau die Fehler, die keine erzeugen.

Je autonomer Agenten arbeiten, desto wichtiger wird das. Wenn Menschen nicht mehr jede Übergabe selbst prüfen, muss das System sichtbar machen, ob die Kommunikation zwischen den Agenten noch funktioniert.

Redundanz hat die Zusammenarbeit getragen

Dass die Zusammenarbeit trotz der Störung weiterlief, lag am zweiten Kanal. Das Austauschverzeichnis im Dateisystem blieb nachvollziehbar, auch als der Nachrichtenkanal schwieg. Die Übergaben dort waren weiterhin vorhanden und lesbar. Daraus folgt eine einfache Lehre: Ein zweiter, unabhängiger Kommunikationsweg verhindert keine Störung, aber er sorgt dafür, dass eine Störung nicht gleich alles lahmlegt.

Aktueller Stand: Beobachtung statt Einsatz

Redundanz allein löst das eigentliche Problem nicht, denn die Störung wurde nur zufällig bemerkt. Deshalb arbeite ich daran, ein ausbleibendes Signal selbst sichtbar zu machen, statt mich darauf zu verlassen, dass es irgendwann auffällt. Bis das zuverlässig klappt, bleibt die Agenten-Kommunikation im Technologie-Radar auf Beobachtung und wird noch nicht als verlässlicher Baustein eingesetzt.

Abgrenzung zu MCP

Das Model Context Protocol (MCP) und dieser Nachrichtenkanal lösen unterschiedliche Probleme, auch wenn beide mit KI-Agenten zu tun haben. MCP standardisiert, wie ein Agent strukturiert auf Werkzeuge und Datenquellen zugreift: Client-Server-Verbindung, definierte Tool-Schnittstellen, ein Agent ruft ein Werkzeug auf und bekommt ein strukturiertes Ergebnis zurück. Es ist die Schicht zwischen einem einzelnen Agenten und seinen Fähigkeiten.

Hier geht es um etwas anderes: die Abstimmung zwischen mehreren getrennten, autonomen Agenten-Teams, die an unterschiedlichen Projekten arbeiten und sich gegenseitig Übergaben, Rückfragen und Statusmeldungen zukommen lassen – asynchron, nicht als einzelner Tool-Aufruf, sondern als fortlaufender Dialog zwischen Teams. MCP würde ich nutzen, damit ein einzelner Agent etwa auf eine Datenbank oder einen Such-Index zugreifen kann. Der hier beschriebene Nachrichtenkanal plus das Dateisystem-Austauschverzeichnis lösen die Koordination auf einer Ebene darüber: Team-zu-Team statt Agent-zu-Werkzeug. Beide Schichten ergänzen sich, ersetzen sich aber nicht gegenseitig.