AI Agent Evaluation: Execution Traces, Tool Calls & Production Readiness

Ein Agent ist nicht produktionsreif, weil er einen Task einmal erfolgreich beendet. Entscheidend ist, ob sein relevanter, beobachtbarer Execution Path korrekt, sicher, reproduzierbar und wirtschaftlich bewertet werden kann.

Die Kernfrage lautet:

Wie weist ein Unternehmen nach, dass ein Agent reale Aufgaben mit den richtigen Tools, innerhalb klarer Grenzen und auch unter Fehlern belastbar ausführt?

Für die vorgelagerte Entscheidung zwischen Agent, Workflow und Automation siehe KI-Agent vs. Workflow vs. Automation. Ob die gesamte Architektur mit Daten, Identity, Security und Betrieb tragfähig ist, behandelt die KI-Architektur-Checkliste für Unternehmen.

Task Success reicht nicht: Execution Quality entscheidet

Bei einem Chat-Use-Case kann eine richtige Antwort einen großen Teil des Qualitätsziels abbilden. Ein Agent kann zusätzlich Daten lesen, APIs aufrufen, Dateien verändern, Nachrichten senden oder Fachprozesse anstoßen. Damit kann derselbe Outcome über sehr unterschiedliche Wege entstehen.

Lauf A

1. Der Agent liest erlaubte CRM-Daten.
2. Er verwendet das freigegebene Pricing-Tool mit korrekten Parametern.
3. Er erstellt einen Angebotsentwurf.
4. Er wartet vor der Freigabe auf einen Menschen.

Lauf B

1. Der Agent liest zusätzlich sensible Notizen.
2. Er wählt ein falsches Tool und überschreibt einen Datensatz.
3. Ein Retry löst dieselbe Aktion ein zweites Mal aus.
4. Er erstellt anschließend denselben Angebotsentwurf.

Beide Läufe liefern den richtigen Text. Nur einer ist ein akzeptabler Ausführungspfad. Ein Agent kann unnötige Tool Calls erzeugen, falsche Parameter verwenden, Rechte überschreiten, Fehler zufällig kompensieren oder erheblich teurer und langsamer sein, ohne dass dies im finalen Outcome sichtbar wird.

Gleicher Outcome bedeutet nicht gleiche Qualität.

Task Success bleibt notwendig. Für produktive Agenten muss zusätzlich klar sein, ob der Weg zum Ergebnis den technischen, fachlichen und wirtschaftlichen Vertrag erfüllt.

Der Execution Trace ist das Evaluationsobjekt

Ein Execution Trace ist keine vollständige Aufzeichnung interner Modellgedanken und kein Auftrag, pauschal alles zu loggen. Gemeint ist die minimale, zweckgebundene technische Evidenz, mit der ein Lauf bewertet, debuggt und bei Bedarf reproduziert werden kann.

Dazu gehören je nach Use Case beispielsweise:

• Task- oder Request-ID,
• verwendete Modell-, Prompt- und Policy-Version,
• Tool-Auswahl und relevante Parameter,
• relevante Tool-Ergebnisse,
• erwartete und tatsächlich ausgelöste State Changes oder Side Effects,
• Fehler, Retries, Freigaben und Human Handoffs,
• Stop Condition sowie finales Outcome,
• Kosten und Latenz des Laufs.

Diese Evidenz beantwortet eine zentrale Release-Frage: Warum wurde dieser Task als erfolgreich bewertet? Sie muss datensparsam sein: Inhalte, Parameter und Tool-Ergebnisse nur soweit erfassen oder referenzieren, wie sie für Diagnose, Audit und Reproduktion des konkreten Risikos nötig sind.

Agent Evaluation als Release-Pfad

1. 01

   Task

   Welches fachliche Ergebnis, welche Rollen und welche Grenzen gelten?

   Akzeptierter Outcome definiert

2. 02

   Execution Trace

   Welche Versionen, Tools, Zustände und Entscheidungen sind für diesen Lauf technisch beobachtbar?

   Minimale Evidenz verfügbar

3. 03

   Tool- und State-Validation

   Waren Auswahl, Parameter, Reihenfolge und Side Effects korrekt?

   Execution Assertions erfüllt

4. 04

   Failure- und Guardrail-Check

   Stoppt, gleicht ab oder übergibt der Agent bei Fehlern und Policy-Grenzen sicher?

   Riskante Pfade getestet

5. 05

   Kosten und Latenz

   Bleibt der korrekt ausgeführte Task innerhalb seiner wirtschaftlichen und zeitlichen Grenze?

   Unit Economics messbar

6. 06

   Release Decision

   Liegt für kritische Failure Classes und Aktionen ausreichende Evidenz vor?

   GO, MITIGATION NEEDED oder BLOCKED

Was ein Agent-Testfall neben dem Outcome prüfen muss

Ein Testfall bewertet nicht nur, ob am Ende eine brauchbare Antwort erscheint. Er definiert den beobachtbaren Vertrag für die Ausführung.

A. Tool-Auswahl und Parameter

Prüfen Sie, ob der Agent das richtige Tool verwendet, ob der Aufruf überhaupt nötig ist und ob Parameter, Reihenfolge und Anzahl der Aufrufe zum Task passen. Ein falsches Tool kann trotz korrektem Endergebnis ein Sicherheits-, Kosten- oder Wartungsrisiko sein.

Für IDs, Beträge, Empfänger, Mandanten, Schreib-/Leseoperationen, JSON-Schemas oder maximale Call Counts sind deterministische Assertions oft belastbarer als eine semantische Bewertung.

B. State Changes und Side Effects

Ein Agent-Testfall sollte erwartete und verbotene Zustandsänderungen benennen können:

• Welches System darf verändert werden?
• Welcher neue Zustand ist nach erfolgreicher Ausführung erwartet?
• Welche Nebenwirkung wäre unzulässig?
• Darf derselbe Effekt nur einmal eintreten?
• Ist die Aktion reversibel oder braucht sie eine Kompensation?

Ein korrekter Text kompensiert keinen falschen Datensatz, keine doppelt ausgelöste Nachricht und keine unerwartete Transaktion.

C. Policy Boundaries und Human Approval

Für jede Aktion muss klar sein, ob sie autonom erlaubt, nur nach Freigabe erlaubt oder grundsätzlich verboten ist. Der Test prüft dabei auch, ob der Agent die richtige Identity und die minimale Berechtigung verwendet.

Retrieval-ACLs, Security Trimming und Revocation sind eigene Architekturthemen. Wie nicht autorisierte Evidenz bereits vor dem Modellkontext ausgeschlossen wird, behandelt RAG-Berechtigungen & Security Trimming.

Agent-Testfälle als Execution Fixtures

Ein Golden Dataset für RAG bewertet vor allem Retrieval und Antwortqualität. Ein Agent-Testset baut darauf auf, bewertet aber zusätzlich Handlungspfad und Zustandsänderungen. Dafür eignet sich ein versioniertes Execution Fixture statt nur eines Inputs mit Referenzantwort.

So wird nicht die gesamte Architektur erneut getestet, sondern der agentische Execution Contract eines konkreten Tasks.

Failure Paths: stoppen, abgleichen oder übergeben

Der Happy Path zeigt, dass ein Agent etwas kann. Produktionsreife zeigt sich, wenn ein Tool fehlschlägt, ein Schema unerwartet ist, eine externe API zu spät antwortet oder der nächste Schritt unsicher wird.

Relevante Failure Paths sind unter anderem:

• Tool Call schlägt fehl oder liefert ein unerwartetes Response-Schema,
• externe API antwortet zu spät oder erreicht ein Rate Limit,
• ein notwendiger Schritt wird übersprungen oder der Agent beendet zu früh,
• ein Loop erzeugt übermäßige Tool-Nutzung,
• ein Teil des Workflows wurde ausgeführt, der Abschlusszustand bleibt aber unklar,
• ein Retry löst eine mutierende Aktion doppelt aus,
• ein Human Handoff wäre nötig, wird aber nicht ausgelöst.

Unknown Execution State ist kein Retry-Signal

Ein Timeout bedeutet nicht automatisch, dass eine Aktion nicht ausgeführt wurde. Sendet der Agent eine mutierende Anfrage und die Verbindung bricht ab, kann die Gegenstelle die Änderung bereits gespeichert haben. Ein blinder Retry kann dann eine zweite Erstattung, Nachricht oder Datenänderung auslösen.

Für solche Fälle braucht der Testfall konkrete Erwartungen an:

• Idempotency oder Deduplication für geeignete Aktionen,
• Status Reconciliation gegen das Zielsystem,
• sichere Eskalation und Human Handoff bei unklarem Zustand,
• Recovery oder Compensation, wenn eine Aktion rückgängig gemacht werden kann,
• eine eindeutige Stop Condition, wenn keine sichere Fortsetzung möglich ist.

Ein produktionsreifer Agent braucht nicht nur Erfolgspfade, sondern definierte Zustände nach Unsicherheit.

Guardrails sind erst belastbar, wenn ihre Umgehung getestet wurde

Eine Prompt-Regel wie „Der Agent soll keine Erstattung auslösen“ ist keine belastbare Grenze. Sie beschreibt ein gewünschtes Verhalten. Eine technische Grenze beschränkt, was der Agent tatsächlich tun kann, etwa durch Allow-Lists, Schemas, enge Tool Scopes, Berechtigungen, Action Limits, Human Approval oder Egress Restrictions.

Ein Guardrail wird erst zur Evidenz, wenn sein Bypass getestet wurde. Geeignete Fälle sind zum Beispiel Context- oder Prompt-Injection, unerwartete Tool-Outputs, adversarial Inputs, Policy-Bypass-Versuche und Parameter außerhalb der erlaubten Grenzen.

Ein Guardrail ist erst Evidenz, wenn seine Umgehung getestet wurde.

Das ersetzt keine vollständige Security-Architektur. Es prüft, ob die für diesen Agenten behaupteten Grenzen im konkreten Execution Path tatsächlich greifen.

Deterministische Checks, LLM-Grader und Human Review

Diese Methoden bewerten unterschiedliche Teile des Execution Trace. Keine von ihnen sollte einen anderen Kontrolltyp simulieren, wenn eine direktere Prüfung möglich ist.

Deterministische Assertions

Geeignet für Tool-Auswahl, Parameter innerhalb eines Schemas, verbotene Aktionen, erwartete State Changes, vorhandene Approvals, Retry Counts und Stop Conditions. Harte Sicherheits- und Berechtigungsgrenzen sollten nicht von einem LLM-Grader abhängen, wenn sie technisch prüfbar sind.

LLM-Grader

Geeignet für semantische Qualität, Plausibilität, Task-Erfüllung, Vollständigkeit und die Angemessenheit einer Eskalation. Sie bewerten Ergebnisqualität, nicht den Ersatz für eine technische Policy Enforcement.

Human Review

Gezielt nötig bei neuen Failure Classes, fachlich mehrdeutigen Grenzfällen, High-Risk Actions, neuen Tool-Kombinationen und zur Kalibrierung von Gradern. Human Review ist damit ein definierter Kontrollpunkt, kein unbestimmter Restprozess.

Regression misst auch Verschlechterungen im Execution Path

Änderungen an Modell, Prompt, System Prompt, Tool-Schema, API, Retrieval, Policy oder Workflow können den Execution Path verschlechtern, obwohl Task Success gleich bleibt oder sogar steigt.

Eine neue Version kann beispielsweise mehr Tool Calls brauchen, Tools in riskanterer Reihenfolge aufrufen, häufiger retrien, mehr Human Handoffs auslösen, zusätzliche Side Effects erzeugen oder höhere Kosten und Tail Latency verursachen.

Ein „besseres“ Modell kann ein schlechterer Agent sein.

Deshalb sollte jede relevante Änderung gegen dieselben Execution Fixtures laufen. Ergebnisse gehören nach Failure Class aufgeschlüsselt: Ein guter Durchschnittswert darf keine Regression bei verbotenen Aktionen, kritischen State Changes oder Recovery verdecken. Die Methodik für Retrieval, Evidenz und Antwortqualität bleibt dabei in RAG Evaluation: Metriken & Golden Dataset verankert.

Kosten und Latenz pro erfolgreich abgeschlossenem Task

Rohe Tokenzahlen und durchschnittliche Laufzeit erklären nicht, ob ein Agent wirtschaftlich arbeitet. Entscheidend sind Kennzahlen mit dem korrekt ausgeführten Task als Bezugsgröße:

• Cost per Successful Task,
• Cost per Correctly Executed Task,
• Latency per Successful Task,
• Tail Latency, etwa p95, wenn der Prozess zeitkritisch ist,
• Retry- und Failure-Anteil,
• Tool Calls pro erfolgreich abgeschlossenem Task.

Eine billigere Einzelanfrage kann wirtschaftlich schlechter sein, wenn sie mehr Fehlversuche, Retries oder Eskalationen erzeugt. Ebenso hilft eine niedrige Durchschnittslatenz wenig, wenn kritische Tasks regelmäßig in hoher Tail Latency hängen. Diese Messung ist keine FinOps-Abhandlung, sondern Teil der Entscheidung, ob der Agent seinen Task verlässlich genug ausführt.

Release Decision: Evidenz statt Gesamtscore

Vor produktiven Aktionen sollte ein Agent mindestens belastbare Evidenz zu folgenden Punkten liefern:

• Task Success für reale, repräsentative Aufgaben,
• Execution Assertions für Tools, Parameter und Reihenfolge,
• erwartete und verbotene State Changes,
• Policy Compliance und Human Approval,
• getestete Failure-, Recovery- und Handoff-Pfade,
• Regressionen nach relevanten Änderungen,
• Kosten und Latenz pro korrekt ausgeführtem Task.

Das Statusmodell aus der KI-Architektur-Checkliste passt auch hier: GO, MITIGATION NEEDED oder BLOCKED. Ein numerischer Gesamtscore ersetzt diese Entscheidung nicht. Ein kritischer Policy- oder State-Change-Blocker darf nicht durch gute Outcome-Metriken kompensiert werden.

Nächster Schritt

Wenn ein Agent oder agentischer Workflow bereits existiert, aber niemand seinen Execution Path, seine Failure States und seine Unit Economics belastbar bewerten kann, sollte nicht zuerst weitere Autonomie gebaut werden.

Zuerst braucht es reale Execution Fixtures, Trace Assertions, getestete Guardrails sowie klare Release-Kriterien. Dabei unterstütze ich mit KI Production Readiness: bestehende Systeme prüfen, Regression und Evidenz aufbauen und einen verantwortbaren Weg vom Pilot in die Produktion definieren.