Je Agent Wordt een Beetje Raar

Waarom AI in productie behoefte heeft aan testen, observability, feedbackloops en lifecycle-eigenaarschap, lang nadat de demo voorbij is

We kennen het verhaal allemaal.

Een programmeur bouwt een tool voor één heel specifiek gebruiksscenario. QA test hem van alle kanten, onder de meest uiteenlopende omstandigheden die geen redelijk mens ooit zou proberen. En toch doorstaat hij elke test.

Dan krijgt een gebruiker hem in handen. 

Die gebruikt hem in een onverwachte workflow, past hem toe op een probleem dat niemand had voorzien, en vraagt hem iets te doen dat nooit in de requirements stond. Denk aan de klantenservice-chatbot van een fastfoodketen die ineens dienstdoet als noodoplossing om code te debuggen, omdat de gebruiker toevallig door zijn tokens heen is.

AI-agents zijn hier niet immuun voor. Sterker nog, ze kunnen nog overtuigender zijn wanneer ze de fout ingaan.

Heb jij ooit te maken gehad met een agent die met overtuigend, indrukwekkend zelfvertrouwen ongelijk had? Het soort fout waarbij je even stilstaat en je afvraagt: hoe is dit langs QA gekomen?

Gefeliciteerd. Je AI-agent heeft het tot productie geschopt.

Helaas heeft productie ook gebruikers.

De agent die schitterde in een gecontroleerde demo kan nog steeds snel reageren, gezonde API's teruggeven en een groen monitoringdashboard laten zien, terwijl hij ondertussen rustig de verkeerde dingen doet.

Technisch gezien ligt er niets “plat”.

En toch voelt iedereen die het systeem gebruikt dat er iets niet klopt.

Welkom bij AI in productie.

De wereld veranderde. Je agent niet.

AI-agents opereren binnen organisaties waar alles om hen heen verandert: data, API's, rechten, modellen, workflows en gebruikersgedrag.

Dat levert verschillende, duidelijk te onderscheiden soorten productie-eigenaardigheden op:

1. Kennisdrift: De agent haalt informatie op die vroeger klopte, maar die nu niet meer doet.
2. Tooldrift: De API bestaat nog wel, maar gedraagt zich niet meer zoals de agent verwacht.
3. Rechtendrift: De agent verliest toegang tot iets wat hij nodig heeft, of krijgt juist toegang tot iets wat hij niet zou moeten hebben.
4. Model- en promptdrift: Een schijnbaar kleine wijziging levert onverwacht ander gedrag op.
5. Workflowdrift: De agent volgt trouw een proces dat de organisatie drie maanden geleden heeft aangepast, maar niemand heeft de agent daarover ingelicht.
6. Gebruiksdrift: Mensen doen iets waarvan niemand bij het ontwerp van het systeem had gedacht dat ze het zouden doen.

En gebruiksdrift verdient bijzondere aandacht.

En dan komen de mensen

Gebruikers combineren meerdere bedoelingen in één verzoek, verzinnen workflows die je nooit hebt ontworpen, zoeken de grenzen op en gebruiken het systeem voor dingen waar het nooit voor bedoeld was.

Ze zullen hem ook corrigeren, er omheen werken en hem soms gewoontes aanleren die je hem liever niet had zien leren.

Die menselijke creativiteit hoeft geen probleem te zijn. Sterker nog, productiegebruik is een van de rijkste informatiebronnen die een AI-engineeringteam tot zijn beschikking heeft. Je gebruikers worden in de praktijk je grootste testsuite.

Maar helaas maken ze geen Jira-tickets aan.

In systemen met persistent geheugen, status, retrieval en orkestratie doen die interacties ertoe, omdat elementen uit eerder gebruik kunnen bepalen wat er daarna gebeurt.

Ervaring opbouwen is echter niet hetzelfde als leren.

Geheugen zonder feedback is stapelen, niet leren

Eén van de gevaarlijkste aannames in AI in productie is dat een agent, omdat hij geheugen heeft, op een gegeven moment vanzelf wel beter zal worden.

Geheugen alleen zorgt voor opstapeling.

Verbetering vraagt om een bewust ontworpen feedbackloop.

Een duimpje-omhoog- of duimpje-omlaagknop is dat niet. Logs of telemetrie zijn dat ook niet. Die mechanismen leveren signalen op; de belangrijke vraag is wat er daarna met die signalen gebeurt.

Er is pas sprake van een echte feedbackloop wanneer feedback leidt tot engineering-actie:

Observeren → Evalueren → Corrigeren → Valideren → Verbeteren

Als gebruikers herhaaldelijk slechte retrieval-resultaten krijgen, moet misschien de retrieval-strategie veranderen. Als de agent steevast de verkeerde tool kiest, ligt het probleem misschien bij de tooldefinitie of de routeringslogica. Als gebruikers een nieuw randgeval ontdekken, hoort die interactie een nieuw evaluatiescenario te worden.

En als mensen de agent voortdurend overrulen, is dat niet alleen frustrerend. Het is operationele data.

Een duimpje-omlaagknop die niemand bekijkt, is niet meer dan een klein digitaal klachtenbusje.

Je monitoringdashboard liegt misschien tegen je

Traditionele monitoring kan je vertellen of de dienst beschikbaar is, of de API gezond is, of de responstijd acceptabel is en of er een fout is opgetreden.

Een AI-agent kan al die checks doorstaan en toch slecht presteren.

Daarom moet AI-observability verder reiken dan alleen de gezondheid van de infrastructuur: het moet ook het gedrag van de agent, de kwaliteit van de output en de zakelijke uitkomst omvatten.

Als een gebruiker je vertelt: “De agent zei gisteren iets vreemds,” moet je engineeringteam het hele traject kunnen reconstrueren: het verzoek van de gebruiker, het beschikbare geheugen en de context, het retrieval-resultaat, de routeringsbeslissing, de toolkeuze, de tooluitvoering, de reactie en de uitkomst. Met andere woorden: je moet de situatie kunnen reconstrueren.

“Hij zei gisteren iets vreemds” is geen observability-strategie.

Met tracing kun je precies zien waar het gedrag afweek, in plaats van alleen maar te ontdekken dat het uiteindelijke antwoord niet deugde.

Maak van de gekte een test

Productiegebruik hoort je evaluatieset voortdurend te verbeteren.

De scenario's die vóór lancering werden gebruikt, mogen niet voor altijd bevroren blijven. Gebruikers zullen gevallen blootleggen die je niet had voorzien, en de organisatie zal situaties creëren die niemand kon voorspellen toen het systeem voor het eerst werd ontworpen.

Elke interactie die vreemd genoeg is, zou daarom onderwerp moeten worden van een regressietest.

Eén keer vreemd is een incident.

Twee keer vreemd is een patroon.

Drie keer vreemd? Gefeliciteerd, misschien heb je zomaar een feature te pakken.

De grap doet er minder toe dan het principe: productie hoort je begrip van hoe het systeem kan slagen en falen voortdurend te vergroten.

De gebruikers die je meest bizarre fouten blootleggen, wijzen vaak op requirements waarvan je niet wist dat je ze had.

Versiebeheer voor alles wat je kan verraden

Agentic systemen kunnen van gedrag veranderen, zelfs als de applicatiecode niet verandert.

Modellen, prompts, retrieval-indexen, tooldefinities, orkestratieregels, geheugenbeleid, vangrails en evaluatiedata kunnen allemaal de prestaties beïnvloeden.

Dat maakt traceerbaarheid essentieel.

Als je niet kunt vaststellen wat er is veranderd, kun je niet betrouwbaar vaststellen wat er is misgegaan.

Terugdraaien wordt ook lastiger. Misschien moet je een model terugzetten, een eerdere prompt herstellen, een retrieval-configuratie terugdraaien, een tooldefinitie wijzigen, een orkestratiewijziging ongedaan maken, of ingrijpen in het persistente geheugen en de status.

AI in productie vraagt daarom om operationele discipline over alle onderdelen die het gedrag vormgeven, niet alleen over de applicatiecode.

Wie is hier nu eigenlijk verantwoordelijk voor?

Organisaties steken enorm veel energie in de beslissing wie de agent gaat bouwen. Ze besteden aanzienlijk minder tijd aan de beslissing wie er na de lancering eigenaar van is.

Iemand moet feedback en evaluatieresultaten beoordelen. Iemand moet weten wanneer kennisbronnen verouderd raken of integraties veranderen. Iemand moet de bevoegdheid hebben om wijzigingen aan prompts, tools, modellen en orkestratie goed te keuren. Iemand moet bepalen wanneer de agent moet stoppen, wanneer hij moet escaleren naar een mens, of wanneer hij met pensioen moet.

Zonder eigenaarschap wordt AI in productie al snel de verantwoordelijkheid van iedereen, en dus van niemand.

Een agent uitrollen zonder duidelijk eigenaarschap is een beetje als een aap loslaten in de organisatie.

Hij kan intelligent zijn. Hij kan verrassend capabel zijn. Hij kan zelfs indrukwekkende dingen voor elkaar krijgen.

Maar iemand moet nog steeds verantwoordelijk zijn voor wat hij doet.

Uitrol is niet het einde van een AI-project.

Uitrol is het begin van de operatie.

AI in productie is een levenscyclus

Agentic systemen hebben doorlopende mechanismen nodig om vreemd gedrag op te sporen, te diagnosticeren, te corrigeren, herhaling te voorkomen, en uiteindelijk met pensioen te sturen wat de organisatie niet langer nodig heeft.

Dat betekent dat testen, evaluaties, observability, tracing, menselijke review, versiebeheer, terugdraaien, governance en eigenaarschap allemaal bij dezelfde levenscyclus horen.

Uiteindelijk zouden sommige agents moeten verdwijnen.

Een workflow kan verouderen. Functionaliteit kan overbodig worden. Onderhoudskosten kunnen zwaarder wegen dan de waarde die het oplevert. Een nieuwere functionaliteit kan de oorspronkelijke agent volledig vervangen.

Een agent in leven houden alleen omdat iemand hem ooit heeft gebouwd, is geen operationele strategie.

Een geplande pensionering is aanzienlijk beter dan een langzame afglijding naar chaos.

Stop met AI implementeren en het daarna te vergeten

De volgende fase van AI-volwassenheid in organisaties wordt niet alleen bepaald door wie agents kan bouwen.

Ze wordt bepaald door wie ze kan laten draaien.

Dat vraagt om meer dan prompts schrijven of een model kiezen. Het vraagt om architecten, engineers, security-teams, business leaders en eindgebruikers die begrijpen hoe deze systemen zich gedragen zodra ze onderdeel worden van een levende organisatie.

Simpelweg meer agents bouwen is geen doel op zich.

Het doel zou moeten zijn om organisaties te bouwen die in staat zijn ze bruikbaar, veilig, observeerbaar en afgestemd te houden, keer op keer.

Je AI-agent spookt waarschijnlijk niet.

Je bent hem alleen vergeten te laten draaien.