ThinkingBox beoordeelt AI‑agenten op database‑resultaten en herhaalde betrouwbaarheid
Microsoft‑onderzoekers hebben ThinkingBox gelanceerd, een benchmark die AI‑agenten beoordeelt op basis van de uiteindelijke staat van zakelijke databases in plaats van op conversatie‑vloeiendheid, en zo grote verschillen blootlegt tussen tool‑aanroepen en de werkelijke effecten in de praktijk.

4 oktober 2026 – Microsoft‑onderzoekers hebben ThinkingBox op Hugging Face uitgebracht, waarmee een geheel nieuwe manier wordt geïntroduceerd om grote‑taalmodel‑agenten (LLM‑agenten) te evalueren die met externe tools communiceren. In tegenstelling tot eerdere benchmarks die een correct antwoord in natuurlijke taal of een syntactisch geldige tool‑aanroep belonen, meet ThinkingBox de uiteindelijke backend‑status en de neveneffecten nadat een agent een volledige bedrijfsworkflow heeft uitgevoerd. De benchmark bevat 507 verschillende, stateful bedrijfsprocessen – zoals orderinvoer, voorraadupdate of wijziging van klantrecords – die elk 20 keer worden uitgevoerd in geïsoleerde Microsoft Copilot (MCP)‑tool‑sessies. Door de nadruk te leggen op de feitelijke database‑resultaten, beoogt de suite betrouwbaarheid‑problemen aan het licht te brengen die pas na herhaald, real‑world gebruik zichtbaar worden.
Hoe ThinkingBox werkt
Elk van de 507 workflows is gecodeerd als een opeenvolging van tool‑aanroepen die een relationele database manipuleren. Voor elke proef wordt een volledige isolatie van de MCP‑tool‑omgeving uitgevoerd, zodat er geen kruis‑run‑vervuiling kan optreden die fouten zou kunnen maskeren. Nadat de agent een run heeft voltooid, inspecteert ThinkingBox het definitieve databasesnapshot en vergelijkt dit met een grondwaarheidspecificatie die de verwachte rijen, kolomwaarden en neveneffecten zoals audit‑logs opsomt. Het beoordelingsrubriek houdt geen rekening met of de agent een vloeiende tekstuele samenvatting heeft geproduceerd; het registreert uitsluitend of de backend‑staat overeenkomt met de specificatie, of er onbedoelde wijzigingen zijn opgetreden, en of een tool een fout heeft gerapporteerd.
De evaluatie omvatte 12 publiek beschikbare LLM‑agenten, variërend van open‑source‑modellen tot commerciële aanbiedingen. In totaal genereerde het experiment 121 680 geldige proeven – het product van 507 workflows, 20 herhalingen en de 12 modellen. Van deze proeven faalden 79 853 pogingen in de uitvoerbare‑check‑fase, wat betekent dat de agent ofwel geen vereiste tool‑aanroep deed of een aanroep produceerde die niet kon worden geparseerd. Opmerkelijk is dat 67,24 % van die mislukte pogingen toch zonder een definitieve tool‑fout eindigde, nadat ze ten minste één state‑veranderende tool hadden aangeroepen voordat ze stopten. Dit patroon benadrukt een scheiding tussen de schijnbare successtatus van een agent en de verborgen inconsistenties die in de database achterblijven.
Belangrijkste bevindingen
Wanneer een proef faalde in de uitvoerbare‑check, registreerde de benchmark drie categorieën van afwijking. Verkeerde veldwaarden verschenen in 77,61 % van de mislukte pogingen, wat aangeeft dat agenten vaak onjuiste data schreven zelfs wanneer een tool‑aanroep succesvol was. Onbedoelde effecten – acties die delen van de database wijzigden die niet in de workflow waren gespecificeerd – werden waargenomen in 43,30 % van de fouten, terwijl ontbrekende effecten – verwachte wijzigingen die nooit tot stand kwamen – zich voordeden in 25,36 % van de gevallen. De percentages overlappen omdat één enkele run meerdere fouttypen tegelijk kan vertonen. Deze cijfers tonen aan dat een meerderheid van de tool‑gedreven fouten de database toch in een inconsistente of gedeeltelijk correcte staat achterlaat.
De prestaties varieerden sterk tussen de modellen. Claude Opus 5.5 behaalde de hoogste pass@1‑score en slaagde in 67,16 % van de 121 680 proeven bij de eerste poging. Kimi‑K3 liet een ander profiel zien: het loste 93,89 % van de taken ten minste één keer op in de 20 herhalingen, maar slechts 13,41 % van de runs slaagde in elke afzonderlijke herhaling. Dit contrast onderstreept het belang van het meten van betrouwbaarheid over herhaalde uitvoeringen in plaats van een enkele best‑case run. De overige modellen vielen tussen deze uitersten, waarbij veel een pass@1‑percentage onder de 50 % lieten zien en aanzienlijke variabiliteit vertoonden tussen de verschillende herhalingen.
Beperkingen van de benchmark
ThinkingBox is opzettelijk beperkt tot een samengestelde set zakelijke workflows, en de auteurs benadrukken dat de cijfers niet elke productiescenario weerspiegelen dat een onderneming kan tegenkomen. De benchmark isoleert elke proef in een verse MCP‑sessie, waardoor de invloed van langdurige staat‑opbouw, caching of cross‑workflow‑afhankelijkheden die in live‑systemen bestaan, wordt verwijderd. Bovendien richt de evaluatie zich uitsluitend op relationele database‑uitkomsten; agenten die interacteren met niet‑SQL‑services, bestandssystemen of externe API‑’s worden niet meegenomen. Ten slotte behandelt de metriek elke afwijking van de grondwaarheidspecificatie als een mislukking, zelfs wanneer die afwijking in een specifieke zakelijke context onschadelijk zou kunnen zijn.
- 79 853 pogingen faalden in de uitvoerbare‑check van de 121 680 totale proeven.
- 67,24 % van de mislukte pogingen eindigde netjes zonder een definitieve tool‑fout.
- 77,61 % van de fouten rapporteerde verkeerde veldwaarden in de database.
- 43,30 % van de fouten veroorzaakte onbedoelde neveneffecten.
- 25,36 % van de fouten miste verwachte effecten.
- Claude Opus 5.5 leidde pass@1 met 67,16 % succes.
- Kimi‑K3 loste 93,89 % van de taken ten minste één keer op, maar slechts 13,41 % in alle 20 runs.
De praktische implicaties zijn direct voor ontwikkelaars die AI‑gedreven automatisering bouwen. Door bloot te leggen hoe vaak agenten stilzwijgend verkeerde data schrijven of vereiste updates missen, stimuleert ThinkingBox een verschuiving van de vraag “slagen de tool‑aanroepen?” naar “is de database uiteindelijk correct?”. Teams kunnen de benchmark nu gebruiken om robuustheidstesten te prioriteren, compenserende transacties toe te voegen of prompts te herontwerpen die beter idempotent gedrag afdwingen. De gegevens geven leveranciers bovendien een concreet doel: de herhaalbaarheid over meerdere runs verbeteren, niet alleen een hoge single‑shot pass‑rate behalen. Naarmate ondernemingen LLM‑agenten inzetten voor kritieke back‑office taken, wordt het vermogen om te certificeren dat de onderliggende data betrouwbaar blijven een onderscheidende concurrentiefactor.
Vooruitkijkend plannen Microsoft en de bredere onderzoeksgemeenschap om ThinkingBox uit te breiden met extra workflow‑categorieën, uitgebreidere tracking van neveneffecten en integratie met continue‑integratie‑pijplijnen. De benchmark is al beschikbaar op Hugging Face, waardoor iedereen dezelfde 507 workflows kan uitvoeren tegen hun eigen agenten en de resultaten kan vergelijken met de gepubliceerde baseline. Door outcome‑gerichte evaluatie open en herhaalbaar te maken, staat ThinkingBox op het punt de manier waarop de industrie AI‑agentbetrouwbaarheid meet te veranderen, en de discussie te verplaatsen van oppervlakkige correctheid naar de diepere vraag of de database – de ultieme bron van waarheid – het beoogde zakelijke resultaat weerspiegelt.
Bronnen
- The Agent Said It Was Done. The Database DisagreedMicrosoft / Hugging Face · 3 oktober 2026
- ThinkingBox paperarXiv · 31 augustus 2026



