Ein Statuscode ist keine Qualitätsaussage. Wenn ein klassischer Webservice mit 200 antwortet, war die Anfrage technisch erfolgreich – mehr sagt der Code nicht aus, aber bei deterministischer Business-Logik reicht das meistens. Bei einem KI-Agenten reicht es nicht: Der Agent kann ein Tool erfolgreich aufgerufen, eine Antwort erhalten und trotzdem die falsche Rückerstattungshöhe gewählt, die falsche Rechnung storniert oder eine E-Mail an den falschen Empfänger geschickt haben. Der HTTP-Call war einwandfrei. Die Entscheidung war es nicht.
Genau diese Lücke schließt Observability für Agenten. Sie ersetzt nicht klassisches Monitoring auf Basis von Prometheus und Grafana – sie ergänzt es um eine Ebene, die klassisches Monitoring naturgemäß nicht abdeckt: die semantische Korrektheit einer autonomen Entscheidung. Dieser Artikel ist Teil vier unserer Serie zu Agentic-AI-Infrastruktur und beschreibt, was auf der Observability-Schicht unserer Plattform tatsächlich passiert. Einen Überblick über alle fünf Schichten samt interaktiver Systemkarte finden Sie auf der Übersichtsseite.
Warum klassisches Monitoring bei Agenten nicht reicht
Klassisches Application-Monitoring beantwortet drei Fragen zuverlässig: Ist der Dienst erreichbar? Wie hoch ist die Latenz? Wie viele Anfragen scheitern mit einem Fehlercode? Für zustandslose, deterministische Services reicht das, weil dieselbe Eingabe immer dieselbe Ausgabe erzeugt – ein Fehler zeigt sich als Fehlercode, ein Erfolg als korrektes Ergebnis.
Ein KI-Agent bricht diese Annahme an zwei Stellen. Erstens ist die Ausgabe eines Sprachmodells auch bei identischer Eingabe nicht garantiert identisch. Zweitens trifft ein Agent Entscheidungen, die kein HTTP-Statuscode abbildet: welches Werkzeug er aufruft, mit welchen Parametern, ob er eskaliert oder selbst freigibt. Ein Dashboard, das nur „Anfragen pro Sekunde" und „Fehlerquote" zeigt, ist für diese Fragen blind.
In der Praxis: Ein Support-Agent, der bei jedem Lauf mit 200 antwortet, aber in 12 von 100 Fällen die falsche Rückerstattungssumme berechnet, sieht in klassischen Metriken aus wie ein gesundes System. Erst eine Eval-Suite, die das Ergebnis gegen ein bekanntes Goldset prüft, deckt das auf.
Die Konsequenz: Agenten brauchen eine zusätzliche Beobachtungsebene, die nicht nur technische Erreichbarkeit, sondern Entscheidungsqualität sichtbar macht. Das ist keine Kür für Enterprise-Betriebe, sondern die Grundvoraussetzung, um einen Agenten überhaupt produktiv laufen zu lassen, ohne blind zu sein.
OpenTelemetry-Spans je Tool-Call
Wie Tool-Aufrufe eines Agenten technisch angebunden werden, beschreiben wir ausführlich im Artikel zur Agentic-AI-Systemintegration. Die Beobachtungs-Grundlage dafür ist ein offener Standard: OpenTelemetry. Jeder Tool-Call, jeder Modellaufruf und jede Freigabeentscheidung eines Agenten erzeugt einen eigenen Span. Anders als bei klassischer Software reicht dabei ein generischer Span mit Dienstname und Latenz nicht – ein Agenten-Span muss zusätzlich die Attribute tragen, die eine Entscheidung nachvollziehbar machen.
Ehrlich: Instrumentierung, die nachträglich in bestehenden Code eingebaut wird, erfasst selten mehr als Latenz und Fehlercode. Agenten-Observability funktioniert nur, wenn die Spans von Anfang an mitgedacht werden – idealerweise durch ein Agent Gateway, das jeden Tool-Aufruf ohnehin durchleitet und dort automatisch instrumentiert.
Folgende Attribute gehören in jeden Span eines Tool-Calls, damit er sowohl für Fehlersuche als auch für Audit und Kostenzuordnung taugt:
- agent.id / agent.version: Welcher Agent, welcher Codestand hat gehandelt – Grundlage der Agenten-Identität
- prompt.version: Mit welcher Prompt-Fassung wurde entschieden – unverzichtbar, um eine Regression nach einer Prompt-Änderung zurückzuverfolgen
- run.id / step: Zuordnung zum Gesamtlauf und zur Position im Ablauf
- tool.name: Welches Werkzeug, über welchen MCP-Server
- tool.params_sanitized: Sanitisierte Parameter – Feldnamen und Typen bleiben, personenbezogene Klartextwerte werden gehasht oder entfernt
- tokens.in / tokens.out: Grundlage jeder Kostenzuordnung
- cost.eur: Kosten dieses einzelnen Aufrufs, berechnet aus Tokens und Modellpreis
- latency.ms: Wo die Zeit im Lauf tatsächlich hingeht
- error.type: Fehlerklassifikation für Alerting, falls der Aufruf scheitert
Diese Liste ist bewusst redundant zu dem, was ein Dashboard zur Kostensteuerung braucht – Traces und Kostenattribution laufen über denselben Datenstrom. Wer Kosten separat erfasst, bekommt am Monatsende Zahlen, die nicht zum tatsächlichen Trace passen.
Die Trace-Struktur eines Agenten-Laufs
Ein einzelner Agenten-Lauf ist kein flacher Log-Eintrag, sondern ein Baum aus Spans mit klarer Eltern-Kind-Beziehung. Der oberste Span agent.run umschließt den gesamten Vorgang, darunter hängt üblicherweise ein planner.plan-Span, der die Schrittfolge festlegt, gefolgt von einem oder mehreren tool.*-Spans für die tatsächlichen Aktionen. Dass ein Lauf nach einem Fehlschlag exakt an der richtigen Stelle fortgesetzt werden kann, statt von vorn zu beginnen, ist dabei kein Zufall, sondern Ergebnis der zugrundeliegenden Durable Execution – dazu mehr im ersten Artikel dieser Serie.
Entscheidend für die Fehlersuche: Ein fehlgeschlagener Versuch und der anschließende Retry sind zwei getrennte Spans, nicht ein überschriebener Eintrag. Nur so bleibt sichtbar, dass ein Endpunkt beim ersten Versuch instabil war, auch wenn der Lauf am Ende erfolgreich durchlief.
├─ planner.plan [142ms]
│ └─ model.call gpt-oss-120b · 890 tok
├─ tool.ticket_lookup [ok · 210ms]
├─ tool.mail.send [fehlgeschlagen · 502 upstream_timeout · 340ms]
├─ tool.mail.send [retry #1 · ok · 298ms]
└─ agent.finish [completed · 0,031 € · 4.590 tok]
Diese Baumstruktur beantwortet auf einen Blick drei Fragen: Wo im Ablauf ist Zeit vergangen, welcher Schritt ist gescheitert, und wie oft musste wiederholt werden, bevor der Lauf abgeschlossen war. Ohne getrennte Retry-Spans verschwindet genau diese Information – das Dashboard zeigt nur noch den erfolgreichen zweiten Versuch und damit ein zu optimistisches Bild der Systemstabilität.
Praxisbeispiel: Ein Lauf scheitert bei mail.send mit 502
Ein konkreter Ablauf zeigt, wie der Trace-Baum in der Fehlersuche tatsächlich genutzt wird. Ein Support-Agent soll nach Abschluss eines Tickets eine Bestätigungs-E-Mail versenden. Der Lauf schlägt beim ersten Versuch fehl, läuft aber nach einem automatischen Retry durch.
Schritt 1: Alarmierung durch die Fehlerquote, nicht durch einen Ausfall
Das Dashboard zeigt keinen kompletten Ausfall – der Lauf war am Ende erfolgreich. Was auffällt, ist eine erhöhte error.type=upstream_timeout-Rate auf dem Span tool.mail.send über die letzten zwei Stunden: 7 von 40 ersten Versuchen sind betroffen, alle wurden per Retry aufgefangen.
Schritt 2: Ein einzelner Lauf wird aufgeklappt
Im Trace-Baum von r-8f21c9 zeigt sich der fehlgeschlagene Span mit 340 ms Laufzeit und dem HTTP-Statuscode 502 im sanitisierten Parameterfeld. Direkt darunter folgt der Retry-Span mit identischen Parametern und Erfolg nach 298 ms – schneller sogar als der fehlgeschlagene Versuch, ein Hinweis auf eine kurzzeitige Überlast beim E-Mail-Provider, nicht auf ein grundsätzliches Problem.
Schritt 3: Muster statt Einzelfall
Die Frage ist nun nicht „warum ist dieser eine Lauf gescheitert", sondern „warum scheitert dieser Endpunkt regelmäßig beim ersten Versuch". Die Antwort liegt außerhalb des Agenten: Der E-Mail-Provider hat in einem bestimmten Zeitfenster erhöhte Latenz. Die Lösung ist kein Prompt-Fix, sondern ein Retry-Budget mit Backoff am Tool-Gateway und – falls die Rate weiter steigt – ein Gespräch mit dem Provider über dessen SLA.
Die meisten Mittelständler unterschätzen, wie oft ein Agenten-Problem in Wahrheit ein Integrationsproblem eines nachgelagerten Systems ist. Ohne den Retry als eigenen Span bliebe genau das unsichtbar – der Lauf sähe nur „erfolgreich" aus.
Deterministisches Replay: Was aufgezeichnet werden muss
Das klassische Debugging-Problem bei Agenten: Der Fehler tritt beim zweiten Versuch nicht mehr auf, weil das Modell eine andere Antwort liefert oder ein externes System inzwischen anders reagiert. Deterministisches Replay löst das, indem der komplette Lauf gegen aufgezeichnete Modell- und Tool-Antworten erneut abgespielt wird – ohne echte Aufrufe und ohne neue Kosten.
Damit Replay funktioniert, müssen mindestens folgende Daten je Lauf aufgezeichnet werden:
- Jede Modellantwort im Rohformat, inklusive verwendetem Modell und Temperatur
- Jede Tool-Antwort, inklusive Statuscode und Rohdaten vor der Sanitisierung
- Die Prompt-Version, mit der der Lauf tatsächlich ausgeführt wurde
- Alle Zufallsgrundlagen des Laufs, etwa Seeds oder Sampling-Parameter, soweit vom Modellanbieter verfügbar
Grenzen des Replay
Drei Grenzen gehören ehrlich dazu, nicht nur als Fußnote:
- Modell-Nichtdeterminismus: Auch bei Temperatur null liefern viele Sprachmodelle nicht garantiert dieselbe Ausgabe für dieselbe Eingabe – Batching-Effekte und Infrastrukturänderungen beim Anbieter spielen hinein.
- Modell-Updates: Ein Anbieter kann ein Modell austauschen, ohne die Versionsnummer sichtbar zu ändern. Replay gegen aufgezeichnete Antworten umgeht das Problem, weil es die alte Antwort erneut nutzt – zeigt damit aber auch, dass ein „Live-Nachstellen" desselben Fehlers mit dem aktuellen Modell nicht zuverlässig möglich ist.
- Externe Systeme: Ein Tool kann sich seit der Aufzeichnung geändert haben – neues Antwortschema, neuer Fehlercode, geänderte Geschäftslogik. Replay prüft die Entscheidungslogik des Agenten, nicht die Integration gegen die reale Außenwelt.
Ehrlich: Replay beweist, wie der Agent bei genau diesen aufgezeichneten Eingaben entschieden hat – nicht, dass er heute dieselbe Antwort träfe. Wer beides braucht, kombiniert Replay für die schnelle Fehlersuche mit einem echten Testlauf gegen ein Testsystem vor jedem größeren Rollout.
Eval-Harness in der CI
„Es lief einmal im Notebook" ist kein Deployment-Kriterium. Jede Änderung an Prompt, Modell, Policy oder Werkzeugliste sollte automatisiert gegen eine Suite aus echten Fällen laufen, bevor sie in Produktion geht – analog zu einer Testsuite in klassischer Softwareentwicklung, nur mit anderen Prüfkriterien.
Das Goldset
Ein Goldset ist eine Sammlung realer Fälle mit bekanntem, korrektem Ergebnis. Zum Start reichen 20 bis 30 Fälle, wenn sie echte Randfälle statt nur den Normalfall abdecken. Entscheidend ist nicht die Startgröße, sondern die Wachstumsregel: Jeder produktive Fehlschlag wird als neuer Fall aufgezeichnet und dem Goldset hinzugefügt. Nach einem halben Jahr Betrieb ist das Goldset oft der wertvollste Teil des gesamten Projekts – wertvoller als der ursprüngliche Prompt.
Regressionslauf vor jedem Prompt-Change
Ein Prompt-Change ohne Regressionslauf ist ein Blindflug. Die Suite läuft bei jeder Änderung automatisch gegen das komplette Goldset und meldet, welche vorher bestandenen Fälle jetzt scheitern – bevor ein Mensch das in Produktion bemerkt.
Maschinell prüfbare Erfolgskriterien
Ein Eval-Fall braucht ein Kriterium, das ein Skript auswerten kann, keine subjektive Einschätzung. Typische Prüfungen: Wurde genau das erwartete Werkzeug mit den erwarteten Parametern aufgerufen? Liegt der Status des Laufs im erwarteten Zustand? Liegen Kosten und Laufzeit innerhalb eines Grenzwerts? „Klingt die Antwort gut" ist kein Testkriterium – das ist eine Umfrage, kein automatisierbarer Regressionstest.
In der Praxis: Ein Eval-Fall, der prüft, ob eine Rückerstattung über dem Freigabelimit korrekt an einen Menschen eskaliert statt selbst freigegeben zu werden, ist wertvoller als zehn Fälle, die nur den reibungslosen Normalfall wiederholen. Der teuerste Fehler eines Agenten ist eine stille Selbstfreigabe, die nie hätte passieren dürfen.
Kennzahlen, die zählen
Ein Betrieb mit vielen Dashboards ist nicht automatisch ein gut beobachteter Betrieb. Vier Kennzahlen liefern den eigentlichen Steuerungswert, alle anderen sind meist Beiwerk:
- Erfolgsquote je Use Case: Anteil der Läufe, die ohne Eskalation und ohne Fehlschlag zum korrekten Ergebnis kommen – gemessen gegen das Goldset, nicht gegen ein Gefühl
- Kosten je erfolgreichem Task: Nicht Kosten je Lauf oder je Token, sondern die Gesamtkosten inklusive aller Fehlversuche und Retries, geteilt durch die Zahl der tatsächlich erfolgreichen Abschlüsse – die einzige Zahl, die sich fair mit den Kosten eines manuellen Prozesses vergleichen lässt
- Anteil Läufe ohne menschliches Zutun: Wie viele Läufe vollständig autonom abgeschlossen wurden, ohne Eskalation an einen Menschen – die eigentliche Automatisierungsquote
- p95-Laufzeit: Nicht der Durchschnitt, sondern der 95. Perzentilwert, weil er die tatsächliche Nutzererfahrung der langsamsten regelmäßig auftretenden Fälle zeigt
Kein sinnvolles Kriterium ist eine allgemeine „Zufriedenheit mit der Antwort" ohne definierten Maßstab – das lässt sich nicht automatisiert in der CI prüfen und eignet sich bestenfalls als ergänzende, manuell erhobene Stichprobe.
Logs, Metriken, Traces und Evals im Vergleich
Die vier Werkzeuge ergänzen sich, ersetzen sich aber nicht. Wer nur eines davon betreibt, hat eine blinde Stelle:
| Werkzeug | Zeigt | Beantwortet | Blinder Fleck |
|---|---|---|---|
| Logs | Einzelne Ereignisse als Text | „Was ist genau passiert?" | Kein Zusammenhang zwischen Ereignissen ohne manuelles Korrelieren |
| Metriken | Aggregierte Zahlen über Zeit | „Wie oft, wie schnell, im Durchschnitt?" | Kein Bezug zum Einzelfall, keine Entscheidungsqualität |
| Traces | Kausaler Ablauf eines Laufs als Span-Baum | „Wo im Ablauf ist was fehlgeschlagen?" | Zeigt was passiert ist, nicht ob das Ergebnis inhaltlich korrekt war |
| Evals | Ergebnis gegen bekannten Sollwert | „War die Entscheidung richtig?" | Nur so gut wie das Goldset, das sie prüft |
Für einen produktiven Agenten braucht es alle vier: Metriken für die Kapazitätsplanung, Logs für Detailfragen, Traces für die Fehlersuche im Einzellauf und Evals als einziges Werkzeug, das tatsächlich die inhaltliche Korrektheit einer Entscheidung prüft. Wer nur Metriken und Logs betreibt, hat klassisches Monitoring – aber keine Agenten-Observability.
Wann sich das nicht lohnt – und was Observability nicht ersetzt
Volle Observability mit Spans, Replay-Infrastruktur und einer wachsenden Eval-Suite ist Aufwand. Er lohnt sich nicht in jeder Situation:
- Reine Prototypen ohne Produktivbetrieb: Für einen Proof of Concept mit fünf Testläufen reicht ein einfaches Log – die volle Trace-Pipeline aufzubauen bindet Zeit, die in den eigentlichen Anwendungsfall fließen sollte.
- Sehr geringes Laufvolumen ohne Skalierungsplan: Bei wenigen Läufen pro Woche lässt sich jeder Fehlschlag manuell nachvollziehen, ohne dass sich eine Eval-Suite in der CI amortisiert.
- Agenten ohne Tool-Zugriff auf produktive Systeme: Ein rein beratender Agent ohne Schreibzugriff hat ein geringeres Schadenspotenzial – ein einfacheres Logging kann hier vorübergehend ausreichen.
Wichtige Klarstellung: Observability ersetzt keine Policy. Ein Trace zeigt nachträglich, was ein Agent getan und was es gekostet hat – er verhindert nichts von selbst. Ob ein Agent eine Rückerstattung über einem Limit selbst freigeben darf, entscheidet die Durchsetzung am Agent Gateway, nicht das Dashboard danach. Beobachtung und Durchsetzung sind zwei getrennte Schichten, die beide vorhanden sein müssen – mehr dazu in unserem Artikel zu Agent Identity und Least Privilege sowie zu Schatten-KI und Agenten-Sicherheit.
Auch regulatorisch ist Observability kein Freifahrtschein: Sie liefert die Nachweise, die EU-AI-Act-Pflichten zu Protokollierung und Nachvollziehbarkeit verlangen, ersetzt aber nicht die eigentliche Risikoklassifizierung oder DSGVO-Bewertung eines Agenten-Einsatzes. Wie wir Nachweispflichten, Zertifizierung und Auftragsverarbeitung dokumentieren, zeigt die Trust-Seite der Plattform.
Wer den Aufbau selbst in die Hand nimmt, findet den technischen Einstieg im Quickstart. Für Unternehmen, die Observability, Runtime und Tool-Layer lieber als Managed Service beziehen, bündeln wir das in KI Managed Services oder – bei Anforderungen an vollständige Datenhoheit – in On-Premise-KI-Betrieb. Wer eine komplette KI-Infrastruktur aus einer Hand sucht, dem beschreibt KI Full-Stack Providing das Gesamtpaket.
Häufig gestellte Fragen
Reicht klassisches Application-Monitoring nicht für KI-Agenten aus?
Nein. Ein Agenten-Lauf kann mit HTTP 200 und niedriger Latenz durchlaufen und trotzdem die falsche Entscheidung treffen – etwa eine Rückerstattung in falscher Höhe. Klassisches Monitoring prüft technische Erreichbarkeit, nicht Entscheidungsqualität. Dafür braucht es Spans mit Agenten-Identität, Tool-Parametern und Policy-Entscheidung sowie eine Eval-Suite gegen ein Goldset.
Was genau steht in einem OpenTelemetry-Span für einen Tool-Call?
Mindestens Agenten-ID und -Version, Prompt-Version, Lauf-ID und Schrittnummer, Werkzeugname, sanitisierte Parameter, Latenz, Token-Verbrauch, Modellname und Cache-Treffer sowie im Fehlerfall eine Fehlerklasse. Diese Attribute sind Grundlage für Fehlersuche, Audit und Kostenzuordnung gleichermaßen.
Was muss für ein deterministisches Replay aufgezeichnet werden?
Jede Modellantwort, jede Tool-Antwort, die verwendete Prompt-Version und die Temperatur beziehungsweise Zufallsgrundlagen des Laufs. Replay spielt den Lauf gegen diese aufgezeichneten Antworten erneut ab, ohne echte Aufrufe und ohne neue Kosten.
Wo liegen die Grenzen von deterministischem Replay?
Modell-Nichtdeterminismus auch bei Temperatur null, Modell-Updates des Anbieters ohne sichtbare Versionsänderung, und externe Systeme, die sich seit der Aufzeichnung geändert haben. Replay prüft die Entscheidungslogik gegen aufgezeichnete Antworten – es ersetzt keinen echten Testlauf gegen ein Testsystem.
Was ist ein Goldset und wie groß muss es sein?
Ein Goldset ist eine Sammlung realer Fälle mit bekanntem, korrektem Ergebnis. Zum Start reichen 20 bis 30 Fälle mit echten Randfällen. Entscheidend ist, dass jeder produktive Fehlschlag als neuer Fall aufgenommen wird.
Welche Kennzahlen sollte man für KI-Agenten wirklich verfolgen?
Erfolgsquote je Use Case, Kosten je erfolgreichem Task inklusive Fehlversuchen und Retries, Anteil der Läufe ohne menschliches Zutun und die p95-Laufzeit. Eine subjektive Zufriedenheit mit der Antwort ist kein automatisiert prüfbares Kriterium.
Muss ein fehlgeschlagener Tool-Call, der nach Retry durchläuft, überhaupt auffallen?
Ja. Ohne eigenen Span für den fehlgeschlagenen Versuch bleibt die Instabilität des aufgerufenen Systems unsichtbar – ein Dashboard zeigt sonst nur den erfolgreichen zweiten Aufruf.
Ersetzt Observability eine Policy für Agenten-Handlungen?
Nein. Observability macht sichtbar, was ein Agent getan hat – sie verhindert nichts von selbst. Ob eine Handlung erlaubt ist, entscheidet die Policy am Agent Gateway, nicht das Trace-Dashboard danach.
Rechenbeispiel (Annahme): Ein Support-Agent mit 4.590 Tokens pro erfolgreichem Lauf und einem Retry-Anteil von 15 % kostet bei einem angenommenen Modellpreis rund 0,031 € je Lauf und 0,047 € je erfolgreichem Task – inklusive der Fehlversuche. Reale Werte hängen von Modellwahl, Cache-Trefferquote und Retry-Rate ab und sind Teil des Sandbox-Angebots von HostSpezial.