Agenten-Observability: sehen, was ein KI-Agent in Echtzeit tut

Je mehr Autonomie ein KI-Agent gewinnt, desto zentraler wird die Frage "was genau hat er getan?". Ein Agent, der dauerhaft läuft, über mehrere Kanäle angesprochen wird, Werkzeuge aufruft und manchmal an Unteragenten delegiert, erzeugt eine Aktivität, die sich mit bloßem Auge schwer verfolgen lässt. Observability ist die technische Antwort auf dieses Problem: sichtbar, nachvollziehbar und verständlich machen, was tatsächlich im Inneren des Systems geschieht.

Definition im Detail

Observability, im weiten Sinne der Softwaretechnik, ist die Fähigkeit, den inneren Zustand eines Systems zu verstehen, indem man betrachtet, was es nach außen produziert, typischerweise Traces, Metriken und Protokolle (Logs). Das ist die Definition, die OpenTelemetry verwendet, der offene Referenzstandard für Software-Instrumentierung, getragen von zahlreichen Anbietern von Observability-Werkzeugen. Diese drei Datentypen erfüllen ergänzende Rollen: Traces verfolgen eine Anfrage entlang ihres Wegs durch ein verteiltes System, Protokolle erfassen zeitgestempelte Ereignisse, verknüpft mit einer bestimmten Anfrage oder nicht, und Metriken aggregieren gemessene Zahlen über die Zeit.

Agenten-Observability wendet dasselbe Prinzip auf den spezifischen Fall eines autonomen KI-Agenten an. Es gibt noch keinen einzigen, breit stabilisierten Standard, der präzise festlegt, was agentische Observability abdecken muss, anders als die klassische Software-Observability, die von einem ausgereiften Standard wie OpenTelemetry profitiert. In der Praxis konvergieren die Plattformen, die Agenten betreiben, jedoch zu gemeinsamen Bedürfnissen: wissen, welche Aktion ein Agent ausgeführt hat, auf welchem Werkzeug, zu welchem Zeitpunkt, mit welchem Ergebnis, und auf Initiative welches Auslösers (ein Gespräch, eine E-Mail, eine geplante Aufgabe).

Das ist kein technischer Luxus, der großen Teams vorbehalten ist. Sobald ein Agent handeln kann, ohne bei jedem Schritt systematisch validiert zu werden, wird Observability zur konkreten Art, die Frage "warum hat er das getan?" im Nachhinein zu beantworten oder ein anormales Verhalten zu erkennen, bevor es ein echtes Problem verursacht.

So funktioniert es

Konkret stützt sich die Observability eines Agenten auf drei übereinanderliegende Schichten. Die erste ist die Erfassung von Ereignissen: jede Entscheidung, jeder Werkzeugaufruf, jeder bedeutsame Schritt der Argumentation wird in dem Moment protokolliert, in dem er auftritt, mit Zeitstempel, Status (laufend, erfolgreich, fehlerhaft) und Ursprung des Auslösers. Die zweite ist die Strukturierung: Diese Rohereignisse werden kategorisiert (eine Dateiaktion wird nicht wie ein Aufruf eines externen Werkzeugs oder ein Argumentationsschritt des Modells protokolliert), damit man effizient filtern und suchen kann. Die dritte ist die Darstellung: eine Oberfläche oder ein Export, mit der eine Person diese Aktivität durchsehen kann, sei es für einen bestimmten Agenten oder für eine ganze Organisation.

Ein gutes System für agentische Observability unterscheidet auch delegierte Arbeit: Wenn ein Agent eine Teilaufgabe an einen kurzlebigen Unteragenten delegiert, muss diese Delegation in der Zeitleiste des übergeordneten Agenten sichtbar bleiben, sonst wird ein Teil der tatsächlichen Arbeit unsichtbar.

Konkretes Beispiel bei Atako

Bei Atako stützt sich die Observability pro Agent auf eine Aktivitäts-Timeline in Echtzeit: Jedes Ereignis ist dort kategorisiert (Web, Dateien, Gedächtnis, Code, Integration, Planung, Delegation, Argumentation des Modells, Sonstiges), mit einem Status (laufend, erfolgreich, fehlerhaft), einer Dauer und einem genauen Ursprung (Chat, E-Mail, Webhook, geplante Aufgabe, Nachricht zwischen Agenten, Unteragent oder System). Ein eigenes Panel, "Tool logs", listet separat jeden vom Agenten ausgeführten Integrationsaufruf mit seinem Ergebnis (Erfolg, Ablehnung, Fehler).

Diese Observability pro Agent wird durch eine unternehmensweite Ansicht ergänzt, Administratoren vorbehalten: eine Seite "Integration logs", filterbar nach Team, Agent, Anbieter und Datum, mit einem CSV-Export bis zu 50.000 Zeilen, sowie einer aggregierten Nutzungsansicht pro Integrationsanbieter. Jeder protokollierte Aufruf hält den betroffenen Agenten, die verwendete Verbindung, den Anbieter, die genaue Aktion, ihre Argumente (mit sensiblen Feldern wie dem Text einer E-Mail oder einer Suchanfrage, die systematisch maskiert werden), den Status, den vom Anbieter zurückgegebenen HTTP-Code, die Latenz und den Zeitstempel fest. Die Leitplanken der Berechtigung (die Grants) und die Observability arbeiten Hand in Hand: Das eine entscheidet, ob eine Aktion erlaubt ist, das andere hält fest, was tatsächlich geschehen ist.

Häufige Fehler

Ein häufiger Fehler besteht darin, Observability mit einem einfachen Fehlerprotokoll zu verwechseln. Ein observierbares System meldet nicht nur, wenn etwas kaputtgeht, es gibt auch Sichtbarkeit auf den normalen Betrieb, was erlaubt, ein unerwartetes Verhalten zu verstehen, selbst wenn technisch nichts fehlgeschlagen ist.

Zweiter Fehler: glauben, Observability verhindere, dass ein Agent falsch handelt. Es ist kein Blockademechanismus, es ist ein Sichtbarkeitsmechanismus. Sie kombiniert sich mit Berechtigungen und, bei sensiblen Aktionen, mit einem Punkt menschlicher Validierung, ersetzt aber keines von beidem.

Dritter Fehler: Observability nur Administratoren vorbehalten, ohne sie den Teams zugänglich zu machen, die den Agenten tatsächlich täglich nutzen. Eine nützliche Observability muss der Person, die einen Agenten erstellt hat oder nutzt, erlauben, sein Verhalten zu verstehen, nicht nur einer isolierten technischen Rolle.

Schließlich ist es ein klassischer Fehler, die Bedeutung von Delegationen an Unteragenten in der Aktivitäts-Zeitleiste zu unterschätzen. Ein Agent, der eine Teilaufgabe delegiert, bleibt aus Sicht des Nutzers weiterhin für das Ergebnis verantwortlich: Erscheint diese Delegation nicht klar in der Timeline, wird ein Teil der tatsächlichen Arbeit im Nachhinein unsichtbar und unverständlich.