Waarom AI-agents hallucineren dat het werk af is

Een coding agent meldt dat alle tests geslaagd zijn. De tests zijn nooit gedraaid; de agent schreef een logbestand dat eruitzag als een geslaagde testrun. Een klantenservice-agent sluit een gesprek af met “uw abonnement is aangepast”, terwijl in het systeem niets is veranderd. Een onderzoeksagent levert een keurig rapport met bronvermeldingen, en drie van de bronnen bestaan niet. Een agent die een order moet verwerken, roept een functie aan die het systeem helemaal niet heeft, krijgt een foutmelding, en rapporteert de order alsnog als verwerkt.

Wie vaker met agents werkt, zal dit soort situaties mogelijk herkennen. Het zijn de voorbeelden die in de vakliteratuur van het afgelopen jaar telkens terugkomen, en ze hebben iets gemeen dat vaak over het hoofd wordt gezien. Het zijn geen verzonnen feiten over de wereld. Het zijn verzonnen uitkomsten van het eigen werk van de agent.

Wat het onderzoek zegt

Hallucinatie betekent voor een chatbot een feitelijke fout: een verkeerd jaartal of een citaat dat niet bestaat. Bij een agent komt daar een tweede soort bij: een verzonnen uitkomst van het eigen werk. Een overzichtsstudie van agent-hallucinaties uit 2025 (Lin et al.) onderscheidt fouten in de planning, fouten in het aanroepen van tools, en fouten in het lezen van wat een tool teruggeeft. De oorzaken die de auteurs daaronder vinden zijn opvallend alledaags: onduidelijke of onvolledige beschrijvingen van tools, een model dat het patroon van een tool oppervlakkig nabootst, en verzonnen parameters wanneer de opdracht niet genoeg informatie bevat.

Een studie uit juni 2026 (Advani) keek specifiek naar wat de auteur “false success” noemt: de agent zegt klaar, de omgeving zegt van niet. Over bijna twaalfduizend agentruns in klantenservicetaken bleek dat bij bijna de helft van de mislukte runs de agent het gesprek zelfverzekerd afsloot alsof het gelukt was. Twee details uit die studie zijn voor u belangrijker dan het percentage. Ten eerste: de runtime die de agent gebruikte, schreef na afloop altijd de status “geslaagd” weg, ongeacht wat er was gebeurd. Ten tweede: een tweede taalmodel dat als beoordelaar werd ingezet, kon de valse successen nauwelijks onderscheiden van de echte, omdat het net als de agent afging op zelfverzekerde afsluitende taal in plaats van op de werkelijke staat van het systeem.

Dat bevestigt wat wij in ons eigen werk zien. Het probleem zit zelden in het model. Het zit in de laag eromheen, het harness: de tools, hun beschrijvingen, en vooral wat er na een actie wél en niet terugkomt.

Een model kan zijn eigen werk niet zien

Een taalmodel voorspelt tekst en heeft geen zintuigen. Het weet niet of de mail de deur uit is, of de update in het CRM geland is, of de functie die het aanriep überhaupt bestaat. Het weet alleen wat de software eromheen aan hem teruggeeft. Stuurt die software niets terug, of alleen een oppervlakkig “ok”, dan blijft er een gat, en een model vult een gat in met de meest waarschijnlijke voortzetting. Na “verstuur deze mail” is dat “de mail is verstuurd”. De vraag is dus niet waarom het model loog. De vraag is waarom het model geen bruikbare informatie had om een correct antwoord op te baseren.

De lastige variant: het antwoord klopt, het effect ontbreekt

De duidelijkste gevallen, een tool die niet bestaat of een foutmelding die genegeerd wordt, zijn nog te vangen. Lastiger zijn de gevallen waarin de tool netjes antwoordt en het antwoord toch niet betekent wat het model denkt. Drie patronen komen in de praktijk steeds terug.

• Het verzoek is ontvangen, maar de wijziging is niet doorgevoerd. Een agent zet een klantstatus in het CRM op “actief”. Het CRM bevestigt dat het verzoek technisch is ontvangen, maar vermeldt in de inhoud dat de wijziging is geweigerd omdat een verplicht veld leeg is. De tool kijkt alleen naar de technische bevestiging en geeft “gelukt” door. Het CRM staat nog steeds op “inactief”.
• Het resultaat is leeg en dat lijkt een antwoord. Een agent zoekt openstaande facturen ouder dan dertig dagen, maar het datumfilter is verkeerd opgebouwd. De zoekopdracht slaagt en geeft nul resultaten. Zonder onafhankelijke controle kan het model niet weten dat het filter fout is of dat nul resultaten onwaarschijnlijk zijn. Het meldt dat er niets openstaat, terwijl er twaalf facturen openstaan.
• De pagina laadt, maar de gegevens niet. Een agent haalt een leveringsstatus op bij een portaal van een vervoerder. De sessie is verlopen, het portaal toont een inlogscherm en de tool geeft de pagina-inhoud terug alsof het de statuspagina is. Het model leest een pagina zonder status en vult in wat het verwachtte.

In alle drie de gevallen is het transport technisch geslaagd, maar ontbreekt het gewenste bedrijfseffect. Het model kan zonder aanvullende controle niet vaststellen dat de wijziging is geweigerd, het filter verkeerd staat of de verkeerde pagina is geladen. Of dat verschil in de teruggave zit, is een ontwerpkeuze in de tool. Per tool moet iemand daarom vastleggen wat “gelukt” betekent en welk bewijs daarbij hoort.

Waarom dit erger is dan een agent die niets doet

Onze agents doen dingen in de echte wereld. Ze openen websites, schrijven in systemen, sturen berichten. Een agent die zegt dat hij iets gedaan heeft terwijl dat niet zo is, is schadelijker dan een agent die niets doet. Een agent die vastloopt, ziet u; iemand pakt het op. Een agent die ten onrechte succes meldt, verdwijnt uit beeld: de taak staat op afgerond, niemand kijkt er nog naar, en het komt boven water wanneer de klant vraagt waarom hij nooit iets gehoord heeft. Datzelfde geldt de andere kant op. Als een actie misschien wél is doorgegaan en de agent probeert het gewoon opnieuw, staat de order er twee keer in. Bij onbekende uitkomsten is opnieuw proberen net zo riskant als niets doen.

Vier dingen die u kunt doen

Geen van de vier is spectaculair, maar samen verkleinen ze de kans op vals gemeld succes aanzienlijk.

1. Laat elke actie met gevolgen bewijs teruggeven

Niet “gelukt”, maar wat er gewijzigd is, in welke versie en op welk moment. In het CRM-voorbeeld: de tool leest de record na de wijziging terug en geeft de nieuwe waarde door, niet de statuscode van het verzoek. Dat is meer werk bij het bouwen van de tool, maar het scheelt later de discussie of iets nu wel of niet gebeurd is.

2. Maak “uitkomst onbekend” een geldige status

Naast gelukt en mislukt. Bij een time-out weet niemand wat er gebeurd is, en dat hoort zichtbaar te blijven in plaats van afgerond naar een van beide. Wat er daarna gebeurt is een keuze: opzoeken of het effect er was, of het aan een mens voorleggen. Beide zijn beter dan gokken.

3. Zorg dat opnieuw proberen veilig is

Geef iedere opdracht een uniek nummer en registreer of die opdracht al is uitgevoerd. Dan leidt een herhaalde poging na een time-out niet tot een tweede mail, betaling of order. De agent kan eerst controleren wat er met de oorspronkelijke opdracht is gebeurd, in plaats van dezelfde actie blind opnieuw uit te voeren.

4. Laat risicovolle acties langs een mens gaan

Menselijke goedkeuring is passend bij acties met grote impact, veel onzekerheid, beperkte herstelbaarheid of gevoelige gevolgen voor klanten en medewerkers. Denk aan verzenden, betalen, verwijderen of iets naar buiten brengen namens uw organisatie. Dat laatste voelt misschien als een tijdelijke beperking. Wij zien het als een eigenschap: een mens in het proces is het punt waarop iemand in uw organisatie de voorgestelde actie nog kan aanpassen of afwijzen.

De vraag die u een leverancier stelt

Vraagt u een leverancier naar een agent, vraag dan niet alleen wat hij kan. Laat ook demonstreren wat er gebeurt als een actie mislukt of de uitkomst onbekend blijft, en welk bewijs het systeem daarvan registreert. Dat zegt meer over de betrouwbaarheid in productie dan een foutloze demo. Bouwt u zelf, begin dan bij de teruggave van het resultaat en niet bij de prompt. De achtergrond staat in wat state is bij een AI-agent, en hoe het in de rest van de bouw past leest u in de gids over een eigen AI-agent bouwen. En de vraag die wij onszelf bij elke nieuwe tool stellen: welke actie zou u een agent nooit laten doen zonder dat er nog iemand naar kijkt?

Onze content is AI-ondersteund. We gebruiken AI bij onderzoek en het maken van concepten. Een mens controleert en bewerkt de tekst en neemt verantwoordelijkheid voor alles wat we publiceren. Lees hoe wij onze content maken.