Agent Observability

Agent Observability ist die Betriebs-Praxis, mit der Teams sichtbar machen, was ein KI-Agent im Live-Einsatz tut, welche Schritte er dabei geht, was er kostet und wie gut seine Antworten sind. Sie ergänzt die drei üblichen Betriebs-Sichten (Ablauf-Verfolgung, Kennzahlen, Protokolle) um vier Kern-Signale: Qualität (stimmen die Antworten), Kosten (welcher Aufruf verbrennt wie viel), Antwortzeit (wie schnell kommt eine Antwort) und Sicherheit (werden Regeln oder Datenschutz verletzt).

Was ist Agent Observability?

Agent Observability schließt eine Lücke, die klassisches Betriebs-Monitoring offen lässt. Das übliche Application Performance Monitoring (APM, die Betriebs-Sicht auf Web-Anwendungen und Microservices) misst technische Basiswerte wie HTTP-Status, Antwortzeit und Speicherverbrauch, gebaut für Systeme, die auf gleiche Eingabe immer gleich reagieren. Ein KI-Agent verhält sich anders: Er antwortet variabel (dieselbe Frage kann zwei unterschiedliche, gleich richtige Antworten erzeugen), ruft Werkzeuge in wechselnder Reihenfolge auf, startet Unter-Agenten, holt Wissen aus Datenquellen (Retrieval) und verursacht pro Aufruf Kosten in Form von Tokens (Text-Bausteine, mit denen das Sprachmodell abrechnet). Klassisches APM kennt weder Tokens noch die konkrete Werkzeug-Kette eines Agenten und hat kein Konzept für erfundene Antworten (Halluzinationen) oder für schleichenden Qualitätsverlust des Modells (Drift).

Der Aufbau ruht auf zwei Ebenen. Die erste Ebene sind die drei aus Cloud-native bekannten Säulen: Distributed Tracing erfasst jeden Agent-Lauf als Span-Baum mit Root-Span, LLM-Calls, Tool-Calls, Retrieval-Schritten und Sub-Agenten. Metrics aggregieren daraus die operativ relevanten Größen. Logs führen strukturierte Events mit Trace-ID und Span-ID, damit ein Vorfall aus der Metrik in die konkrete Trace navigierbar bleibt. Die zweite Ebene ist ein Signal-Modell aus vier Agent-spezifischen Klassen: Quality (Eval-Score-Trend, Halluzinations-Rate, Tool-Trajectory-Match), Cost (Tokens pro Call, Cost-per-Outcome, Modell-Mix), Latency (Time-to-First-Token, p95/p99 End-to-End) und Safety (Prompt-Injection-Versuche, PII-Verstöße, Guardrail-Trigger).

Der Begriff hat sich 2026 als eigenständige Disziplin im LLMOps-Umfeld etabliert. Das offene Fundament sind die OpenTelemetry GenAI Semantic Conventions, die Span-Attribute wie gen_ai.usage.input_tokens oder gen_ai.request.model standardisieren. Auf diesem Standard oder daneben setzen Plattformen wie Langfuse, LangSmith, Arize Phoenix, Datadog LLM Observability, Helicone, Braintrust und Laminar auf. Die AI-Act-Anforderungen an Aufzeichnung (Art. 12) und Post-Market-Monitoring (Art. 72) verankern Observability zusätzlich als Compliance-Pflicht für Hochrisiko-Systeme im DACH-Raum.

Abgrenzung zu Agent Tracing, Agent Evaluation und klassischem APM

Agent Observability wird häufig mit angrenzenden Disziplinen gleichgesetzt. Die Begriffe messen unterschiedliche Dinge und sitzen an unterschiedlichen Stellen im Betriebs-Stack.

Tracing liefert die Rohdaten, Observability das Signal-Modell darüber. Evaluation misst Qualität in einer separaten Pipeline und speist ihr Ergebnis als Quality-Signal in die Observability-Sicht ein. LLM Observability betrachtet einen einzelnen Modell-Aufruf isoliert, Agent Observability den gesamten Agent-Lauf inklusive Tool-Ketten und Multi-Step-Trajectories. Klassisches APM zeigt, dass der Agent läuft; es zeigt nicht, was er kostet oder ob er driftet.

Beispiel: Betrieb eines Customer-Support-Agenten

Ein produktiver Customer-Support-Agent instrumentiert seine Aufrufe über die OpenTelemetry GenAI Conventions. Jeder Lauf erzeugt einen Span-Baum: Root-Span für die Anfrage, Child-Spans für jeden LLM-Call, jeden Tool-Call (Ticket-Lookup, Wissensdatenbank-Suche) und jeden Retrieval-Schritt, mit Attributen für Modellname, Token-Verbrauch, Latenz und Tool-Argumente. Eine zentrale Observability-Plattform wie Langfuse oder Arize Phoenix nimmt die Spans entgegen und aggregiert daraus Metriken pro Endpoint und Zeitfenster.

Auf diesen Aggregaten laufen SLOs. Cost-per-Outcome pro Endpoint hat einen Tages-Cap; wird er überschritten, eskaliert der Alarm an FinOps und den Endpoint-Owner. Die Time-to-First-Token hat einen p95-Wert, der wie ein klassisches APM-Signal on-call weckt. Der Eval-Score aus einer parallelen Online-Evaluation läuft als Quality-Metrik mit; weicht der 24-Stunden-Median um mehr als fünf Prozent vom Vorwoche-Wert ab, landet ein Drift-Ticket beim Eval-Owner. PII-Verstöße und Prompt-Injection-Trigger aus Guardrails erzeugen strukturierte Log-Events mit Trace-ID, die sofort an Security eskalieren. Bei einem Vorfall verbindet die Trace-ID den Metrik-Ausschlag, die konkrete Anfrage und die auslösende LLM-Antwort in einer navigierbaren Sicht.