Observability für KI-Agenten ist der Prozess, laufende Aktivitäten zu erfassen und zu bewerten, um nachzuvollziehen, zu messen und zu verstehen, wie ein KI-Agent Entscheidungen trifft und handelt. Sie beantwortet, ob der Agent das richtige Ergebnis erzielt hat und welcher Schritt den Fehler verursacht hat – nicht nur, ob der Durchlauf eine Antwort zurückgegeben hat.
Es gibt drei Wege, über die das Monitoring von KI-Agenten funktioniert:
- Application Performance Monitoring (APM): Überwacht die Infrastruktur, auf der ein Agent läuft, und meldet Latenz und Fehlerrate.
- LLM-Observability: Sie protokolliert einzelne Modellaufrufe und erfasst dabei den gesendeten Prompt und die jeweils zurückgegebene Completion
- Agenten-Observability: Erfasst die Reihenfolge, in der der Agent seine Entscheidungen getroffen hat, sodass ein Fehler in einem Schritt auf den auslösenden Schritt zurückverfolgt werden kann.
Warum scheitert klassisches Monitoring bei Agenten?
Klassisches Monitoring stützt sich auf Infrastrukturüberwachung und die Protokollierung einzelner Modellaufrufe und funktioniert bei KI-Agenten nicht, weil es jeden Schritt isoliert erfasst. Agenten durchlaufen mehrstufige Sequenzen, in denen ein einzelner Schritt fehlerhafte Daten zurückgeben kann, ohne eine Ausnahme auszulösen. Standard-Tools protokollieren einen erfolgreichen Statuscode, aber die ungültigen Daten fließen in die nachfolgenden Schritte weiter.
Beispiel: In Schritt 3 liest ein Agent einen veralteten Kontostand aus einer Datenbank. Die Datenbank liefert gültige Daten, also protokolliert das Monitoring-System eine erfolgreiche Anfrage. In Schritt 10 nutzt der Agent genau diesen Wert, um einem Kunden einen Kontostand zu nennen.
Das System formatiert die Antwort und schließt die Aufgabe ab, ohne einen Fehler auszulösen. Da die Schritte 3 und 10 beide ohne Systemausnahme abgeschlossen wurden, protokolliert das Monitoring-Tool den gesamten Durchlauf als erfolgreich. Der falsche Kontostand geht hinaus – und niemand bemerkt es, bis eine externe Prüfung es aufdeckt.
Dies sind die fünf Ausführungsmechaniken eines Agenten, an denen Monitoring auf Einzelanfragen-Ebene scheitert:
- Nicht-Determinismus: Der Agent wiederholt sich nicht: Dieselbe Anfrage durchläuft beim zweiten Mal eine andere Schrittfolge. Ein einzelner aufgezeichneter Durchlauf sagt Ihnen also nicht, wie sich der Agent verhält.
- Zustand über mehrere Turns: Fehler und Auswirkung liegen weit auseinander – ein früh im Gespräch entstandener Fehler führt viele Turns später zum falschen Ergebnis.
- Tool-Aufrufe mit Seiteneffekten: Manche Schritte lassen sich nicht rückgängig machen: Der Agent schreibt in ein führendes System, während der Durchlauf noch läuft. Dieser Schreibvorgang ist nicht immer umkehrbar.
- Übergaben zwischen Sub-Agenten: Arbeit wird zwischen Agenten weitergereicht – und wenn die Übergabe nicht aufgezeichnet wird, lässt sich die Reihenfolge, in der die beiden Agenten gehandelt haben, nicht rekonstruieren.
- Fehler, die wie Erfolge aussehen: Der Durchlauf des Agenten endet und die Ausgabe wirkt gültig, doch die gestellte Aufgabe bleibt unerledigt.
Was getract werden sollte
Observability für Agenten erfordert zwei getrennte Mechanismen: das Aufzeichnen der Ausführungshistorie eines Durchlaufs und die Bewertung, ob diese Aktionen zu einem korrekten Ergebnis geführt haben. Die Ausführungshistorie bildet den Trace, während automatisierte Bewertungsfunktionen eine Evaluierungsebene bilden.
Trace-Struktur und Spans
Ein Trace ist das vollständige Protokoll einer einzelnen Agentenausführung. Jede einzelne Aktion, die während dieses Durchlaufs zur KI-Observability beiträgt, wird als Span erfasst.
Ein Span steht für eine einzelne Arbeitseinheit und speichert Startzeit, Ausführungsdauer und Ausgabedaten dieser konkreten Aktion. Zudem halten Spans eine Eltern-Kind-Hierarchie ein, um die logische Reihenfolge zu bewahren.
Agenten-Trace und -Span
Wenn beispielsweise ein Modellaufruf entscheidet, eine Datenbankabfrage auszuführen, wird der Span der Datenbankabfrage im übergeordneten Reasoning-Span verschachtelt. Diese Hierarchie erlaubt es technischen Teams, eine falsche Endantwort bis zu genau dem früheren Schritt zurückzuverfolgen, der ungültige Daten erzeugt hat.
Die Ergänzung definiert einen Span darüber, was er ist (eine Arbeitseinheit), was er enthält (Startzeit, Dauer, Ergebnis) und warum die Eltern-Kind-Reihenfolge wichtig ist (ein Tool-Aufruf ist in dem Schritt verschachtelt, der ihn ausgelöst hat). Diese Verschachtelung ermöglicht es, von einer falschen Antwort zum verursachenden Schritt zurückzugehen.
Bewertungen auf Schritt- vs. Trace-Ebene
Ein vollständiger Trace zeigt Ihnen, was passiert ist – aber nicht, ob das Geschehene korrekt war. Das ist Aufgabe der Evaluierungsebene, die den Durchlauf auf zwei Ebenen bewertet.
- Bewertungen auf Schrittebene: Prüfen einzelne Aktionen, etwa ob der Agent das passende Tool für eine Anfrage ausgewählt oder relevante Dokumentation aus einer Datenbank abgerufen hat.
- Bewertungen auf Trace-Ebene: Bewerten die gesamte Ausführungskette, um festzustellen, ob der Agent die Gesamtaufgabe erfüllt hat.
Telemetrie-Standards
Die semantischen Konventionen von OpenTelemetry GenAI sind der herstellerneutrale Benennungsstandard für Agenten-Telemetrie. Sie geben Modellaufrufen, Tool-Aufrufen und Ausführungsmetriken dieselben Feldnamen – unabhängig davon, welches Tool sie erfasst. Die Konventionen befinden sich noch in Entwicklung und sind nicht stabil, daher ist mit Änderungen der Feldnamen zu rechnen.
Ein Team, das Telemetrie im OpenTelemetry-Format statt im Format eines einzelnen Anbieters erfasst, kann seine Trace-Daten in einem portablen Format vorhalten. Das Team kann Tools für KI-Observability wechseln oder ein zweites ergänzen, ohne zu ändern, wie jeder agent Telemetrie erfasst. Anbietervergleiche lassen den Standard meist außen vor, denn ein gemeinsames Format macht ihre Produkte austauschbar.
So gliedert sich das Tooling für Agenten-Observability
Tools für Agenten-Observability lassen sich in vier Kategorien einteilen, die sich darin unterscheiden, wo das Tool läuft und welche Fragen es beantworten soll – nicht darin, welches das beste ist.
Jedes unten aufgeführte Tool überwacht einen agent, den ein Team selbst erstellt hat und selbst betreibt. Keines davon erstellt den agent oder betreibt ihn. Das ist der wesentliche Unterschied zwischen einem Observability-Tool und einer Plattform mit integrierter Observability – und er entscheidet darüber, wonach Kaufende tatsächlich suchen.
| Category | Example tools | Best at | Weak at |
|---|---|---|---|
| Evaluation-first platforms | Braintrust, DeepEval (Confident AI), Maxim | Scoring whether the agent did the right thing | Running as a high-volume trace backend |
| Open-source, self-hosted tracing | Langfuse, Arize Phoenix, Traceloop OpenLLMetry | Data residency and full control | You run and scale the storage yourself |
| APM tools extended for LLMs | Datadog, New Relic, Dynatrace | One platform for agents and infrastructure | Lighter evaluation depth |
| Enterprise governance and control planes | Fiddler, Arize AX, WhyLabs | Audit trails and compliance reporting | Heavier to adopt for one agent |
Evaluationsorientierte Plattformen
Diese Plattformen setzen bei der Evaluation an und ergänzen das Tracing darum herum. Das zentrale Objekt ist eine Testsuite, die prüft, ob der agent das korrekte Ergebnis erzielt hat; die Trace-Ansicht dient dazu, einen negativen Score zu erklären.
Braintrust, das im Februar 2026 eine Series B über 80 Mio. $ für den Ausbau von KI-Observability aufnahm, DeepEval von Confident AI und Maxim arbeiten alle nach diesem Prinzip.
Solche Plattformen sind stark darin, aus „der agent liegt manchmal falsch“ ein Bestanden oder Nicht-bestanden gegenüber einem von Ihnen definierten Kriterium zu machen – und fangen so eine Regression ab, bevor sie in die Produktion gelangt.
Open-Source-Tracing zum Selbsthosten
Solche Tools sind darauf ausgelegt, Traces in der von Ihnen selbst betriebenen Infrastruktur zu erfassen und zu speichern, instrumentiert nach offenen Standards. Die Trace-Daten verlassen Ihre Umgebung nie. Langfuse, das ClickHouse im Januar 2026 übernommen hat, Arize Phoenix und Traceloops OpenLLMetry sind die gängigen Vertreter, und alle drei setzen auf OpenTelemetry auf.
Sie passen, wenn die Datenresidenz die Kaufentscheidung bestimmt und wenn Sie eine Instrumentierung wollen, die sich später auf ein anderes Tool übertragen lässt. Die Kosten sind operativer Natur, denn Sie sind selbst für Bereitstellung, Betrieb und Skalierung des Speichers verantwortlich. Zudem können die Funktionen für Evaluation und Governance so unterschiedlich ausfallen, dass ein Team sie häufig aus mehreren Projekten zusammenstellt.
Für LLMs erweiterte APM-Tools
Das sind die Application-Monitoring-Plattformen, die ein Team ohnehin betreibt, um Agenten-Spans zusammen mit den seit jeher erfassten Infrastrukturmetriken aufzuzeichnen. Datadog Agent Observability erfasst sieben Span-Arten und unterstützt die OpenTelemetry-GenAI-Konventionen. New Relic vermarktet seine Variante als erstes APM für KI, und Dynatrace nimmt Agenten-Traces über OpenTelemetry auf.
Das sind die idealen Tools, wenn Sie eine einzige Plattform für den agent und die Dienste darunter wollen und wenn es günstiger ist, Agenten zu einem bestehenden Vertrag hinzuzufügen, als einen neuen Anbieter zu onboarden.
Governance- und Control-Plane-Lösungen für Großunternehmen
Diese Plattformen behandeln Trace und Evaluation als Nachweis für Governance, nicht nur als Debugging-Hilfe. Ihr Unternehmen kann damit Audit-Trails und Zugriffskontrollen auf Tracing und Scoring aufsetzen. Zudem sind sie leistungsfähig bei der Erstellung von Compliance-Berichten. Fiddler, das sich selbst als AI Control Plane für Agenten in Großunternehmen positioniert, sowie Arize AX und WhyLabs arbeiten auf dieser Ebene.
Für wen sich eine Plattform mit integrierter Observability eignet
Eine Plattform mit bereits enthaltenem Monitoring zu kaufen, eignet sich für Großunternehmen, die fertige Agenten dem Eigenbau von Grund auf vorziehen. Wenn ein Team eine einsatzbereite Agenten-Belegschaft kauft, entfällt durch integriertes Trace-Logging und integrierte Evaluation der Aufbau einer separaten Monitoring-Pipeline.
Observability selbst aufzubauen bedeutet, für jeden workflow das korrekte Verhalten zu definieren. Das heißt, diese Workflow-Regeln zu schreiben und die Testsuite bei jeder Änderung eines agent zu aktualisieren. Das ist laufender Personalaufwand im Engineering, keine einmalige Anschaffung.
Wer am meisten von integrierter Observability profitiert
- Nicht-technische Kaufende in Großunternehmen: Das Team muss kein spezialisiertes Monitoring-Personal einstellen, da Trace-Logging und Leistungsbewertung bereits in die Ausführungsplattform integriert sind.
- Regulierte Unternehmen: Organisationen aus Banken, Telekommunikation, Luftfahrt oder Energieversorgung erhalten Audit-Trails und Evaluationsnachweise, die sofort für Compliance-Prüfungen bereitstehen.
- Operative Führungskräfte wie COO oder CFO können überprüfen, ob der agent die zugewiesene Aufgabe gelöst hat – und nicht nur, ob ein Durchlauf fehlerfrei endete.
HappyRobot steht hier für das Plattformmodell, denn seine Evaluations-Engine, Adversarial Testing, und Audit-Trails sind Teil der Plattform, die die Agenten betreibt. Statt dass ein Team separate Monitoring-Software in seine Workflows einbindet, verbindet HappyRobot agentische KI mit deterministischer Logik, um Evaluation und Compliance für genau die Agenten bereitzustellen, die darin laufen.
Darüber hinaus gibt es Northstars in HappyRobot – auditierbare Regeln, die das korrekte Verhalten jedes agent definieren und gegen die die Plattform Prüfungen durchführt. Sie legen fest, was korrektes Verhalten ist, und die Audits und Tests werden daran gemessen.
