AI-agenten lopen zelden vast. Ze falen stilletjes, en onderzoek laat zien waarom

Grote taalmodelagenten beantwoorden nu supporttickets, doorzoeken databases en plannen reizen. Als er iets misgaat, geven ze meestal een zelfverzekerd antwoord en een succescode terug. Een groeiende hoeveelheid onderzoek verklaart waarom deze fouten moeilijk te herkennen zijn en hoe engineeringteams leren ze te meten.

Een fout die op succes lijkt

Traditionele software faalt doorgaans op een manier die meteen opvalt. Een functie gooit een exception, een server retourneert een foutcode en een monitoringdashboard kleurt rood. Een AI-agent gedraagt zich anders. Het is een cyclus: een taalmodel leest een prompt, besluit een tool aan te roepen, zoals een zoek-API of database, leest het resultaat en bepaalt wat het vervolgens doet. Bij elke stap kan iets misgaan, terwijl alle netwerkverzoeken in de keten toch slagen.

Neem een veelvoorkomend geval. Een weertool werkt niet en geeft de tekst “service unavailable” terug in een verder normaal antwoord. Het model leest die tekst en biedt beleefd zijn excuses aan, of erger nog, schrijft op basis van zijn trainingsgegevens een aannemelijke weersvoorspelling. De gebruiker krijgt een vloeiend antwoord. In de serverlogs staat een geslaagd verzoek met een normale latentie. Niets in een conventionele monitoringstack registreert dat er iets is misgegaan.

Modelaanbieders beschrijven dezelfde lacune in hun eigen documentatie. In de Gemini API-handleiding van Google staat dat het model “de functie niet zelf uitvoert”. Het stelt alleen een functienaam en argumenten voor; de applicatie van de ontwikkelaar voert de aanroep uit. De applicatie is daarom het enige onderdeel van het systeem dat het werkelijke resultaat ziet. Anthropics technische handleiding voor het bouwen van agents benadrukt hetzelfde punt: agents hebben bij elke stap “ground truth” uit de omgeving nodig, zoals toolresultaten, om hun eigen voortgang te beoordelen. Wanneer een tool een fout als gewone tekst meldt, klopt die ground truth niet en kan de agent dat onmogelijk opmerken.

Dit is geen nieuw soort probleem, maar een scherpere variant van een oud probleem. In 2015 beschreven Google-ingenieurs onder leiding van D. Sculley de “verborgen technische schuld” in machineleersystemen. Volgens hen schuilt het grootste deel van het risico in een ML-systeem in productie buiten de modelcode, in data-afhankelijkheden, configuratie en lijmcode. Agents voegen een nieuwe laag aan die lijst toe. Prompts en toolbeschrijvingen zijn configuratie die het gedrag van een systeem kan veranderen zonder dat de code verandert.

Kleine aanpassingen, grote gevolgen

Hoeveel verschil kan een kleine promptwijziging maken? In een paper die op ICLR 2024 werd gepresenteerd, veranderden Melanie Sclar van de University of Washington en haar collega’s alleen de opmaak van prompts met enkele voorbeelden: scheidingstekens, spatiëring en hoofdlettergebruik. De betekenis bleef hetzelfde. Toch varieerden de prestaties op dezelfde taak op LLaMA-2-13B met maximaal 76 punten op het gebied van nauwkeurigheid. De gevoeligheid verdween niet bij grotere modellen, meer voorbeelden of instructieafstemming.

De auteurs raden aan een prestatiebereik voor verschillende aannemelijke promptindelingen te rapporteren, in plaats van één getal. Voor engineeringteams is de praktische les eenvoudiger. Een prompt aanpassen is een codewijziging. Daarvoor is een versiegeschiedenis nodig, en de wijziging moet worden getest voordat die gebruikers bereikt.

Hetzelfde geldt voor toolbeschrijvingen, die het model als onderdeel van zijn prompt leest. In de handleiding van Anthropic staat dat tooldefinities “net zoveel aandacht voor prompt engineering verdienen” als de hoofdprompt. De handleiding beschrijft een codeeragent die steeds fouten maakte met relatieve bestandspaden. Nadat de tool was aangepast zodat absolute paden verplicht waren, gebruikte het model die zonder fouten. Het model veranderde niet. Alleen de beschrijving die het las, veranderde.

Eén keer succes zegt weinig

Een tweede onderzoekslijn richt zich op consistentie. De τ-bench-benchmark, gepubliceerd door Shunyu Yao en collega’s bij Sierra en gepresenteerd op ICLR 2025, simuleert klantenservicegesprekken waarin een agent tools moet gebruiken en bedrijfsregels moet volgen. De auteurs introduceerden een maatstaf met de naam pass^k: de kans dat een agent dezelfde taak bij alle k pogingen correct uitvoert.

De resultaten waren ontnuchterend. Een GPT-4o-agent voltooide ongeveer 61% van de retailtaken in één poging. Wanneer de agent dezelfde taak acht keer achter elkaar succesvol moest uitvoeren, daalde dat percentage tot ongeveer 25%. Een demo die één keer werkt, zegt weinig over hoe een systeem zich bij de duizendste uitvoering gedraagt.

Waar multi-agentsystemen vastlopen

Veel teams koppelen nu meerdere agents aan elkaar: de ene plant, een andere voert uit en een derde controleert het werk. Een onderzoek uit 2025 van UC Berkeley, “Waarom falen multi-agente LLM-systemen?”, analyseerde meer dan 1.600 geannoteerde uitvoeringstraces uit zeven populaire multi-agentframeworks. De auteurs, onder leiding van Mert Cemri, ontwikkelden een taxonomie met de naam MAST, met 14 faalwijzen in drie groepen: problemen met het systeemontwerp, gebrekkige afstemming tussen agents en taakverificatie.

Hun belangrijkste bevinding is dat veel fouten voortkomen uit het ontwerp van het systeem, en niet alleen uit de beperkingen van het onderliggende model. Agents negeren hun toegewezen rol, raken de draad van het gesprek kwijt of verklaren een taak afgerond zonder het resultaat te controleren. Deze fouten laten geen foutmelding achter. Ze zijn alleen zichtbaar als iemand kan nagaan wat elke agent daadwerkelijk heeft gedaan. De berichtgeving van Unite.AI over de paradox van multi-agentsystemen wijst vanuit architectuurperspectief op een verwant punt: extra agents kunnen een vroege fout versterken in plaats van die weg te nemen.

Het onzichtbare zichtbaar maken

De technische aanpak is ontleend aan gedistribueerde systemen, waar verzoeken al lange tijd met een techniek genaamd tracing door meerdere services worden gevolgd. Toegepast op agents wordt elk gebruikersverzoek een trace en wordt elke modelaanroep of toolaanroep daarin een ‘span’. Een span legt de invoer, de uitvoer, het aantal gebruikte tokens en de benodigde tijd vast. OpenTelemetry, de brancheorganisatie voor standaarden op dit gebied, werkt aan gedeelde conventies voor spans in generatieve AI. In 2026 zijn die conventies nog steeds aangemerkt als in ontwikkeling, waardoor de namen van attributen nog kunnen veranderen.

Verschillende open-sourceprojecten, zoals Langfuse, Arize Phoenix en AcruxCore, passen dit idee al toe. Hun broncode is openbaar, zodat teams kunnen bekijken hoe een trace wordt opgeslagen en de software op hun eigen servers kunnen draaien. Ze registreren modelaanroepen en toolaanroepen als spans binnen één trace en stellen teams in staat daar kwaliteitsscores aan toe te kennen. De keuze van de tool is minder belangrijk dan één detail: een toolspan moet vastleggen wat de tool daadwerkelijk heeft teruggegeven, niet alleen of het netwerkverzoek is geslaagd. Zonder die informatie blijft de hierboven beschreven fout met de weertool onzichtbaar.

Uit brancheonderzoek blijkt dat tracing inmiddels gangbaar is, maar dat testen achterblijft. In het najaar van 2025 ondervroeg LangChain 1.340 professionals voor het rapport over de stand van zaken in agentontwikkeling. De kwaliteit werd het vaakst genoemd als belemmering voor het in productie nemen van agents: 32% van de respondenten noemde dit. 89% van de organisaties meldde een vorm van waarneembaarheid voor hun agents, en 62% registreerde individuele stappen en toolaanroepen met gedetailleerde tracing. Slechts 52,4% voerde offline-evaluaties uit op testsets en 37,3% evalueerde liveverkeer. De meeste teams kunnen zien wat hun agents hebben gedaan. Minder teams controleren of dat correct was.

Antwoorden op grote schaal beoordelen

Traces laten zien wat er is gebeurd. Ze zeggen niet of het antwoord goed was. Elk gesprek handmatig lezen is niet schaalbaar, dus teams gebruiken steeds vaker een tweede model als beoordelaar. Deze aanpak staat bekend als LLM als beoordelaar. In een paper van NeurIPS 2023 concludeerden Lianmin Zheng en collega’s dat sterke modellen zoals GPT-4 het in meer dan 80% van de gevallen eens waren met menselijke voorkeuren, ongeveer even vaak als mensen het met elkaar eens zijn.

In hetzelfde paper werden de zwakke punten van deze methode beschreven. Beoordelingsmodellen geven de voorkeur aan het antwoord dat als eerste wordt getoond, aan langere antwoorden en soms aan tekst die ze zelf hebben geschreven. Scores van beoordelingsmodellen zijn daarom schattingen. Ze zijn nuttig bij grote aantallen, maar moeten worden getoetst aan een kleine set voorbeelden die door mensen zijn gelabeld, waarbij de volgorde van de antwoorden willekeurig wordt bepaald.

Van praktijk naar beleid

Dit meetwerk wordt ook steeds meer een vereiste op het gebied van governance. Het Amerikaanse National Institute of Standards and Technology publiceerde in januari 2023 zijn kader voor risicobeheer van AI. Een van de vier kerntaken, ‘Meten’, vraagt organisaties AI-risico’s in de loop van de tijd te kwantificeren, bij te houden en te documenteren. Voor een agent zijn traces en evaluatiescores het bewijs waar die taak om vraagt.

Wat teams nu kunnen doen

Dit sluit aan bij het argument dat op dit platform is aangevoerd: betrouwbaarheid is de echte lakmoesproef voor agentische AI. Het bovenstaande onderzoek voegt daar de details over meting aan toe: betrouwbaarheid is geen eigenschap die je één keer vaststelt, maar een bereik dat je voortdurend moet blijven meten.

Het onderzoek wijst op een aantal eenvoudige gewoonten, waarvan veel ook door de grote aanbieders van modellen worden aanbevolen. In de praktische gids van OpenAI voor het bouwen van agents wordt teams aangeraden ‘evaluaties op te zetten om een uitgangspunt voor prestaties vast te stellen’ voordat ze gaan optimaliseren. Ook adviseert de gids de controle over te dragen aan een mens wanneer een agent een vastgesteld aantal mislukte pogingen overschrijdt of met een risicovolle handeling te maken krijgt. Anthropic adviseert agents uitvoerig te testen in afgeschermde omgevingen voordat ze zelfstandig aan de slag gaan.

In de praktijk komt dat neer op een paar concrete stappen. Beheer prompts en toolbeschrijvingen, net als code, met versiebeheer. Test elke wijziging van een prompt aan de hand van een vaste dataset en houd rekening met uiteenlopende resultaten in plaats van één getal. Voer elke test meerdere keren uit, omdat één enkele test inconsistenties kan verhullen. Leg tooluitvoer vast in traces, zodat een toolfout niet verborgen blijft achter een succescode. Beschouw geautomatiseerde beoordelingsscores als schattingen en toets ze bij mensen.

Voor geen van deze gewoonten is een doorbraak in modelcapaciteiten nodig. Wel moet je een AI-agent behandelen als wat die is: een probabilistisch systeem dat je moet meten, omdat het zijn eigen fouten zelden zal aankondigen.