65% één keer, 25% élke keer: Microsoft draaide 507 agenttaken twintig keer per stuk

De twee cijfers uit Microsofts Thinkingbox-benchmark tegenover elkaar — 65,36% pass@1, het cijfer dat een demo laat zien, naast 25,25% pass^20, het cijfer voor dezelfde taak in alle twintig runs goed doen — met de aantekening dat 80,88% van de mislukte pogingen netjes eindigde en dat 334 van de 507 taken heen en weer schoten tussen slagen en falen — Zelfde model, dezelfde 507 taken, backend gereset voor elke run. De afstand tussen beide cijfers is de afstand tussen iets dat werkt als je het laat zien en iets dat werkt als je het verkoopt.

Microsoft publiceerde vorige week een benchmark met de minst dubbelzinnige titel in tijden: "One Success Isn't Reliability" — één succes is geen betrouwbaarheid.

De paper (arXiv 2608.19741, 20 augustus 2026) introduceert Thinkingbox, een open source sandbox voor agents in stateful businessworkflows, plus een benchmark van 507 taken. Beide staan op GitHub.

Het hoofdresultaat zijn twee cijfers van hetzelfde model op dezelfde taken:

65,36% pass@1. 25,25% pass^20.

In één keer goed in ongeveer twee derde van de gevallen. In alle twintig pogingen goed in ongeveer een kwart. Heb je ooit een agent succesvol gedemonstreerd en hem daarna zien ontsporen bij een klant, dan is dat gat de volledige verklaring — en iemand heeft het eindelijk gemeten.

1. Wat deze benchmark doet wat andere niet doen

De meeste agentbenchmarks beoordelen de transcriptie. Riep de agent de juiste tools aan? Zei hij dat hij klaar was? Zag het slotbericht er goed uit?

Thinkingbox beoordeelt de database.

Hoe een Thinkingbox-taak echt verloopt

Vijf elementen gecombineerd die meestal apart worden getest

Een gesimuleerde gebruiker met wie de agent een gesprek over meerdere beurten voert, in plaats van één prompt.
Echte domeintools aangeboden via geïsoleerde backendsessies — en via een MCP-server, zodat de agent ermee praat zoals hij in productie zou doen.
Een stateful backend die wijzigingen vasthoudt gedurende het gesprek.
Controle op side effects: na afloop inspecteert het harnas wat er werkelijk veranderde in de onderliggende opslag.
Taakspecifieke uitkomstcontroles, geconditioneerd op beleid en niet alleen op de vraag of een tool een 200 teruggaf.

Vervolgens doet het het geheel twintig keer, met de backend gereset tussen de runs.

Dat ontwerp is de bijdrage. Alles wat interessant is aan de resultaten volgt uit die twee keuzes: controleer de toestand, en herhaal.

2. pass@1 is het cijfer dat je demo laat zien

De 507 taken beslaan vijf domeinen: retail en e-commerce (98 taken), reizen en horeca (104), autoverzekeringen (100), interne IT van een neobank (104) en IT/HR-support in consulting (101).

Meer dan een dozijn propriëtaire en open-weight modellen werden gedraaid. De gepubliceerde spreiding:

GPT-5.4

65,36% → 25,25%

Het sterkste resultaat in de set, en toch: in één keer goed bij twee op de drie taken, twintig van de twintig keer goed bij één op de vier.

Claude Sonnet 4.6

58,45% → 20,12%

Tweede op beide maten, met dezelfde vorm van instorting — ongeveer een derde van het eerste-poging-cijfer overleeft twintig herhalingen.

DeepSeek-V4-Pro

43,26% → 3,55%

De dramatischste daling in de tabel. Een respectabel cijfer bij één poging wordt bijna niets zodra consistentie vereist is.

Grok-4.3

14,38% → 0%

Nul taken correct afgerond in alle twintig runs. Dat is het waard om ronduit te zeggen, want het is de helderste illustratie van wat pass^20 meet.

Kijk naar de verhouding, niet naar de ranglijst. Over de hele tabel ligt pass^20 ergens tussen een derde en een tiende van pass@1. Welk nauwkeurigheidscijfer je ook geciteerd hebt zien worden voor een agent: wat je gebruikers bij herhaald gebruik ervaren ligt merkbaar lager, en dit is de eerste benchmark die ik heb gezien die die korting kwantificeert.

3. De 334 taken die flikkeren

Dit is de bevinding die ik op een slide zou zetten.

Het beste model slaagde minstens één keer bij ongeveer negen op de tien taken. Het slaagde in alle twintig runs bij ongeveer één op de vier.

Daarmee is de interessante groep niet de betrouwbare taken en ook niet de onmogelijke. Het zijn de 334 taken — twee derde van de benchmark — waarvan de uitkomst per poging wisselde.

Waarom in die band geloofwaardigheid sneuvelt

Een taak die altijd werkt is een feature. Een taak die nooit werkt is een bekende beperking waar je omheen ontwerpt. Een taak die meestal werkt is de taak die je succesvol demonstreert, vol vertrouwen uitrolt en daarna aan een klant uitlegt. Twee derde van realistische businessworkflows zit voor het beste beschikbare model in die band, wat betekent dat de standaarduitkomst van een demo bouwen een demo is die werkt — en je bijna niets vertelt.

Heb je je ooit afgevraagd waarom agentpilots zo slecht doorstromen naar productie, dan is dit een mechanisch antwoord. Pilots zijn kort, begeleid en klein van omvang. Ze bemonsteren de goede runs.

4. Vier op de vijf mislukkingen zagen eruit als successen

Nu het deel met de meest directe technische consequentie.

80,88% van de mislukte pogingen eindigde netjes. Het gesprek stopte normaal. Statuswijzigende tool calls werden uitgevoerd en gaven succes terug. Er ging niets stuk. De eindtoestand was alleen verkeerd.

De conclusie van de paper zelf is bot: signalen op het niveau van respons en tool call zijn geen duidelijke proxy's voor voltooiing van de taak van begin tot eind.

Uitgesplitst waren de dominante faalmodi:

77,5% — de agent ging door na een toolfout alsof die geslaagd was. De tool zei nee. Hij ging verder alsof het antwoord ja was.
12,1% — verkeerde statuswijzigingen. De tool werkte correct en schreef de verkeerde waarde. Alleen te vinden door de backend achteraf te controleren; onzichtbaar in de logs.

Lees die twee samen en een gangbare aanname valt om. De agent-observability van de meeste teams bestaat uit tool calls tracen en transcripties inspecteren. Tegen deze verdeling van mislukkingen vangt dat ongeveer één op de vijf. De andere vier zien er precies uit als de successen — dezelfde nette afsluiting, dezelfde geldige calls — en het enige wat ze onderscheidt is de toestand van de database als het klaar is.

Dit is ook het eerlijke antwoord op het onderzoek dat we gisteren behandelden, waarin 85,5% van de engineers zei de output van agents te vertrouwen. Natuurlijk doen ze dat. Vier op de vijf mislukkingen zijn onzichtbaar vanaf waar zij staan.

5. De spreiding tussen domeinen telt zwaarder dan het gemiddelde

Succes varieerde enorm per domein: ruwweg 52% gemiddeld succes in retail, tegenover ruwweg 23% bij autoverzekeringen.

Dat is meer dan twee keer zoveel verschil bij dezelfde modellen en hetzelfde harnas, en het verdient begrip in plaats van middeling. Retailworkflows zijn doorgaans korter, vergevingsgezinder en minder beleidsgebonden. Verzekeringsworkflows zijn lang, gebonden aan regels, en zitten vol stappen waar één verkeerde waarde vroeg in de keten stilletjes alles daarna vergiftigt.

De praktische vertaling voor een founder: het cijfer van jouw domein is niet het krantenkopcijfer. Lijkt wat je automatiseert op een schadeproces — meerdere stappen, beleidspoortjes, veel state — dan is de boodschap van de benchmark dat je de onderkant van de reeks moet verwachten, en dat je dat beter kunt ontdekken dan je klant.

6. Wat dit niet zegt

Drie voorbehouden, want een opvallende benchmark nodigt uit tot te ver doorlezen.

De geteste modellen zijn niet de huidige frontier. De tabel is gebouwd op GPT-5.4 en de Claude 4.6-generatie. De frontier is sindsdien opgeschoven: GPT-5.6 en Claude Opus 5 kwamen na dit werk. De absolute cijfers zijn al historisch. Of de verhouding tussen pass@1 en pass^20 verbetert bij nieuwere modellen is de echt open vraag, en niets hier beantwoordt die.

Positie in de benchmark is geen capaciteitsranglijst. Claude Opus 4.6 scoort hier onder Claude Sonnet 4.6 (37,91% tegen 58,45% pass@1), wat iedereen voorzichtig zou moeten maken om dit als kale ranglijst te lezen. Aansluiting op het harnas, promptformaat en tool-callingconventies verschuiven deze cijfers. Beschouw de vorm van de bevinding als robuust en de volgorde als eigen aan deze opzet.

Het is een simulatie. Geïsoleerde backends en een gesimuleerde gebruiker zijn enorm veel beter dan statische testgevallen, en het is nog steeds niet jouw productiesysteem met jouw data en jouw gebruikers. De richting van de fout is onbekend: echte workflows kunnen makkelijker zijn omdat gebruikers verduidelijken, of moeilijker omdat de werkelijkheid rommeliger is dan een simulator.

7. Wat je maandag verandert

Niet één keer

Draai het twintig keer

De goedkoopste verandering die er is. Neem de vijf taken die je agent het hardst goed moet doen, draai elk twintig keer tegen een gereset omgeving, en noteer hoeveel er élke keer slagen. De meeste teams hebben dit cijfer nooit voor hun eigen product gezien. Het is meestal een slechte middag en een uitstekend besluit.

Niet op de transcriptie

Toets op toestand

Je controle moet na afloop de database bevragen en vergelijken met wat waar zou moeten zijn. Slaagt je test omdat de agent "klaar" zei, dan zou hij ook slagen op 80,88% van Thinkingbox' mislukkingen. Een evaluatieset die op uitkomsten toetst is de versie die het bouwen waard is.

Bij toolfouten

Faal luid

De grootste faalmodus — 77,5% — is een agent die doorgaat nadat een tool nee zei. Die is te repareren in het harnas en niet in het model: maak toolfouten tot harde stops waar de agent zich niet omheen kan praten.

De derde kaart levert het meeste op. Het is geen modelprobleem en er is geen betere prompt voor nodig. Als een tool call faalt en je orkestratie laat de agent doorgaan, heb je een machine gebouwd die met overtuiging verkeerde antwoorden produceert — en de benchmark zegt dat dat driekwart van wat er misgaat verklaart.

De eerlijke samenvatting

Microsoft bouwde de agentbenchmark die beoordeelt wat ertoe doet — wat er in het systeem veranderde — en draaide daarna alles twintig keer om te zien of het standhoudt. Beide keuzes zijn achteraf voor de hand liggend en geen van beide was standaard.

De resultaten: het beste destijds beschikbare model had het in één keer goed in 65,36% van de gevallen en élke keer goed in 25,25%. Twee derde van de taken flikkerde tussen runs. Vier op de vijf mislukkingen eindigde netjes, met geldige tool calls, en zou er in elke transcriptiegebaseerde monitoring die je hebt uitgerold uitzien als een succes.

Niets daarvan betekent dat agents niet werken. Het betekent dat een demo geen bewijs is, dat nauwkeurigheid bij één run de verkeerde metriek was om te citeren, en dat de observability die de meeste teams hebben gebouwd de mislukkingen die daadwerkelijk optreden niet kan zien.

De oplossing is niet exotisch. Draai het twintig keer. Controleer de database. Zet de agent stil als een tool nee zegt.

Bronnen: arXiv 2608.19741, "One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows" · microsoft/thinkingbox op GitHub · De scores per model, de opbouw van de 507 taken, het cijfer van 80,88% nette terminatie en de domeingemiddelden zijn zoals gerapporteerd in de paper en de bijbehorende analyse; de voorbehouden in sectie 6 zijn van mij.

Vertrouwen loopt voor op het bewijs, en een nieuw onderzoek heeft de bonnetjes26 augustus 2026

The AI MVP Evaluation Set: Test Real User Tasks Before You LaunchJuly 16, 2026

Hire the Reviewer Before the Coder: Building a Startup Engineering Team When Agents Write the Code (2026)July 31, 2026

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →