Methode · AgentOps · Agentic FinOps & AgentOps
AgentOps im FinCrime-Betrieb: Warum Monitoring bei autonomen KI-Agenten nicht reicht
Reasoning Loops, falsche Tool-Calls, Context Drift und stille Halluzinationen erzeugen keine klassischen Stacktraces. Sie brauchen Traces, State-Monitoring und evaluative Observability.
Wenn ein Microservice fehlschlägt, gibt es meist einen Fehlercode, einen Stacktrace, eine Metrik, einen Timeout oder eine gebrochene Abhängigkeit. Wenn ein autonomer KI-Agent fehlschlägt, kann er äußerlich erfolgreich wirken. Er ruft weiter Tools auf, erzeugt plausibel klingende Zwischenergebnisse, füllt das Kontextfenster, verbraucht Tokens und liefert am Ende eine saubere Zusammenfassung, die fachlich falsch ist.
Watchdog-Lesart
Ein Agentenlauf muss replayfähig werden. Nicht als Voyeurismus in Prompts, sondern als kontrollierte Spur aus Zustand, Tool-Nutzung, Kosten, Evaluator-Ergebnis und menschlicher Übergabe.
Das ist der Bruch zwischen klassischem Monitoring und AgentOps.
Monitoring fragt: Ist das System verfügbar? Wie hoch ist die Latenz? Wie viele Fehler gab es? AgentOps muss zusätzlich fragen: Welchen Weg hat der Agent genommen? Welche Tools hat er mit welchen Parametern aufgerufen? Welcher Zustand wurde verändert? Wann begann der Loop? Welche Annahme stammt nicht aus den Quellen? Welche Kosten entstanden pro Schritt? Und was wurde geloggt, obwohl es im FinCrime-Kontext nicht hätte geloggt werden dürfen?
Die zentrale These lautet: AgentOps ist keine bunte LLM-Dashboard-Schicht. Es ist die Observability-Architektur für nicht-deterministische Systeme.
Warum der Fehler kein Stacktrace ist
Agentische Workflows bestehen aus Iteration. Ein Agent liest Kontext, plant einen nächsten Schritt, ruft ein Tool auf, bewertet das Ergebnis, schreibt neuen Kontext und entscheidet erneut. Das kann funktionieren. Es kann aber auch in drei typische Fehlermuster kippen:
- Reasoning Loop: Der Agent wiederholt Planungsschritte, ohne näher an ein belastbares Ergebnis zu kommen.
- Tool Drift: Der Agent wählt formal erlaubte, fachlich aber falsche Tools oder ruft sie mit falschen Parametern auf.
- Silent Hallucination: Der Agent formuliert eine plausible Aussage, die nicht in den Daten, Dokumenten oder Tool-Outputs gedeckt ist.
Keines dieser Muster muss einen technischen Fehler werfen. Ein HTTP-Status 200 kann eine fachlich falsche Antwort transportieren. Eine niedrige Latenz kann bedeuten, dass der Agent zu früh abgeschlossen hat. Ein erfolgreicher Tool-Call kann mit den falschen Parametern erfolgt sein. Deshalb reicht klassisches APM nicht aus.
Pattern 1: LLM Tracing mit Spans und Traces
OpenTelemetry hat für generative KI eigene semantische Konventionen entwickelt. Noch sind diese Konventionen in Entwicklung, aber die Richtung ist klar: Ein GenAI-System braucht nicht nur eine Anfrage- und Antwortmetrik, sondern strukturierte Spans für Inferenz, Embeddings, Retrieval und Tool-Ausführung.
Für AgentOps heißt das: Ein kompletter Agentenlauf wird als Trace verstanden. Jeder Schritt wird als Span sichtbar:
- initialer Nutzerauftrag
- System- und Policy-Kontext
- Retrieval-Schritt
- LLM-Aufruf
- Tool-Call
- Tool-Response
- Evaluationsschritt
- Human-Review-Übergabe
- Kosten- und Tokenereignis
Das ist nicht akademisch. Ohne diese Granularität lässt sich nicht unterscheiden, ob ein Agent an schlechter Retrieval-Qualität, falscher Modellwahl, Tool-Parametern, Kontextüberlauf oder einer fehlerhaften Evaluator-Regel gescheitert ist.
LangSmith und Phoenix besetzen genau diesen Raum. LangSmith beschreibt Traces als Abfolge von Schritten von Input zu Output und visualisiert die einzelnen Runs. Phoenix positioniert sich als offene AI-Observability- und Evaluation-Plattform, die Traces über OpenTelemetry und OpenInference verarbeitet. AgentOps.ai modelliert Ausführungen als Sessions, um Agentenläufe später zu rekonstruieren.
Die gemeinsame Architekturidee: Agentenarbeit muss replayfähig werden.
Pattern 2: State- und Context-Monitoring
Ein Microservice hat Zustand, aber meist nicht im gleichen Sinn wie ein Agent. Agenten tragen Gesprächshistorie, Tool-Outputs, Zwischenergebnisse, Pläne, Fehlerkorrekturen und Memory-Fragmente in einem laufenden Kontext. Dieser Kontext kann kippen.
Wenn das Context Window vollläuft, entstehen nicht nur höhere Kosten. Der Agent verliert Fokus. Alte Zwischenergebnisse verdrängen relevante Belege. Tool-Outputs werden zusammengefasst, aber nicht mehr präzise genug. Die Gefahr ist nicht nur technischer Abbruch, sondern semantische Erosion.
State- und Context-Monitoring muss deshalb andere Signale erfassen:
- Token-Auslastung des Kontextfensters
- Anzahl der Iterationen pro Fall
- Wiederholung derselben Tool-Klasse
- wachsender Anteil zusammengefasster statt originaler Belege
- Wechsel zwischen fachlichen Zuständen
- Zahl nicht abgeschlossener Subtasks
- Abbruchbedingungen und deren Auslösung
In FinCrime-Systemen kommt eine weitere Dimension hinzu: Nicht jeder Kontext darf vollständig geloggt werden. KYC-Daten, Sanktionshinweise, interne Verdachtsnotizen und personenbezogene Daten können nicht beliebig in Observability-Plattformen fließen. AgentOps braucht deshalb Privacy-by-Design: Redaction, Hashing, selektive Traces, Metadaten statt Rohprompt und klare Datenklassifizierung.
Die harte Regel lautet: Was nicht verantwortet gespeichert werden darf, darf auch nicht aus Observability-Bequemlichkeit im Trace landen.
Pattern 3: Evaluative Observability
Klassische Unit-Tests prüfen deterministische Funktionen. Agenten liefern generative Ergebnisse. Deshalb entsteht ein drittes Pattern: Evaluative Observability.
Dabei wird nicht nur beobachtet, was der Agent getan hat. Ein Evaluator bewertet, ob das Ergebnis bestimmte Kriterien erfüllt. Das kann regelbasiert, statistisch, durch Human Review oder durch ein zweites LLM erfolgen. Arize und LangSmith dokumentieren LLM-as-a-Judge-Ansätze, bei denen ein Modell anhand definierter Kriterien Outputs bewertet.
Für FinCrime ist die Formulierung entscheidend. LLM-as-a-Judge ist keine Verifikationsschicht. Es ist ein zweiter, kontrollpflichtiger Bewertungsmechanismus.
Gute Evaluatoren prüfen enge Fragen:
- Hält die Antwort das geforderte JSON-Schema ein?
- Verweist jede Risikobehauptung auf eine Quelle?
- Werden Annahmen gemacht, die nicht in den Quelldaten stehen?
- Wurde ein Tool-Call mit zulässigen Parametern ausgeführt?
- Hat der Agent eine Verdachtsentscheidung formuliert, obwohl nur eine Voranalyse erlaubt war?
Schlechte Evaluatoren geben allgemeine Qualitätsnoten. Im FinCrime-Betrieb ist das wertlos. Ein Score von 0.82 sagt nichts, wenn unklar bleibt, ob eine Behauptung belegt, eine Datenklasse verletzt oder eine menschliche Freigabe umgangen wurde.
Die Standardwerke: stabiler Kanon und neue Frontier
Für AgentOps gibt es noch kein Accelerate. Genau das ist der Befund.
Die etablierte Ops-Welt hat ihre Referenzwerke: Accelerate für DevOps-Metriken, Securing DevOps für Shift-Left-Security, Fundamentals of Data Engineering für Datenflüsse, Designing Machine Learning Systems für MLOps, Eric Evans’ Domain-Driven Design für fachliche Modellierung und Cloud FinOps für variable Cloud-Ökonomie.
AgentOps dagegen entsteht aus drei Quellen:
- Papers: ReAct ist ein Grundlagenanker, weil es Reasoning und Acting als verschränkte Schleife formuliert. Neuere AgentOps-Papers beschreiben Monitoring, Anomalieerkennung, Root Cause Analysis und Resolution für Agentensysteme.
- Framework-Dokumentation: LangSmith, Phoenix, AgentOps.ai und OpenTelemetry-GenAI-SemConv definieren aktuell de facto, wie Tracing, Sessions, Spans, Evaluators und Tool-Calls praktisch aussehen.
- Produktionsmuster: Teams lernen gerade, dass raw traces, Prompt-Logging, Tool-Replays und Evaluator-Scores ohne Governance selbst neue Risiken erzeugen.
Das ist die eigentliche Frontier: AgentOps ist noch nicht fertig kanonisiert, aber produktionskritisch.
Was das für FinCrime bedeutet
FinCrime-Agenten arbeiten in einem Hochrisikokontext. Sie fassen KYC-Akten zusammen, prüfen Adverse Media, traversieren UBO-Graphen, vergleichen Sanktionshinweise, priorisieren Alerts oder bereiten Fallnotizen vor. Genau dort kann ein plausibler Fehler teuer werden: reputationsrechtlich, regulatorisch, datenschutzrechtlich und operativ.
Ein bankfähiges AgentOps-Setup braucht deshalb mindestens:
- Trace-IDs pro Fall, Agentenlauf und Tool-Call
- Datenklassifizierung pro Span
- Redaction-Regeln für Prompts und Tool-Outputs
- Context-Window-Metriken und Loop-Zähler
- Tool-Fehlerraten und Parameterfehler
- Evaluator-Versionen und Rubriken
- Human-Review-Übergaben
- Kosten pro Trace, Task und verwertbarem Ergebnis
AgentOps ist damit die technische Schwester von AML Observability. AML Observability rekonstruiert, wie aus einem Signal ein Befund wurde. AgentOps rekonstruiert, wie ein Agent zu seinem Vorschlag kam.
Die Watchdog-These
Klassisches Monitoring sieht, ob ein System lebt. AgentOps muss zeigen, ob ein autonomes System noch begrenzt, nachvollziehbar und fachlich kontrolliert arbeitet.
Der Unterschied ist fundamental.
Ein Agent, der weiterläuft, ist nicht automatisch gesund. Ein Agent, der eine Antwort liefert, ist nicht automatisch fertig. Ein Agent, der Kosten erzeugt, ist nicht automatisch produktiv. Und ein Agent, der plausibel klingt, ist im FinCrime-Betrieb noch lange nicht belastbar.
Die neue Betriebsfrage lautet deshalb nicht: Hat der Agent geantwortet?
Sie lautet: Kann der Weg zur Antwort geprüft, begrenzt und verantwortet werden?
Quellen und Einordnung
- OpenTelemetry: Semantic conventions for generative AI spans
- OpenTelemetry: Semantic conventions for generative AI systems
- LangChain Docs: LangSmith Observability
- LangChain Docs: Observability concepts
- Arize Phoenix Docs: AI Observability and Evaluation
- AgentOps Docs: Sessions
- Arize AX Docs: LLM-as-a-Judge
- LangSmith Docs: LLM-as-a-judge evaluator
- ReAct: Synergizing Reasoning and Acting in Language Models
- O'Reilly: Accelerate
- Manning: Securing DevOps
- O'Reilly: Fundamentals of Data Engineering
- O'Reilly: Designing Machine Learning Systems
- O'Reilly: Domain-Driven Design
- FinOps Foundation: Cloud FinOps book
Transparenz: Dieser Beitrag wurde mit Codex aus Nutzerimpulsen, Watchdog-Dossierlogik und den dokumentierten Primär- beziehungsweise Standardquellen vorbereitet. Redaktionelle Prüfung vor weiterer Distribution bleibt erforderlich.
