Die direkte Antwort: Eine gelungene Demo beweist nichts über die Zuverlässigkeit eines KI-Agenten, denn die richtige Frage lautet nicht, ob er die Aufgabe einmal erledigt hat, sondern ob er sie jedes Mal korrekt erledigt. In einer Studie, die Microsoft am 20. August 2026 veröffentlichte, erreichte das stärkste Modell 65,36%, wenn jede Aufgabe einmal ausgeführt wurde, bestand aber alle zwanzig Versuche nur bei 25,25% der Aufgaben. Diese Lücke ist genau der Abstand zwischen einem Agenten, der Sie in einem Meeting beeindruckt, und einem Agenten, dem Sie Kundendaten anvertrauen können.

Was Microsoft tatsächlich gebaut hat

Das Werkzeug heißt Thinkingbox, eine Open-Source-Testumgebung, die unter der MIT-Lizenz auf GitHub veröffentlicht wurde. Die Idee ist einfach und clever: Statt Werkzeuge direkt in den Agenten einzubauen, definieren Sie sie als MCP-kompatible Server, führen den Agenten in einer isolierten Sitzung mit eigener zugrunde liegender Datenbank aus und zeichnen den vollständigen Ausführungsverlauf auf.

Der entscheidende Punkt liegt in der Bewertung. Das Framework liest nicht, was der Agent angeblich getan hat; es prüft, was sich nach Abschluss der Aufgabe tatsächlich in der Datenbank verändert hat. Diese Unterscheidung ist kein technisches Detail. Agenten sind sehr gut darin, eine überzeugende Zusammenfassung von Arbeit zu schreiben, die nie stattgefunden hat, und jede Bewertung auf Grundlage des Gesprächsprotokolls misst die Qualität der Prosa, nicht die Qualität der Ausführung.

Auf dieser Umgebung baute das Team einen Benchmark namens Thinkingbox-bench mit 507 richtliniengebundenen Workflows in fünf Bereichen: Einzelhandel und E-Commerce, Reisen und Gastgewerbe, Kfz-Versicherung, interner IT-Support bei einer Neobank sowie IT- und HR-Support bei einer Beratungsfirma. Jede Aufgabe wurde zwanzigmal mit zwölf Modellen ausgeführt, sowohl proprietären als auch Open-Weight-Modellen.

Warum diese Zahl für Unternehmer wichtig ist

Stellen Sie sich vor, Sie übertragen einem Agenten die Bearbeitung von Rücksendeanfragen in Ihrem Shop. Eine Erfolgsquote von 65% wirkt auf dem Papier akzeptabel. Im Betrieb bedeutet sie, dass ein Drittel der Anfragen mit einem falschen Ergebnis endet: eine doppelt ausgezahlte Erstattung, eine Bestellung, die ohne Wiederauffüllung des Lagerbestands geschlossen wird, oder eine Ausnahme für einen Kunden, für den Ihre Richtlinie sie nicht vorsieht.

Schlimmer noch: Die Fehler in dieser Studie waren keine offensichtlichen Abstürze. Das Papier beschreibt ausdrücklich, dass viele Fehler sauber endeten und Schritte unternahmen, die gültig aussahen, während der Endzustand des Systems dennoch falsch war. Keine Fehlermeldung, kein Abbruch, nichts, was auf einem Monitoring-Dashboard aufleuchtet. Nur ein Protokoll, das sich normal liest, und Daten, die still und leise falsch geworden sind.

Ein Fehler, der das System anhält, ist ärgerlich, aber sichtbar. Ein Fehler, der den Ablauf abschließt und Ihre Daten falsch hinterlässt, ist derjenige, der Sie wirklich Geld kostet, denn Sie entdecken ihn erst einen Monat später beim Abgleich.

Das erklärt auch eine häufige Quelle der Enttäuschung. Das Pilotprojekt besteht, weil es die Aufgabe einmal mit sauberen Daten ausgeführt hat. Der echte Betrieb ist dieselbe Aufgabe tausendfach auf einem unordentlich angesammelten Zustand, und genau dort zeigt sich der Unterschied zwischen 65% und 25%.

Was Sie tun sollten, bevor Sie einen Agenten einführen

  • Verlangen Sie wiederholte Durchläufe, nicht eine einzige Demo. Machen Sie zwanzig aufeinanderfolgende Durchläufe derselben Aufgabe mit denselben Daten zu Ihrem Abnahmekriterium. Ein Anbieter, der sich weigert, sagt Ihnen damit etwas.
  • Messen Sie den Datenzustand, nicht den Antworttext. Legen Sie vorab fest, wie der Datensatz in Ihrer Datenbank nach der Aufgabe aussehen soll, und vergleichen Sie die Realität damit. Geben Sie sich nicht mit der Zusammenfassung des Agenten selbst zufrieden.
  • Testen Sie Richtlinien, nicht nur leichte Aufgaben. Der Großteil Ihrer Arbeit ist nicht frei gestaltbar; er unterliegt Regeln: Rückgabefristen, Kreditlimits, Ausnahmen für bevorzugte Kunden. Ein Agent, der ohne Einschränkungen Erfolg hat, kann bei der ersten echten Bedingung zusammenbrechen.
  • Bauen Sie die Testsammlung aus Ihren eigenen Fällen. Nehmen Sie zwanzig echte Fälle aus den letzten Monaten, einschließlich der ungewöhnlichen, die Ihre Mitarbeitenden verwirrt haben, und machen Sie daraus eine feste Testreihe, die Sie mit jedem Modell vor der Einführung und nach jedem Update ausführen.
  • Vergeben Sie Befugnisse schrittweise. Beginnen Sie mit einem Agenten, der vorschlägt, aber nicht ausführt, lassen Sie ihn dann Vorgänge mit geringer Tragweite erledigen und erweitern Sie seinen Spielraum, sobald sich eine echte Messhistorie ansammelt. Befugnisse sollten mit Daten verdient werden, nicht mit Eindrücken.

Wie wir das bei Origami handhaben

Wenn wir ein System bauen, das einen KI-Agenten enthält, behandeln wir den Agenten wie jede andere Softwarekomponente: Er erhält eine automatisierte Testreihe, Prüfungen, die nach jedem Vorgang den Zustand der Datenbank kontrollieren, und einen klaren Übergabepunkt an einen Menschen, wenn eine Konfidenzschwelle überschritten wird. Das Modell selbst bleibt eine austauschbare Einstellung und wird nicht fest in den Code eingeschweißt, denn das beste Modell von heute ist in drei Monaten vielleicht nicht mehr das beste.

Die Erkenntnis, die man aus dieser Studie mitnehmen sollte, ist nicht, dass Agenten unbrauchbar sind. Sondern dass der Maßstab, an dem wir sie gemessen haben, falsch war. Heutige Agenten sind leistungsstarke Werkzeuge innerhalb eines klar definierten und laufend gemessenen Rahmens und sehr schwach, wenn man ihnen einen sensiblen Prozess auf Grundlage einer überzeugenden Demo übergibt. Der Unterschied liegt nicht im Modell, sondern in der technischen Disziplin rund um das Modell.

Quellen