Getestet wird ein Bewertungssystem, das die falsche Endaktion eines Agenten erneut prüft.

Anthropics Funktion „Claude Outcomes“ bündelt einen Prozess, den viele Teams selbst zusammenstellen: Ein Arbeitsagententwirft eine Antwort, ein zweiter Komponent bewertet sie anhand eines Bewertungsschemas, und bei einer Fehlbeurteilung erhält der Agent eine weitere Chance. Die zugrundeliegende Idee ist so einfach, dass man sie ohne das verwaltete Produkt ausprobieren kann; daher wurde eine vereinfachte Version in einer kontrollierten Umgebung mit Agentenausgabe, Bewertungsjudge und genau einer erneuten Chance neu entwickelt.

Die Frage

Der Test stellt nur eine einzige Frage: Wenn ein Agent eine strukturierte Entscheidung treffen muss, verringert ein mit einem Bewertungsschema gesteuertes Wiederholungsverfahren die Anzahl der falschen Endaktionen?

Die abschließenden Aktionen sind hier entscheidend, denn viele tatsächliche Fehler von Agenten haben nichts mit der Qualität des Textes zu tun. Eine Antwort mag gut lesbar sein, das JSON kann korrekt interpretiert werden – doch die gewählte Aktion kann dennoch falsch sein. Das führt in einem Support-Prozess zu operativen Fehlern. Nehmen wir an, ein Agent gibt DENY zurück, obwohl NO_ACTION richtig gewesen wäre: Die vorsichtig klingende Begründung rettet die Situation nicht.

Die Einrichtung

Die Testreihe bestand aus dreißig synthetischen Support-Fällen sowie einem Modell, gpt-5.4-mini. Ein solches Beispiel kann nicht als Benchmark dienen. Der Wert liegt darin, wie die Fehler aussahen: Welche Fehler wurden behoben, welche übersehen und wo das Muster zu seinen Kosten führt.

Jeder Fall enthält ein kurzes Kundenszenario, eine Richtlinie sowie eine festgelegte Liste der zulässigen abschließenden Aktionen:

APPROVE
DENY
ASK_CLARIFYING_QUESTION
ESCALATE
NO_ACTION

Zwei Schleifen konkurrierten miteinander. Im Basisszenario geht der Fall direkt an den Agenten, und jede zurückgegebene Aktion wird aufgezeichnet. In der version mit Kontrollmechanismus prüft ein Bewertungsrichter die erste Antwort, und bei einem Misserfolg wird der Agent zur weiteren Anstrengung zurückgeschickt – diesmal mit den Kriterien, die er übersehen hat.

Das Diagramm unten dient als kompakte Referenz für Agenten-Arbeitsabläufe mit ergebnisbasierten Kontrollmechanismen. Es zeigt, wie Bewertungskriterien eine vorgeschlagene Aktion vor der Annahme einer endgültigen Entscheidung gegen einen Richtlinienvertrag überprüfen.

Der Vertrag wurde absichtlich eng gefasst, mit einer begrenzten Liste an möglichen Aktionen, expliziten Richtlinienbeschränkungen sowie nur einer erneuten Versuchsmöglichkeit, falls eine Bewertung fehlschlägt.

Baseline:
case -> agent -> final action

Gated:
case -> agent -> rubric judge
if failed -> retry once
retry answer -> final action

Die Fälle waren synthetisch, basierten aber auf gängigen Einschränkungen im Produktionsumfeld:

Es wurde ein echter LLM-Anbieter verwendet und kein deterministischer Simulator, denn das Interessante ist die tatsächliche Verhaltensweise des Modells, nachdem seine erste Antwort bewertet und überarbeitet wurde.

Ein Urteiler ohne Lösungsschlüssel

Ein Urteiler, der bereits die Antwort kennt, würde den Sinn zunichtemachen. Jeder Fall enthält eine expected_action, doch dieser Wert wird erst nach der Ausführung in Offline-Metriken verwendet, und der Urteiler erhält ihn nie zu Gesicht. Was der Urteiler sieht, ist die von dem Agenten gewählte Aktion, und er prüft diese Aktion anhand objektiver Richtlinienbeschränkungen.

Stellen Sie sich einen Rückerstattungsantrag vor, bei dem im Zahlungswerkflow ein offener Chargeback vorliegt. NO_ACTION könnte die richtige Entscheidung sein, da die Zahlungsabteilung für die Lösung dieses Problems zuständig ist und der Support nicht darüber entscheiden sollte. Ein schwacher Entscheider würde lediglich prüfen, ob das Modell NO_ACTION gewählt hat – das entspricht im Grunde einer Überprüfung mit einer Antwortliste. Dies eignet sich für die Bewertung offline, ist aber keine echte Entscheidungsschranke.

Eine echte Entscheidungsschranke stellt eine andere Frage: Angesichts von DENY – hat der Agent fälschlicherweise den Support als Entscheidungsträger eingestuft, obwohl ein anderer Workflow für den Fall zuständig ist?

Zur Laufzeit wird in der Regel keine versteckte Antwortliste benötigt. Stattdessen soll geprüft werden, ob die vorgeschlagene Aktion gegen klare Vertragsbedingungen verstößt. Hier waren die Bedingungen einfach: Wählen Sie eine endgültige Aktion und wählen Sie keine, die mit den Richtlinien des Falls kollidiert.

Was ist passiert

Bei einer einzigen Durchlaufung der 30 Fälle machte das Basissystem 6 Endaktionen falsch. Nach Hinzufügen eines Richters und einer erneuten Versuche blieben nur noch 2 falsch.

Der Gewinn ist real, doch die Zahlen allein täuschen. Der Schleifenmechanismus verlieh dem System keine umfassenden neuen Fähigkeiten. Er funktionierte nur dort, wo der Richter einen konkreten Widerspruch zwischen der gewählten Aktion und dem Richtlinienvertrag benennen konnte, wie die Fehlerbeispiele zeigen.

Was das System korrigierte

Der Schleifenmechanismus behebte 4 der 6 Fehler des Basissystems. Die meisten Korrekturen erfolgten in Fällen, in denen das Basissystem zu schnell eine Ablehnung vornahm. Die Richtlinie unterstützte zwar keine sofortige Genehmigung, verlangte aber auch keine Ablehnung. Besser war es, um Klarstellung zu bitten oder auf einen anderen Arbeitsablauf zu warten.

Eine Anfrage zur Änderung der E-Mail-Adresse eines Kontos wurde eingereicht. Sie stammte von einem neuen Gerät, die MFA-Verifizierung war noch nicht abgeschlossen, und der Anfragende kannte die Zahlungs-Postleitzahl. Laut Richtlinie musste zunächst die MFA-Verifizierung abgeschlossen oder eine andere genehmigte Überprüfung der Kontoeigentümerschaft durchgeführt werden, bevor der Support weiterarbeiten konnte. Die Standardantwort lautete DENY, obwohl eigentlich ASK_CLARIFYING_QUESTION erwartet wurde. Es war noch zu früh, die Anfrage abzulehnen, da es weiterhin einen Weg für eine genehmigte Überprüfung gab; daher war es der richtige Schritt, nach weiteren Informationen zu fragen. Der Richter lehnte die Ablehnung als zu früh ab, und beim erneuten Versuch änderte das Modell seine Antwort auf ASK_CLARIFYING_QUESTION.

Ein weiterer reparierter Fall betraf ein Ersatzgerät. Ein Kunde bat den Support, eines nachzusenden, doch bereits an diesem Morgen war ein RMA erstellt worden, das auf eine Lagerüberprüfung wartete. Die Grundregel wählte DENY und die erwartete Aktion war NO_ACTION. Die Ablehnung beschrieb die Situation falsch, da der Kunde nicht ungeeignet war. Der Ersatzprozess lief bereits, und der Support sollte kein dupliziertes RMA eröffnen. Der Neversuch korrigierte dies auf NO_ACTION.

Sowohl die Beispiele als auch das Muster zeigen den praktischen Wert. Die Regel machte das Modell nicht allgemein intelligenter – sie zwang lediglich zur Behebung eines bestimmten Widerspruchs zwischen der ausgewählten Aktion und dem Richtlinienvertrag.

Was es nicht beheben konnte

Die beiden verbleibenden Fehlschläge sagen mehr aus als die Gesamtbewertung. Beide betrafen bereits bestehende Workflows, bei denen die erwartete Aktion NO_ACTION war, und die endgültige Entscheidung blieb auch nach dem Neversuch weiterhin DENY.

Im ersten Fall gab es bei einem Rückerstattungsantrag einen offenen Chargeback im Zahlungsworkflow. Laut Richtlinie durfte der Support keine Rückerstattungen ausstellen, solange ein Chargeback aktiv war, da die Zahlungsabteilung für die Lösung zuständig war. Im zweiten Fall wollte ein Käufer eine manuelle Freigabe der Lieferung, während eine Betrugsprüfung lief, und die Richtlinie verbot dem Support, Lieferungen in diesem Zustand freizugeben. In beiden Fällen erkannte der Judge das Problem und gab fehlerhafte Kriterien zurück, doch der Neversuch führte dennoch zur falschen Aktion.

Das verändert die Art und Weise, wie das Muster für den Produktivgebrauch beurteilt werden sollte. Ein Gate kann feststellen, dass eine Aktion eine Regel bricht, doch Feststellung bedeutet noch nicht Behebung. Angenommen, das Modell kann nicht zwischen „Anfrage ablehnen“ und „Sich da raushalten, weil ein anderer Workflow entscheidet“ unterscheiden. Dann kann selbst eine als problematisch markierte Antwort unverändert zurückkehren. Dass etwas sicher erscheint, macht eine Aktion noch lange nicht richtig, und DENY wirkt zwar konservativ, ist aber dennoch falsch, wenn der Agent keine Befugnis für den Fall hat.

Wo man ihm vertrauen kann

Der Erfolg hing hier von einem überprüfbaren Ergebnis ab. Der Agent wählte aus einer geschlossenen Menge, die Richtlinienlimits waren klar definiert und der Prüfer konnte die gewählte Aktion mit einer konkreten Regel vergleichen. Wiederholungen, die an ein Ergebnis gekoppelt sind, erwecken in solchen Situationen mehr Vertrauen:

Mehr Vorsicht ist geboten, wenn das Ergebnis subjektiv ist:

Es sollte nicht als allgemeine Zuverlässigkeitsschicht betrachtet werden. Reservieren Sie es für Fälle, in denen ein falscher Ablauf so teuer ist, dass er die Kosten für einen zusätzlichen Modellaufruf rechtfertigt, und in denen das gewünschte Ergebnis in einen Vertrag festgelegt werden kann.

Produktionsänderungen, die sich lohnen

Eine Anpassung ist wichtiger als alle anderen: Wiederholte Fehlversuche ohne Korrektur sollten als Feedback zum Design interpretiert werden. Wenn der Agent ständig DENY und NO_ACTION verwechselt, sollten die Aktionen genauer definiert, Beispiele hinzugefügt oder der Workflow-Vertrag überarbeitet werden. Ein weiterer Versuch behebt in den meisten Fällen nicht das Verständnisschwund.

Trennen Sie auch die Laufzeit-Steuerung von der Offline-Bewertung. Während der Laufzeit setzt der Bewertungsmechanismus Einschränkungen durch, während die Offline-Bewertung die endgültigen Aktionen anhand von etikettierten Erwartungen prüft. Ihr Zusammenführen verfälscht das Systembild. Es lohnt sich außerdem, jeden Neversuch zu protokollieren – inklusive der ersten Aktion, der fehlgeschlagenen Kriterien, der überarbeiteten Aktion sowie des endgültigen Urteils – denn die Mischung aus Korrekturen und unkorrigierten Aktionen sagt oft mehr über die Leistung aus als die Gesamtgenauigkeit.

Fazit

Ausgangskontrollen lohnen sich, wenn „Fertigstellung“ als Vertrag formuliert werden kann. Hier war der Vertrag einfach: Wählen Sie eine endgültige Aktion, die keine Richtlinienbeschränkungen verletzt. Unter dieser Bedingung reduzierte der gesteuerte Schleifenprozess die fehlerhaften Endaktionen von 6 von 30 auf 2 von 30.

Diese verbleibenden Fehlschläge sind es, denen die Aufmerksamkeit in der Produktion gelten sollte. Der Tester hat das Problem erkannt, doch beim erneuten Versuch wurde dennoch die falsche Aktion ausgeführt. Die offene Frage ist daher nicht nur, ob ein System Ausgaben bewerten kann, sondern auch, ob der gesamte Prozessschleifen dieses Urteil in die richtige Entscheidung umsetzen kann. Das sind die Beweise, nach denen gefragt werden muss, bevor eine auf Ergebnissen basierende Schleife einen Live-Workflow berührt.

Weiterführende Literatur

Die API-Dokumentation von Anthropic zur Definition von Ergebnissen sowie der entsprechende Leitfaden zu Agenten, die ihre eigene Arbeit überprüfen, behandeln die verwalteten Funktionen, die dieses Experiment widerspiegelt.