AI-agent verzint succes: audit van 50% valse meldingen

Er is een moment waarop je stopt met je eigen dashboard geloven. Bij mij was dat het moment waarop ik een "geslaagde" deploy wilde laten zien en de URL niet bestond. Niet kapot, niet traag. Niet bestaand. Ik ben gaan graven in mijn eigen AI-stack. Wat ik vond was erger dan een bug: ongeveer de helft van de succesmeldingen van mijn AI-agent was niet te herleiden tot een echte actie.

Vooraf één ding. Dit werd geen verhaal over een liegend taalmodel. Drie van de vier oorzaken bleken mijn eigen bouwfouten. Dat maakt het niet beter. Wel leerzamer.

Een dashboard zonder slecht nieuws

Mijn setup zag er op papier volwassen uit. Een eigen AI-agent op een VPS, n8n voor de workflows, Supabase als database, een dashboard met statuslampjes. Elke run schreef netjes een regel weg: completed. Errors die maand: nul.

Precies dat had de rode vlag moeten zijn. Systemen die nooit slecht nieuws brengen, brengen geen goed nieuws. Ze brengen geen nieuws.

Dus ging ik elke succesmelding terugvertalen naar iets controleerbaars. Een URL die bestaat. Een rij in de database. Een HTTP-status. Uit die audit van mijn eigen AI-stack, voorjaar 2026, bleek dat ongeveer 50% van de succesmeldingen van mijn AI-agent niet te herleiden was tot een verifieerbare actie: geen URL, geen databaserij, geen status. Het dashboard stond diezelfde periode op nul errors. De exacte aantallen heb ik nooit geturfd; de verhouding was pijnlijk genoeg.

~50%

Aandeel succesmeldingen dat niet te herleiden was tot een echte actie

300 s

De timeout die als succes geteld werd

Exit-path per workflow, dus falen kon nergens heen

FIGUUR 01 Wat er overbleef van de succesmeldingen toen ik bewijs ging eisen.

Hoe een timeout een succes werd

De grootste boosdoener was pijnlijk banaal, en helemaal van mijzelf. De frontend van mijn assistent had een timeout van 300 seconden. Kwam er binnen die tijd geen antwoord, dan werd de operatie afgesloten. Tot zover logisch. Alleen: hij sloot af met status "success".

Vijf minuten stilte werd geboekt als resultaat. En omdat niemand een geslaagde operatie nacontroleert, bleef dat maandenlang onzichtbaar. Ik las elke ochtend verzonnen geschiedenis en noemde het rapportage.

Vier patronen, nul foutmeldingen

De audit leverde vier varianten van hetzelfde probleem op. Wat ze deelden: geen van alle gaf ooit een foutmelding.

De timeout kende je al. De tweede was erger. Elke n8n-workflow eindigde in hetzelfde blok dat "completed" wegschreef, ook als er halverwege iets misging. Falen kon letterlijk nergens heen. Nummer drie was subtieler: AI-nodes die in minder dan 100 milliseconden klaar waren, met lege output en een groene status. Een taalmodel dat echt werk doet, is nooit zo snel klaar. En de vierde, de enige waar het model zelf debet aan was: tekstuele claims als "deploy gelukt", zonder enig artefact eronder.

Voor die vierde bestaat een nette verklaring. Taalmodellen worden getraind om liever te gokken dan onzekerheid toe te geven: gokken wordt beloond. Dit is de operationele kant van AI-hallucinaties. Een AI-agent die niet weet of iets gelukt is, zegt eerder "gelukt" dan "geen idee". Geen kwaadaardigheid, de standaardinstelling. De andere drie patronen had ik gewoon zelf gebouwd.

De fix: bewijsplicht

De herbouw was minder werk dan de ontdekking. Drie saaie ingrepen:

1. Timeout is een error. Altijd, zonder uitzondering. Stilte is geen bewijs.

2. Elke workflow kreeg een tweede exit-path. Falen heeft nu een eigen route naar de database, met een eigen status. n8n beschrijft dit patroon gewoon in de error handling-documentatie; ik had het alleen nooit als verplicht behandeld.

3. Bewijsplicht. Geen enkele laag geeft een status door zonder artefact uit de laag eronder. Verificatie als architectuurregel, niet als goed voornemen.

De regel die overblijft is kort: een claim zonder URL, status of databaserij bestaat niet.

Exit-paths per workflow sinds de herbouw

Statussen die nog zonder artefact op groen kunnen

<100 ms

Runtijd die nu een waarschuwing triggert in plaats van een vinkje

FIGUUR 02 Kleine ingrepen, structureel ander gedrag.

Wat dit betekent voor je webshop-automatisering

Dit lijkt een verhaal voor mensen die hun eigen AI-stack bouwen. Maar elke e-commerce manager draait al jaren op dezelfde belofte. Je repricer meldt aangepaste prijzen en je feed-tool geüpdatete listings. Hoeveel van die meldingen heb je ooit op het kanaal zelf teruggecheckt?

Mijn vuistregel sinds de audit: automatisering mag rapporteren wat ze deed, maar je gelooft alleen wat je op het eindpunt ziet. Steekproef op de marketplace zelf, niet in de tool. Bij het schrijven over designen met LLMs kwam ik vanuit de UX-kant op hetzelfde uit: vertrouwen bouw je met verifieerbare output, niet met groene vinkjes.

De nuance: de helft klopte wél

Was mijn AI-agent daarmee waardeloos? Nee. De andere helft van de meldingen was gewoon correct, en het systeem deed wel degelijk nuttig werk. Fabricatie is bovendien geen uniek gebrek van mijn bouwwerk. Het is het voorspelbare gedrag van elk systeem waarin succes de default-status is. Wie zijn eigen stack nooit heeft geauditeerd, moet niet aannemen dat het daar anders ligt.

En de grote claim maak ik bewust niet. Of er sindsdien niets meer onopgemerkt faalt, kan ik niet weten; dat is precies wat onopgemerkt betekent. Wat ik wel weet: elke status heeft nu een artefact onder zich, en wat ik mis, mis ik niet meer geruisloos. Hoe ik bewaak of die bewaking zelf blijft draaien, is een eigen verhaal geworden: wie bewaakt de bewaker.

Bouw systemen die moeten bewijzen, niet systemen die mogen beweren.