Een AI-agent bouwen is het eenvoudige deel

In bijna elk agentproject valt de ruimte op een gegeven moment op een goede manier stil. De agent leest het document, roept het systeem aan, schrijft het record en iedereen ziet dat het werkt.

Dat moment is waardevol. Tegelijk is het de minst representatieve run die de agent ooit zal uitvoeren. Een demo is één zorgvuldig gekozen case, terwijl iemand meekijkt. Productie is elke case die binnenkomt, ook de lastige, lang nadat de ruimte leeg is.

Een agent bouwen is eenvoudiger geworden doordat de tooling is verbeterd. De moeilijkheid is verschoven, niet verdwenen.

01Waarom slaagt een pilot en loopt een programma vast?

Gartner verwacht dat meer dan 40 procent van de agentic-AI-projecten eind 2027 is stopgezet. De belangrijkste redenen zijn oplopende kosten, onduidelijke bedrijfswaarde en gebrekkige risicocontroles. Capaciteit en de aansluiting op de use case blijven relevant. Maar capaciteit alleen brengt een werkende agent niet naar productie.

Het DORA-onderzoek uit 2025 kwam voor softwaredelivery tot een vergelijkbare conclusie: AI versterkt het systeem eromheen. Sterke workflows, platforms en feedbackloops vergroten het effect. Zwakke worden zichtbaarder.

Een pilot beantwoordt één vraag: kan de agent dit één keer? Productie stelt vier andere. Houdt het werk volgende maand nog stand? Wat kost het bij de echte casemix? Wie is verantwoordelijk als het fout gaat? Kun je reconstrueren wat de agent deed en waarom?

In ons artikel over wat een agent werkelijk is maakten we hetzelfde punt over zijn anatomie: het model is één onderdeel; de lagen eromheen maken het werk bruikbaar. Dit artikel gaat over de volgende laag. Niet waaruit een agent bestaat, maar wat nodig is om AI-agents in productie te runnen.

02Wat gaat er mis na de demo?

Na de lancering komen meestal drie dingen naar boven: werk dat eerst wordt geaccepteerd en later wordt teruggedraaid, kosten die veranderen door de manier waarop de agent wordt gerund en processen met weinig volume waarvan de maandelijkse economie moeilijk te voorspellen is.

Het werk wordt ongemerkt teruggedraaid

De meeste systemen kunnen acceptatie op de dag zelf meten: kwam de output door de controle, keurde iemand hem goed en is het record geschreven? Of dat werk een maand later nog overeind staat, weet je pas later. Het venster waarin iets kan misgaan is langer dan het meetvenster.

Een creditnota wordt aangemaakt en twee weken later teruggedraaid. Een leveranciersrecord wordt bijgewerkt en daarna gecorrigeerd door de eigenaar. Op het dashboard lijken beide runs op de dag zelf geslaagd. In werkelijkheid veroorzaakten ze allebei herstelwerk.

Als de correctie de operationele loop niet bereikt, leert de agent er niets van. Erger nog: het team kan instructies en evals blijven aanpassen op basis van wat op de dag zelf werd geaccepteerd, in plaats van wat later standhield. Het systeem rond de agent optimaliseert dan voor het verkeerde signaal.

Softwaredelivery geeft een goed gemeten voorbeeld van dat risico, omdat wijzigingen en terugdraaiingen worden gelogd. Bill Harding, CEO van codeanalysebedrijf GitClear, beschreef de prikkel helder.

AI schrijft bij voorkeur code die niet als defect wordt aangemerkt. Bill Harding, GitClear · LeadDev, July 2026

Uit het onderzoek van GitClear uit 2026 naar 623 miljoen codewijzigingen bleek dat werk dat binnen twee weken werd herzien met 15 procent toenam. Constructies die fouten maskeren namen tussen 2023 en 2026 met 47 procent toe. Dat is bewijs over software, geen bewijs dat elke zakelijke agent zich hetzelfde gedraagt. Het laat wel zien waarom directe acceptatie geen vervanging is voor blijvende kwaliteit.

Context verandert de kostencurve

In een loop die bij elke stap een groeiende historie opnieuw meestuurt, kunnen de inputkosten sneller stijgen dan het aantal stappen. Instructies, voorbeelden, opgehaalde documenten en toolbeschrijvingen strijden allemaal om dezelfde context. Uitzonderingen voegen vaak meer materiaal toe. Die toevoegingen stapelen zich op als niemand ze verwijdert of herstructureert.

Louis-François Bouchard mat dit bij een tutoring agent in productie. Zijn diagnose is het onthouden waard.

Het model werd niet dommer. Zijn context wel. Louis-François Bouchard · Context engineering in 2026, August 2026

Zijn resultaten laten ook zien dat dit geen onvermijdelijke ontwikkeling in één richting is. In zijn workload verlaagde een limiet op tooloutput de kosten per beurt met 38 procent, zonder meetbaar geheugenverlies. Prompt caching, retrieval, outputlimieten, bewust snoeien en modelrouting kunnen de curve allemaal veranderen.

De pilotkosten zijn dus niet per definitie het laagste bedrag dat de agent ooit zal halen. Het is simpelweg geen productieprognose. De productie-economie moet per case worden gemeten, tegen de werkelijke spreiding van het werk.

Bij weinig volume is het gemiddelde minder stabiel

De kosten per case zijn vaak rechts-scheef verdeeld. De meeste cases zijn gewoon; een klein aantal duurt lang. Bij weinig volume kunnen die uitschieters het maandelijkse gemiddelde sterk beïnvloeden. Bij veel volume is het gemiddelde doorgaans stabieler, ook als de totale rekening hoger is.

Dat verschil telt. Een financeproces met duizenden vergelijkbare cases kan in totaal duur zijn, maar per case voorspelbaar. Een analistenproces met vijf diepgaande onderzoeken kan goedkoper zijn en toch elke maand verrassen.

In ons eigen werk vonden we dit patroon in kostenmodellen, niet in een universele productiebenchmark. Het veranderde welke processen we economisch onzeker noemen en welk bewijs we vragen voordat we ze goedkeuren.

03Wat spreken we af vóór de bouw?

Een proces heeft een businesscase nodig voordat de agents een architectuur nodig hebben. Zonder businesscase ontbreekt een stabiele uitkomst, nulmeting en beslisregel waaraan je het systeem kunt houden.

Het onderscheid tussen proces en agent is belangrijk. Een organisatie draagt een procesuitkomst over. Eén agent kan die dragen, of meerdere kleinere agents kunnen eronder samenwerken. Dat is een architectuurkeuze die tijdens de bouw kan veranderen. De businesscase en commerciële eenheid blijven het proces. Het splitsen of combineren van agents verandert dus niet stilletjes wat de klant heeft gekocht.

Voor elk proces dat we in productie brengen, past de businesscase op één pagina. Die legt zes zaken vast: het werk, kwaliteit en risico, de nulmeting, investering en waarde, het prestatiedoel en de benoemde eigenaar.

Twee details bepalen of de rest bruikbaar is.

De nulmeting krijgt een label. Waar de historie van de organisatie voldoende basis biedt, wordt de nulmeting berekend en als gemeten gemarkeerd. Anders wordt ze gemodelleerd op basis van een vergelijkbaar proces, een externe benchmark of een expliciete aanname, met het label gemodelleerd. Een gemodelleerde nulmeting kun je ter discussie stellen en vervangen. Een verborgen aanname niet.

Capaciteit wordt niet als waarde gepresenteerd. De businesscase maakt onderscheid tussen tijd die als capaciteit vrijkomt en gerealiseerde waarde. Vrijgekomen tijd wordt pas waarde wanneer een benoemde eigenaar die omzet in meer output, betere dienstverlening, lagere externe uitgaven of een concrete personeelsbeslissing. Tot dat moment is het beschikbare capaciteit, geen besparing.

De businesscase moet negatief mogen uitvallen. Anders is het een rechtvaardigingsdocument in plaats van een beslisinstrument.

04Hoe ziet een AI-agent in productie eruit?

We gebruiken een methode met vier fasen. De opbouw telt meer dan de namen.

Scan stelt de gewenste uitkomst en de huidige nulmeting vast, en bepaalt of het werk geschikt is. Onboard definieert de agentrollen, systeemtoegang, grenzen en verantwoordelijke eigenaar. Earn trust test de agents op echte cases voordat ze zelfstandig handelen. Grow meet het proces zolang het draait aan de businesscase.

De pijl terug is belangrijk. Bronsystemen krijgen updates. Regels veranderen. Modellen worden vervangen. Een configuratie die een jaar niet is beoordeeld, is niet bewezen stabiel alleen omdat ze nog draait.

In de dagelijkse operatie staan vier signalen naast elkaar: benutting, blijvende kwaliteit, effect op de procescapaciteit en kosten per case. Ze voeden de drie maatstaven uit de businesscase waarmee de rol wordt beoordeeld: kwaliteit, capaciteit en waarde.

De kwaliteitsmeting moet langer duren dan het faalvenster. First-time-right op de dag zelf is een vroeg signaal. First-time-right na de afgesproken periode is het blijvende resultaat. Het verschil bestaat uit werk dat iemand opnieuw opende, corrigeerde of terugdraaide.

Dat cijfer is de meting, niet de oplossing. De oplossing is elke correctie opvangen en terugbrengen in de operationele loop: wat deed de agent, wat veranderde een mens en waarom? Een terugkerende correctie wordt een kandidaat-regel. Die komt pas in de vaste context van de agent nadat hij de tests en evals van die agent doorstaat.

De loop is het antwoord, niet het dashboard. Sluit je de loop, dan baseer je toekomstige wijzigingen op de uitkomst die werkelijk standhield. Laat je hem open, dan kan de kwaliteitsscore verbeteren terwijl de organisatie het werk blijft terugdraaien.

Binnen Aitonomy runnen we code review, QA, security checks, documentatie, infrastructuurcontroles en interne rapportage als agents op verschillende autonomieniveaus. Daar werden verschillende faalpatronen uit dit artikel voor ons voor het eerst zichtbaar.

05Wat hebben we veranderd?

We veranderden twee onderdelen van onze eigen methode.

We gebruiken het aantal agents niet langer als eenheid. We hadden al geconcludeerd dat de inspanning afhangt van de complexiteit van het proces, niet van het aantal agents. Die conclusie hadden we nog niet doorgevoerd in de manier waarop we het werk beschreven en prijsden. Een lezer van ons eigen document wees ons op de inconsistentie.

Het proces is nu de bedrijfsmatige en commerciële eenheid. De agents daaronder blijven architectuurrollen. Hun aantal kan veranderen zonder dat de beloofde uitkomst of de prijs stilletjes verandert.

We veranderden onze omgang met kostenrisico bij weinig volume. Eerst namen we aan dat processen met veel volume het moeilijkst te voorspellen waren, omdat daar de totale uitgaven het hoogst zijn. Onze modellering liet zien dat de gemiddelde maandelijkse kosten per case bij weinig volume minder stabiel zijn. Een paar lange cases kunnen het resultaat dan sterk verschuiven.

We ontdekten dat tijdens de modellering, voordat het een live businesscase raakte. Het waardevolle was niet dat we de fout voorkwamen, maar dat een meetwaarde ons dwong de methode te veranderen.

06Hoe houden we grip op een agent?

Dit is het werk dat Aitonomy voortzet nadat een agent live gaat. Aitonomy Control legt het bewijs uit de operatie vast. Ons operationele team runt de control loop en gebruikt dat bewijs om afwijkingen te onderzoeken en de inzet van de agent aan te passen. De proceseigenaar bij de klant blijft verantwoordelijk voor de uitkomst en bekrachtigt elke maand het besluit om de scope te verruimen, gelijk te houden, te verkleinen of de agent te stoppen.

Grip begint vóór de bouw. We spreken af wat wordt gemeten, stellen de nulmeting vast, definiëren de grenzen van de agent en bepalen welk bewijs nodig is voordat hij met meer autonomie mag handelen.

De faalpatronen in dit artikel delen die eis. Directe acceptatie vervangt geen blijvende kwaliteit. Pilotkosten vervangen geen productiekosten per case. Een theoretische capaciteitsschatting vervangt geen gerealiseerde waarde. En een autonomieniveau mag niet alleen omhoog kunnen.

Aitonomy Control houdt dat bewijs vervolgens bij elkaar: wat elke agent deed, wat een mens goedkeurde, of het werk standhield en hoe kwaliteit, capaciteit, waarde en kosten zich verhouden tot de afgesproken nulmeting.

Dat bewijs moet beslissingen veranderen. We kunnen de context aanpassen, overstappen op een lichter model als dat dezelfde norm haalt, de autonomie verkleinen of verruimen, of de rol stoppen. Veranderen het beoogde doel, de scope of het gebruik van een agent, dan moeten ook de relevante classificatie, documentatie, menselijke controls en verantwoordelijkheden opnieuw worden beoordeeld. De formele juridische beoordeling blijft losstaan van het technische bewijs dat Aitonomy Control levert. Dit is ook het operationele uitgangspunt achter laten zien wat elke agent deed en wie het goedkeurde.

Agents kunnen veel monitoringwerk voorbereiden: scoreboards lezen, afwijkingen markeren en relevante runs verzamelen. Ons operationele team beoordeelt dat materiaal en brengt het bewijs naar de proceseigenaar. Het besluit zelf blijft mensenwerk.

Er is een eenvoudige toets voor echte governance. Vraag wanneer een agent voor het laatst een autonomieniveau omlaag ging. Vraag wanneer een maandbesluit voor het laatst een agent stopzette. Vraag wat er vorige maand veranderde door het scoreboard.

Als het antwoord op alle drie “nooit” is, rapporteert het systeem alleen. Het stuurt niet. Een control die nooit een beslissing verandert, is slechts een dashboard.

Een agent het werk één keer laten doen wordt steeds eenvoudiger. Goed runnen begint daarna: een nulmeting vóór de bouw, een benoemde eigenaar, bewijs dat autonomie kan verlagen én verhogen en een maandelijks besluit dat de agent ook mag stoppen.

Veelgestelde vragen