Ik bekijk dit als iemand die systemen bouwt, test en regelmatig tegen onverwachte problemen aanloopt. IBM en UC Berkeley maakten een heldere stap: ze keken niet alleen of agenten falen, maar waarom. Voor ondernemers met IT-automation of voor marketeers die technologie inzetten: dit zijn bruikbare lessen, geen abstracte theorie.
Het probleem: succespercentages verbergen de echte fouten
Benchmarks zoals ITBench geven een simpel cijfer: geslaagd of niet. Dat is handig om te vergelijken, maar weinig bruikbaar als je wilt verbeteren. Een 14 procent succesratio zegt alleen dat iets faalt, niet welke zwakke schakel het werk daadwerkelijk stopt. In de praktijk wil je weten: vergat de agent context, hallucineerde hij een commando of stopte hij te vroeg? Dat onderscheid bepaalt je volgende stap.
MAST: een bruikbare manier om te ontleden wat er misgaat
MAST staat voor Multi‑Agent System Failure Taxonomy. In plaats van alleen resultaten telt het MAST‑patronen in uitvoerlogs en vertaalt die naar failure modes zoals herhaling van stappen, verlies van gesprekshistorie, verkeerde verificatie of het niet vragen om verduidelijking. Dat maakt falen diagnoseerbaar: je ziet niet alleen dat iets misging, maar welk mechanisme faalde.
Wat ze deden: MAST toepassen op ITBench‑traces
IBM en Berkeley analyseerden 310 SRE‑traces uit ITBench, uitgevoerd met drie modelklassen: een frontier model (Gemini‑3‑Flash), een middelgrote open modelvariant (Kimi‑K2) en een grote open variant (GPT‑OSS‑120B). Door elke trace te annoteren met MAST‑labels konden ze patronen tellen en vergelijken — niet alleen hoeveel successen, maar welke fouten steeds terugkomen en welke echt dodelijk zijn voor een run.
Belangrijkste eerste vondst: surgical versus cascaderend falen
Sterkere modellen zoals Gemini hebben vaak een schoon, ‘surgical’ falen: weinig fouttypes per mislukte run, meestal één zwakke schakel zoals incorrecte verificatie. Open modellen laten vaker cascaderend falen zien: één vroege mismatch verontreinigt de context en leidt tot meerdere fouten achter elkaar. Kimi zit daartussen: complexer dan de frontier maar niet zo chaotisch als de 120B‑variant.
Belangrijkste tweede vondst: non‑fatal en fatal fouten
Niet alle fouten zijn even schadelijk. Sommige verschijnen ook in succesvolle runs en zijn herstelbaar, zoals stapherhaling of lichte afwijking van specificaties. Andere voorspellen bijna zeker een mislukking — bijvoorbeeld incorrecte verificatie (agent verklaart dat het probleem opgelost is zonder harde bewijs) of het niet herkennen van stopcondities. Het verschil is belangrijk: investeer je moeite in weghalen van structurele fricties of in het voorkomen van dodelijke fouten?
Casestudy: Gemini‑3‑Flash — snel en besluitvaardig, maar te zelfverzekerd
Gemini presteert hoog maar maakt één terugkerende fout: het stopt te vroeg omdat het eigen oordeel als voldoende bewijs ziet. Dat leidt tot veel "declare victory"‑situaties zonder tool‑gebaseerd bewijs. De praktische remedie is simpel: laat het model niet zijn eigen werk beoordelen. Bouw een externe verificatiestap in die op basis van concrete tooloutputs bepaalt of de run echt klaar is.
Casestudy: Kimi‑K2 — de terminatiecrisis en uitvoeringskloof
Kimi heeft twee opvallende problemen. Ten eerste herkent het model vaak niet wanneer het klaar is, waardoor het vroeg stopt of eindeloos blijft draaien. Ten tweede beschrijft het vaak een correcte vervolgstap maar voert vervolgens een onjuiste of overbodige actie uit. Dat wijst op een kloof tussen redeneerstappen en uitvoering. Een deterministische state machine of expliciete loop‑detectie buiten het model helpt hier rechtstreeks.
Casestudy: GPT‑OSS‑120B — geheugenverlies en kettingreacties
De open 120‑miljard‑variant vertoont de meest instabiele gedragslijn. Hij verliest vaker gesprekshistorie na langere traces en vergeet daardoor oorspronkelijke alerts of doelstellingen. Kleine redeneerfouten stapelen zich op en veroorzaken kettingfouten. Voor deze modellen is context‑hygiene cruciaal: expliciete context‑samenvattingen, vroegtijdige foutdetectie en strikte checks voorkomen dat een kleine mismatch het hele proces kapot maakt.
Wat je praktisch meteen kunt doen
Er zijn drie korte, concrete ingrepen die veel effect hebben. Ten eerste: externaliseer verificatie — sluit runs alleen af op basis van harde tool‑evidentie in plaats van modelselfscores. Ten tweede: haal termination‑ en loopcontrole uit de LLM‑logica en leg die in een eenvoudige state machine of in expliciete stopcondities met loopdetectoren. Ten derde: behandel onduidelijkheid als eerste klap — dwing een clarify‑of‑read‑only tak af wanneer input vaag is, zodat kleine misverstanden niet uitgroeien tot kettingfouten.
Waarom dit relevant is voor Nederlandse ondernemers
Als je automation inzet, wil je voorspelbaarheid en lage onderhoudslast. MAST helpt je precies te zien welke problemen je systeem maakt en welke interventies het meeste rendement geven. In de praktijk betekent dat minder tijd besteden aan trial‑and‑error prompts en meer aan concrete engineering: verificatiepoorten, terminatieregels en contextmanagement. Dat spaart tijd, reduceert incidenten en maakt automation betrouwbaarder voor je team.
Conclusie: meten moet leiden tot gerichte acties
De grootste waarde van werk als dit is niet de observatie dat "open modellen meer fouten hebben", maar de vertaling naar bruikbare ontwerpkeuzes. Als je agenten inzet in kritische IT‑werkstromen, kijk dan verder dan success‑percentages. Gebruik failure taxonomieën zoals MAST om logs te vertalen naar concrete fixes: externe verificatie voor zekere modellen, state machines voor wispelturige terminatie, en context‑hygiëne voor geheugen‑kwetsbare modellen. Dat is precies het soort aanpak dat je kunt toepassen zonder onnodig risico.