Waarom je agent in demo's werkt en in productie valt

Voor wie? Developers en ML engineers die al een werkende AI-agent hebben gebouwd — in een notebook, een interne tool, een prototype — en willen begrijpen waarom die agent het in productie moeilijker heeft dan in de demo. Je bent vertrouwd met het idee van een agent die externe diensten aanroept en beslissingen neemt op basis van een taalmodel, maar je hebt nog geen productie-ervaring met agents.

Kort: Een agent die in een demo werkt, faalt in productie bijna nooit door een fout in de code. Hij faalt door vier structurele problemen die je in een gecontroleerde testomgeving niet ziet. Dit artikel legt die patronen uit met concrete voorbeelden — en sluit aan bij wat we in de tweedaagse workshop voor developers hands-on doorwerken.

Wat bedoelen we met “agent”? Een AI-agent is een programma dat een taalmodel gebruikt om zelfstandig stappen te zetten: het beslist wat het volgende doet, roept externe diensten aan (een database, een API, een zoekmachine), verwerkt de resultaten en gaat verder — zonder dat een mens elke stap goedkeurt. Het verschil met een gewone chatbot: een chatbot antwoordt. Een agent handelt.

Je agent werkt. De demo loopt soepel, de uitvoer klopt, je collega’s zijn onder de indruk. Twee weken later, in productie, doet hij iets wat je niet verwacht had. Of hij doet niets meer. Of hij blijft dezelfde stap herhalen tot het kostenplafond bereikt is.

Dit is geen uitzonderingsgeval. Het is het patroon.

Waarom de demo misleidt

Een demo is een gecontroleerde omgeving. Je kiest de invoer, je weet wat het systeem moet teruggeven, en je stopt de demonstratie op het moment dat het goed gaat. Productie is het tegenovergestelde: onvoorspelbare invoer, trage of falende externe diensten, gebruikers die doen wat jij niet had voorzien.

Neem een agent die klantvragen beantwoordt door een kennisbank te doorzoeken. In de demo stel je hem vijf vragen die je zelf hebt opgesteld. Hij haalt de juiste documenten op, formuleert een antwoord, klaar. In productie krijgt hij vragen in dialect, vragen met typefouten, vragen over onderwerpen die niet in de kennisbank staan, en vragen die eigenlijk twee vragen in één zijn.

Het fundamentele probleem: een agent die één keer correct presteert op een zorgvuldig samengestelde testcase zegt weinig over hoe hij zich gedraagt na veertig opeenvolgende stappen, na een storing halverwege, of wanneer een externe dienst trager reageert dan verwacht. Productiebetrouwbaarheid vraagt om testen op honderden variaties, na gesimuleerde storingen, bij randgevallen die je niet had voorzien.

De vier faalpatronen

Onderzoek naar agents in productie identificeert steeds dezelfde vier mechanismen achter het overgrote deel van de mislukkingen.

1. Herhaling zonder detectie

Een agent raakt vast in een lus. Hij voert dezelfde actie uit, krijgt telkens een resultaat dat hem niet verder brengt, en herhaalt de stap. Zonder mechanismen om stagnatie te detecteren blijft hij dit doen tot het kostenplafond bereikt is.

Voorbeeld: Een agent moet een rapport opstellen door gegevens op te halen via een externe dienst. Die dienst geeft een foutmelding terug omdat een parameter ontbreekt. De agent herkent de fout niet als definitief, stelt zijn aanvraag licht bij en probeert opnieuw. Na twintig pogingen is het budget op. Het rapport is nooit gemaakt, de gebruiker heeft geen foutmelding gezien, maar er staat wel een factuur in de mailbox.

Dit klinkt eenvoudig op te lossen: detecteer herhaalde acties en stop. Maar de herhaling is zelden identiek — de agent formuleert zijn aanvraag elke keer iets anders. Een eenvoudige check op exacte duplicaten volstaat niet. Je hebt een bewaker nodig die kijkt naar wat de agent probeert te bereiken, niet naar hoe hij het precies formuleert.

2. Redenering en actie lopen uit de pas

De agent redeneert correct over wat hij moet doen maar voert de verkeerde actie uit. Of — even gevaarlijk — hij voert de juiste actie uit op basis van foutieve redenering, en dat leidt toevallig tot het goede resultaat.

Voorbeeld: Een agent moet een samenvatting opstellen en die doorsturen naar de juiste collega op basis van het onderwerp. Hij redeneert correct dat het onderwerp “HR-beleid” is en dat dit naar de HR-manager moet. Maar hij zoekt in het verkeerde adresboek en stuurt naar de IT-manager met dezelfde achternaam. De redenering klopt, de actie niet.

Het gevaar: je ziet dit niet als je alleen het eindresultaat controleert. Een agent die het juiste antwoord geeft via de verkeerde weg, zal in een andere context het verkeerde antwoord geven via diezelfde weg. Dit kun je alleen detecteren door ook de tussenliggende redenering te beoordelen — niet alleen de einduitvoer.

3. Onduidelijke stopcriteria

Een agent stopt wanneer hij denkt dat de taak klaar is — op basis van wat het taalmodel heeft geleerd over “klaar zijn”. Dat werkt in een afgebakende demo. In productie zijn taken zelden zo scherp omlijnd.

Voorbeeld: Een agent krijgt de opdracht “stel een offerte op en stuur die door ter goedkeuring”. Hij stelt de offerte op. Dan interpreteert hij “doorsturen ter goedkeuring” als: sturen naar zijn directe contactpersoon. Die contactpersoon reageert niet (vakantie). De agent wacht. Na een time-out besluit hij dat het doorsturen mislukt is en zoekt een alternatief kanaal. Intussen is de offerte ook al via e-mail verstuurd door een ander systeem. De klant ontvangt twee offertes met verschillende bedragen.

Expliciete stopcriteria — vastgelegd door de engineer, niet afgeleid door het taalmodel — lossen dit op. De agent stopt precies wanneer jij hebt bepaald dat hij moet stoppen, en escaleert naar een mens als geen van de exitcondities bereikbaar blijkt.

4. Fouten die doorwerken in een keten

In een systeem met meerdere agents — waarbij de uitvoer van de ene de invoer van de volgende wordt — kan een fout op stap twee doorwerken tot de einduitvoer op stap tien.

Voorbeeld: Een keten verwerkt binnenkomende contracten. Agent 1 extraheert de kernclausules uit een PDF. Agent 2 controleert die clausules op juridische risico’s. Agent 3 stelt een samenvatting op voor de jurist. Agent 1 mist een clausule omdat de PDF-opmaak ongebruikelijk is. Agent 2 ziet een volledige set clausules en vindt geen risico’s — want de risicovolle clausule ontbreekt simpelweg in zijn invoer. Agent 3 stelt een schone samenvatting op. De jurist tekent.

De fout zat in stap 1, maar was onzichtbaar in de uitvoer van stap 3. Tenzij je elke tussenliggende stap registreert en valideert, zie je hem niet. Welke agent in de keten het grootste risico draagt, hangt bovendien niet af van de complexiteit van zijn taak, maar van zijn positie in de structuur: een centrale schakel die zijn uitvoer doorgeeft aan meerdere volgende agents is een kwetsbaar punt, ongeacht hoe betrouwbaar hij individueel is.

Wat dit vraagt van je aanpak

Deze vier patronen hebben één gemeenschappelijke wortel: ze zijn onzichtbaar als je alleen naar de einduitvoer kijkt.

De nodige verschuiving: van controleren of het eindresultaat klopt, naar zichtbaarheid op elk moment in het proces. Dat betekent dat je registreert wat de agent van plan is, welke externe dienst hij aanroept, wat die dienst teruggeeft, en hoe hij dat resultaat interpreteert — als een gestructureerde gegevensstroom, niet als losse foutberichten.

Een goede evaluatieset voor agents in productie verschilt van een eenvoudige test. Ze controleert niet “geeft de agent het juiste antwoord op deze invoer” maar “gedraagt de agent zich consistent over honderd variaties van deze invoer, na een gesimuleerde storing op stap drie, en bij randgevallen buiten zijn trainingscontext”. Dat vereist zowel geautomatiseerde controles als menselijke beoordeling van de gevallen die buiten de geautomatiseerde parameters vallen.

Stopcriteria zijn een ontwerpbeslissing die je expliciet vastlegt, niet iets dat je aan het taalmodel overlaat. Definieer voor elke agent: onder welke voorwaarden is de taak afgerond, wanneer escaleert hij naar een mens, en wat is de terugvaloptie als geen van die voorwaarden bereikbaar blijkt.

De positieve kant

Als je weet dat bijna alle mislukkingen terug te brengen zijn tot deze vier patronen, weet je ook wat je eerst moet bouwen: detectie van stagnatie, beoordeling van de redenering (niet alleen de uitvoer), expliciete stopcriteria, en validatie op elke tussenlaag van je keten.

Dat is niet oneindig werk. Het is gerichte ontwerpkeuzes maken vóór je uitrolt, in plaats van ze te reconstrueren vanuit productie-incidenten.

Een agent die in productie standhoudt, is geen kwestie van een beter taalmodel kiezen. Het is een kwestie van je systeem bouwen alsof de fout er al inzit — en zorgen dat je hem ziet voordat de gebruiker hem ervaart.

In de tweedaagse workshop voor developers werk je deze vier patronen hands-on uit: je bouwt een agent, test hem op randgevallen, stelt stopcriteria in en richt monitoring in. Je vertrekt met een evaluatieset en een productiechecklist voor een use case uit je eigen werkcontext.