AI-Agent-Observability: Der Praxis-Guide fuer 2026

Ihr Agent ist bei Schritt 14 gescheitert. Welcher Schritt 14?

Ein einzelner LLM-Call ist einfach zu debuggen. Ein Prompt rein, eine Completion raus — beides loggen, das Paar ansehen, Problem gefunden.

Ein Agent ist ein anderes Kaliber. Eine Nutzeranfrage faechert sich auf in einen Planungs-Call, drei Tool-Calls, einen Retrieval-Schritt, zwei weitere Modell-Calls zur Synthese und irgendwo dazwischen einen Retry, weil ein Tool fehlerhaftes JSON zurueckgegeben hat. Wenn die finale Antwort falsch ist — oder der Run das 40-Fache des Erwarteten kostet — sagt Ihnen "wir loggen unsere Prompts" so gut wie nichts. Agent-Observability ist die Disziplin, diesen gesamten Ausfuehrungsbaum zu erfassen, um drei Fragen beantworten zu koennen: Was hat der Agent tatsaechlich getan, was hat es gekostet, und wo ist es schiefgelaufen?

Dieser Guide behandelt, was Sie erfassen sollten, die drei Instrumentierungs-Ansaetze im Jahr 2026 (SDK, OpenTelemetry, Gateway) und die zwei Fehlermodi, die die meisten Teams zu spaet entdecken: ausufernde Kosten und Traces voller personenbezogener Daten.

Was ist Agent-Observability?

Agent-Observability erweitert LLM-Observability von einzelnen Request/Response-Paaren auf vollstaendige mehrstufige Ausfuehrungen. Statt eines flachen Logs von API-Calls erhalten Sie einen Trace: einen Baum aus Spans, der jeden Schritt des Agenten abbildet — in Reihenfolge, mit Timing, Token-Zahlen und Ein-/Ausgaben.

Ein brauchbarer Trace fuer einen Agent-Run sieht so aus:

run: "Erstattung fuer Bestellung #8812"        6.2s   $0.0841
├── llm: naechste Aktion planen (gpt-5.6)      1.1s   1.204 Tok
├── tool: lookup_order(order_id="8812")        0.3s
├── llm: naechste Aktion planen (gpt-5.6)      0.9s   1.876 Tok
├── tool: refund_policy_search(query=...)      0.8s
├── llm: naechste Aktion planen (gpt-5.6)      1.0s   2.341 Tok
│   └── retry: Tool-Argumente ungueltig        +0.4s
├── tool: issue_refund(amount=49.00)           0.6s
└── llm: Antwort verfassen (gpt-5.6-luna)      1.1s   2.090 Tok

Der Unterschied zum klassischen LLM-Logging ist strukturell. Sie fragen nicht mehr "Wie lautete der Prompt?" — Sie fragen "Warum hat der dritte Planungs-Call entschieden, eine Erstattung auszuloesen, und welcher Kontext hatte sich bis dahin angesammelt?"

Konkret muss Agent-Observability Folgendes erfassen:

• +Die Schrittfolge — jeder Modell-Call und Tool-Call, Parent-Child-Beziehungen und Reihenfolge
• +Tool-Calls mit Argumenten und Ergebnissen — die Entscheidungen des Agenten sind nur erklaerbar, wenn Sie sehen, was seine Tools zurueckgegeben haben
• +Tokens und Kosten pro Schritt — Agenten multiplizieren Ausgaben; ein Trace, der Kosten nicht pro Schritt zuordnen kann, kann einen 600-Dollar-Tag nicht erklaeren
• +Latenz pro Schritt — Agenten fuehlen sich insgesamt langsam an; der Trace zeigt, ob es am Modell, einem Tool oder an Retry-Schleifen liegt
• +Fehler und Retries — fehlgeschlagene Tool-Calls, Schema-Validierungsfehler und die Korrekturversuche des Modells
• +Metadaten auf Run-Ebene — Nutzer, Session, Agent-Version, Prompt-Version, Umgebung

Warum Single-Call-LLM-Observability nicht reicht

Die meisten Teams starten mit Request-Logging — jeder OpenAI- oder Anthropic-Call wird irgendwo erfasst. Dann shippen sie einen Agenten und entdecken vier Probleme auf einmal.

Kosten sind nicht mehr linear. Ein Chat-Feature kostet pro Nachricht ungefaehr gleich viel. Die Kosten eines Agent-Runs variieren um eine Groessenordnung, je nachdem, wie viele Schritte er braucht. Schleifen sind der pathologische Fall: Ein Agent, der ein fehlschlagendes Tool immer wieder aufruft, sich entschuldigt und es erneut versucht, kann Tausende Calls verbrennen, bevor es jemand merkt. Flache Call-Logs zeigen steigendes Volumen — aber nicht, welche Runs in Schleifen liefen oder warum.

Fehler passieren mitten in der Trajektorie. In Produktion scheitern Agenten selten mit einer Exception. Sie scheitern, indem sie bei Schritt 6 falsch abbiegen und bei Schritt 14 selbstbewusst eine falsche Antwort liefern. Ohne den Trace beginnt Ihre Debugging-Session mit einer Nutzerbeschwerde und einem Haufen zusammenhangloser API-Logs.

Nichtdeterminismus potenziert sich. Ein Modell-Call ist nichtdeterministisch. Verketten Sie neun davon mit Tool-Calls dazwischen, kann derselbe Input strukturell voellig unterschiedliche Ausfuehrungen erzeugen. Sie koennen nicht ueber "das" Verhalten eines Agenten reden — nur ueber Verteilungen ueber echte Traces. Genau deshalb schlagen Evals auf echtem Traffic synthetische Testsets bei Agenten.

Der Explosionsradius ist groesser. Agenten bewegen deutlich mehr Daten als eine Chatbox. Sicherheitsforscher schaetzen, dass AI-Agenten rund 16-mal mehr Daten bewegen als menschliche Nutzer — jedes Tool-Ergebnis, jedes abgerufene Dokument, jede Datenbankzeile fliesst durch den Modellkontext. Das hat eine Sicherheitsdimension (siehe unser Beitrag zu AI-Agent-Datenlecks) und eine Observability-Dimension, zu der wir gleich kommen: Ihre Traces sind jetzt eine Kopie all dieser Daten.

Drei Wege, Agenten zu instrumentieren

2026 gibt es drei reale Ansaetze, und die meisten Anbieter sind um genau einen davon herum gebaut.

Die ehrliche Zusammenfassung: SDK-Instrumentierung liefert die tiefsten Traces fuer eine einzelne App, Gateway-Erfassung die breiteste Abdeckung fuer den geringsten Aufwand, und OTel ist das Austauschformat, das beides verbindet. LangSmith unterstuetzt inzwischen durchgaengiges OpenTelemetry, und die OTel GenAI Semantic Conventions sind das Naechste an einem branchenweit vereinbarten Schema fuer LLM-Spans.

Warum der Gateway-Ansatz gerade bei Agenten zaehlt

Hier ist die Eigenschaft, die Gateway-Erfassung fuer Agenten ungewoehnlich gut macht: Jeder Schritt eines Agenten, der Geld kostet oder eine Entscheidung trifft, ist ein LLM-API-Call — und jeder dieser Calls laeuft durch denselben Egress-Punkt.

Die Tool-Ausfuehrung passiert in Ihrem Code, aber die Tool-Auswahl — die Argumente, die das Modell gewaehlt hat, die Ergebnisse, die zurueck in den Kontext fliessen — ist in den Request/Response-Bodies der Modell-Calls selbst sichtbar. Ein Gateway sieht also die komplette Entscheidungssequenz des Agenten ohne eine einzige Zeile Instrumentierung:

• +Den Planungs-Call und seinen Output
• +Jeden Tool-Call, den das Modell angefordert hat, samt Argumenten
• +Jedes Tool-Ergebnis, weil es in den Messages des naechsten Requests auftaucht
• +Tokens, Kosten, Latenz und Fehler fuer jeden Schritt
• +Alles gruppiert zu einer Konversation ueber die Kontinuitaet der Message-History

Das ist auch der einzige Ansatz, der die organisatorische Realitaet ueberlebt. Ihr Unternehmen betreibt nicht einen Agenten — es betreibt einen LangGraph-Service, einen CrewAI-Prototyp, drei interne Skripte und Entwickler mit Coding-Agenten. Jeden davon mit einem SDK zu instrumentieren ist ein Projekt pro Codebase. Die Base-URL auf ein Gateway zu zeigen ist eine Konfigurationsaenderung pro Codebase — und ploetzlich hat die Finanzfrage ("Was haben uns Agenten diese Woche gekostet, pro Team?") eine Antwort an einem Ort. Falls das Konzept neu ist: Was ist ein AI-Gateway?

Die richtige Architektur fuer die meisten Teams ist hybrid: Gateway-Erfassung als dauerhafte Basis ueber alles hinweg, plus OTel-/SDK-Spans in den ein, zwei Agenten, die komplex genug fuer Custom-Instrumentierung sind.

Die Metriken, die wirklich zaehlen

Sobald Traces fliessen, widerstehen Sie dem Drang, alles in Dashboards zu giessen. Fuenf Metriken erklaeren das meiste Agent-Verhalten in Produktion:

• +Kosten pro Run (p50 / p95 / max) — das Verhaeltnis p95 zu p50 ist Ihr Schleifen-Detektor. Ein gesunder Agent liegt bei 2–3x; ein driftender Prompt oder ein wackliges Tool treibt es ueber 10x, bevor die Gesamtausgaben auffaellig werden.
• +Schritte pro Run — dasselbe Signal in struktureller Form. Alarmieren Sie auf Verschiebungen der Verteilung, nicht auf feste Schwellwerte.
• +Tool-Fehlerrate pro Tool — Agenten kaschieren fehlschlagende Tools durch Retries und Improvisation. Ein Tool mit 30 % Fehlerrate kann sich wochenlang hinter einem "funktionierenden" Agenten verstecken und dabei die Kosten verdreifachen.
• +Retry-Rate bei Modell-Calls — Schema-Validierungsfehler und fehlerhafte Tool-Argumente konzentrieren sich hier nach Modell- oder Prompt-Versionswechseln.
• +Trace-Abschlussrate — der Anteil der Runs, die einen Endzustand erreichen, statt in Schritt-Limits, Timeouts oder Budget-Caps zu laufen. Das ist Ihr bester Naeherungswert fuer "der Agent hat den Job tatsaechlich erledigt."

Auffaellig, was fehlt: aggregierte Token-Zahlen und Gesamtausgaben. Die zaehlen fuer die Rechnung, sind aber nachlaufende Indikatoren. Verteilungsverschiebungen in den fuenf Metriken oben sind die vorlaufenden.

Die zwei Probleme, die Agent-Traces erzeugen

Observability soll Risiken reduzieren. Naiv umgesetzt, schaffen Agent-Traces zwei neue.

1. Ihre Traces sind jetzt ein PII-Lager

Erinnern Sie sich an die 16-fache Datenbewegung. Agent-Traces erfassen Tool-Ergebnisse — CRM-Datensaetze, Support-Tickets, abgerufene Dokumente, Datenbankzeilen. All das landet woertlich in Ihrem Observability-Speicher. Ist dieser Speicher ein Dritt-SaaS, haben Sie eine Schattenkopie Ihrer sensibelsten Daten in einem System erzeugt, das in Ihrer Datenschutz-Folgenabschaetzung vermutlich nicht vorkommt.

Das ist das Observability-Paradox: Je vollstaendiger Ihre Traces, desto groesser Ihr Datenschutzproblem. Die Mechanik haben wir in Ihr LLM-Observability-Tool loggt PII beschrieben; bei Agenten sind Volumen und Sensibilitaet strikt schlimmer.

Die Loesung ist strukturell, nicht prozedural: PII schwaerzen, bevor sie gespeichert wird — idealerweise am selben Engpass, an dem die Traces erfasst werden. So bleiben Traces debugbar (konsistente Platzhalter wie [PERSON_1], [EMAIL_1] erhalten die referenzielle Struktur), ohne ein wartender Datenschutzvorfall zu sein.

2. Observability ohne Limits ist ein Dashboard fuer Katastrophen

Ein Trace, der zeigt, dass der Agent 400-mal in einer Schleife lief, ist nuetzlich. Ein Gateway, das ihn bei 50 Calls gestoppt haette, ist besser. Agent-Observability reift zu Agent-Kontrolle:

• +Budgets und harte Ausgabenlimits pro Agent, Team oder API-Key, damit eine Endlosschleife gegen eine Wand laeuft statt gegen Ihre Rechnung — siehe harte Ausgabenlimits
• +Tool-Call-Beschraenkungen, damit ein Agent, der per Prompt Injection zu delete_records verleitet wurde, am Egress-Punkt blockiert wird — siehe Agent-Tool-Calls einschraenken
• +Alarme auf Trace-Anomalien — verschobene Schrittzahlen, Retry-Raten und Kosten-pro-Run-Verteilungen sind Ihr fruehestes Signal, dass eine Prompt-Aenderung etwas kaputt gemacht hat

Wenn Ihre Observability-Schicht und Ihre Kontrollschicht dieselbe Schicht sind, ist der Weg von "erkannt" zu "verhindert" eine Policy — kein teamuebergreifendes Projekt.

Wie Grepture hilft

Grepture ist ein AI-Gateway — also der oben beschriebene Engpass-Ansatz, mit zwei Modi, je nachdem, wie viel Kontrolle Sie im Hot Path wollen.

Der Proxy-Modus routet Agent-Traffic durch Grepture: vollstaendige Traces, gruppiert nach Konversation, Tokens/Kosten/Latenz pro Schritt, plus Durchsetzung — PII-Schwaerzung, bevor irgendetwas gespeichert oder an einen Anbieter gesendet wird, Budgets mit harten Caps und Tool-Call-Beschraenkungen.

Der Trace-Modus ist fuer latenzsensitive Agenten: Requests gehen direkt an Ihren Anbieter, das SDK erfasst Metadaten asynchron — gleiches Dashboard, null zusaetzliche Latenz in der Agent-Schleife.

In beiden Faellen bekommen Sie agentengerechte Antworten, ohne jedes Framework zu instrumentieren: welche Runs in Schleifen liefen, was jeder Schritt gekostet hat, was das Modell sah, als es die falsche Entscheidung traf — mit bereits maskierter PII im Trace. Das Setup ist eine Base-URL-Aenderung; der Monitoring- und Logging-Guide fuehrt Sie durch.

Die wichtigsten Erkenntnisse

• +Agent-Observability heisst Traces, nicht Logs — erfassen Sie den vollen Ausfuehrungsbaum (Modell-Calls, Tool-Calls, Retries) mit Kosten und Latenz pro Schritt, sonst koennen Sie Fehler mitten in der Trajektorie nicht debuggen.
• +Single-Call-Logging versagt bei Agenten, weil Kosten nichtlinear sind, Fehler stille Falschabbiegungen sind und Verhalten nur als Verteilung ueber Runs Sinn ergibt.
• +Es gibt drei Instrumentierungs-Optionen — SDK (am tiefsten, meiste Arbeit), OpenTelemetry (der entstehende Austauschstandard) und Gateway-Erfassung (breiteste Abdeckung, null Code-Aenderungen). Die meisten Teams sollten Gateway-Erfassung als Basis fahren und OTel-Spans dort ergaenzen, wo Tiefe noetig ist.
• +Agent-Traces sind standardmaessig ein PII-Risiko — schwaerzen Sie am Erfassungspunkt, nicht nach der Speicherung.
• +Koppeln Sie Observability mit Kontrolle: Budgets, Ausgabenlimits und Tool-Call-Beschraenkungen machen aus "wir haben die Endlosschleife gesehen" ein "die Endlosschleife wurde gestoppt."