ThinkingBox prüft Agenten am tatsächlichen Backend-Zustand

Eine Kundin wartet auf ein Küchengerät für 745 Dollar. Die Sendung steckt seit fünfzehn Tagen nach dem geplanten Liefertermin als Kurier-„Exception“ in einem Verteilzentrum in Nashville fest. Der Agent arbeitet gründlich: Er setzt neun Tool-Aufrufe ab, prüft Bestellung, Tracking und Kundenprofil, liest die Erstattungsrichtlinie korrekt und eröffnet ein Ticket. Dann schließt er es als gelöst. Laut Microsoft und Hugging Face hätte der korrekte Endzustand „on hold“ gelautet, weil die Ausnahme beim Zusteller noch offen war.

Der Fall stammt aus ThinkingBox, einem Benchmark von Microsoft, den beide Unternehmen in einem gemeinsamen Beitrag auf Hugging Face vorstellen. Er misst genau diese Lücke zwischen sauber aussehenden Tool-Aufrufen und dem, was am Ende tatsächlich in der Datenbank steht.

Gemessen wird, was im Backend steht

Laut dem zugehörigen Paper arbeiten die Agenten in isolierten, MCP-kompatiblen Werkzeugsitzungen. Bewertet werden der finale Backend-Zustand und die Nebenwirkungen: falsche Werte, fehlende Änderungen und zusätzliche, ungewollte Effekte. Die 507 Workflows stammen aus Handel, Gastgewerbe, Autoversicherung, interner Neobank-IT sowie IT- und HR-Support in der Beratung. Nur bei 30 Aufgaben prüfen zusätzliche Kriterien auch die Abschlussantwort, etwa Pflichthinweise oder Vertraulichkeit.

In einer Auswertung über zwölf Modelle scheiterten 79.853 Versuche an den Zustandsprüfungen. 67,24 Prozent davon endeten trotzdem sauber, riefen ein zustandsveränderndes Tool auf und meldeten keinen Tool-Fehler. Die Prüfungen fanden in 77,61 Prozent dieser Fälle falsche Feldwerte, in 43,30 Prozent ungewollte Zusatzeffekte und in 25,36 Prozent fehlende Pflichtänderungen. Mehrfachnennungen sind möglich.

Ein sauberes Log beweist also wenig.

Einmal gelöst heißt nicht zuverlässig gelöst

Jede Aufgabe läuft 20-mal, jedes Mal laut Microsoft auf einem identischen, frisch zurückgesetzten Backend. In der Paper-Fassung vom 20. August mit zwölf Modellen erreicht das stärkste Modell 65,36 Prozent im Einzelversuch. Bei 91,12 Prozent der Aufgaben gelingt ihm mindestens ein Lauf, alle 20 Läufe besteht es aber nur bei 25,25 Prozent. Laut OOMeta und der Tabelle im Hugging-Face-Beitrag ist das GPT-5.4.

Der Beitrag vom 3. Oktober erweitert das Feld auf 18 Modelle und zeigt dieselbe Spannung noch deutlicher. Kimi-K3 löst 476 der 507 Aufgaben mindestens einmal, aber nur 68 in allen 20 Versuchen. Claude Opus 5.5 liegt mit 67,16 Prozent im Einzelversuch knapp vor Claude Opus 5 mit 66,50 Prozent. Beide bestehen aber exakt dieselben 241 Aufgaben durchgehend. Der kleine Vorsprung in der Rangliste bringt also keine zusätzliche Verlässlichkeit.

Daraus folgt eine klare Konsequenz für Plattform- und Betriebsteams, die ein Modell für schreibende Workflows auswählen: Die Spalte mit 20 von 20 bestandenen Läufen ist die einzige, die zur Freigabeentscheidung taugt. Der Einzelversuch zeigt, was ein Modell manchmal schafft. Mindestens ein Treffer in 20 Läufen zeigt nur, dass ein Lösungsweg existiert. Alle Werte gelten für diesen Prüfaufbau und lassen sich nicht ohne Weiteres auf andere Benchmarks übertragen.

Was das für die Abnahme bedeutet

Zuverlässigkeit hat einen Preis, und Microsoft beziffert ihn als geschätzte Kosten pro durchgehend bestandener Aufgabe. Grundlage sind Listenpreise auf OpenRouter, nicht tatsächliche Rechnungen. Am günstigsten ist GPT-5.4 mit 6,80 Dollar, besteht aber nur 128 Aufgaben durchgehend. GPT-6 Astra kommt auf 231 Aufgaben für 7,45 Dollar, Claude Opus 5.5 auf 241 Aufgaben für 7,80 Dollar. Für die Auswahl eines Modells ist diese Rechnung brauchbarer als jede Rangliste.

Für den eigenen Abnahmetest lässt sich das Prinzip direkt übernehmen. Am Anfang stehen ein festgelegter Ausgangszustand und eindeutige Erwartungen an den Endzustand. Nach jedem Lauf prüfen Assertions die gewünschte Änderung und genauso, ob andere Datensätze, Beträge, Berechtigungen und Status unberührt geblieben sind. Derselbe Test läuft dann mehrfach in zurückgesetzten Umgebungen, und Tool-Aufrufe werden so protokolliert, dass sich jeder Fehlschlag nachvollziehen lässt. Bevor irreversible Änderungen wirksam werden, braucht der Workflow einen Rückweg, etwa einen Rollback oder eine manuelle Freigabe.

Zuverlässiger macht ThinkingBox Agenten nicht. Der Benchmark liefert aber eine Mindestregel für alles, was Datensätze verändert: Eine Erfolgsmeldung ersetzt nie die Prüfung, ob im Backend der erwartete Zustand steht. Ob diese Regel in Workflows mit menschlicher Freigabe genauso streng gelten muss, beantworten die Daten nicht.