Drie agents gebouwd. Twee staan uit. Van de derde weet niemand precies wat hij doet. En toch overweegt de directie er een vierde bij. Dit patroon zien we bijna wekelijks. Waarom het misgaat, waar het wel werkt en de vier vragen die alles bepalen.
Er is een patroon dat we bij organisaties met AI-agents steeds tegenkomen. Drie agents in productie. De eerste beoordeelt claims, maar werkt niet meer sinds er nieuwe procedures zijn ingevoerd. De tweede genereert offertes. Draait nog, maar niemand kijkt na wat eruit komt. De derde is een "assistent voor de klantenservice". Wat die precies doet weet niemand nog, want de bouwer is inmiddels weg.
En toch staat er een vierde op de planning. Voor HR deze keer. Als iemand vraagt waarom die eerste drie eigenlijk niet werken, valt het meestal stil.
Deze situatie is niet uitzonderlijk. Steeds meer organisaties beginnen aan agent nummer vijf zonder eerst nummer een af te maken. Aangejaagd door LinkedIn-content die belooft dat AI-agents "alles gaan automatiseren", zonder ook maar iets over de praktijk te zeggen.
Tijd voor een eerlijk verhaal. Wat een agent is. Waar we ze zien werken. Waarom driekwart van de pilots strandt. En de vier vragen die je moet beantwoorden voor je aan de eerste bouwt.
Elke conversatie gaat mis op dit punt. Directie hoort "AI-agents", denkt aan een chatbot en verwacht dat het over drie weken draait. Zo werkt het niet.
Een prompt is een opdracht in ChatGPT of Claude. Vraag erin, antwoord eruit. Klaar. Een workflow is een vaste reeks stappen. Elke maandag: nieuws over onderwerp X ophalen, samenvatten in drie punten, doorsturen naar het team. Voorspelbaar. Herhaalbaar. Klein.
Een agent is iets fundamenteel anders. Je geeft hem een doel. Hij bepaalt zelf welke stappen daarvoor nodig zijn. Hij kan tools inzetten, informatie opzoeken, beslissingen nemen en zijn aanpak halverwege omgooien als de situatie erom vraagt.
"Onderzoek deze klant en bereid ons gesprek voor" is een agent-opdracht. Hij bepaalt zelf of hij het CRM checkt, LinkedIn afgaat, de bedrijfssite doorleest, of alle drie. Hij besluit welke van die informatie relevant is voor jouw sector. En schrijft dan een briefing die je zo mee kunt nemen.
Die autonomie is het verschil. Het is ook precies waar het uit de hand loopt.
De agents die we in productie zien draaien hebben vier kenmerken. Meestal niet drie, meestal alle vier. Wie er een bouwt die niet aan minstens drie van deze voldoet, kan de begroting weggooien.
Denk aan klantvragen beantwoorden. Elke vraag heeft dezelfde stappen: categoriseren, informatie ophalen, antwoord voorbereiden, laten toetsen. Maar elke vraag is anders. Dat is waar agents excelleren. Voor een servicedesk waar vragen dezelfde stappen doorlopen, kan het de reactietijd halveren zonder dat de kwaliteit inzakt.
Als informatie verspreid zit over CRM, e-mailhistorie, offertes en LinkedIn, dan wordt bij elkaar brengen door mensen een zware taak. Een agent doet dat sneller. Voor accountvoorbereiding met verspreide bronnen kan een uur werk teruggaan naar tien minuten. Die 50 minuten zijn geen zwakke tijd. Ze zijn de tijd waarin verkopers vroeger de bestandenserver doorspitten.
"Betere content" is niet meetbaar. "Klopt het bedrag in de offerte" wel. Agents kun je alleen verbeteren als je duidelijk kunt vaststellen wanneer ze goed werken. Zonder succescriteria bouw je een blackbox die je alleen op gevoel kunt beoordelen. Vroeg of laat gaat gevoel niet meer stroken met de werkelijkheid.
Een concept dat langs een collega gaat: prima. Een agent die zonder tussenkomst mails verstuurt aan klanten of bedragen goedkeurt: op eigen risico. Hoe groter het effect van een fout, hoe kleiner de autonomie mag zijn. Dat klinkt basaal. In de praktijk zien we agents die gebouwd zijn zonder dat iemand deze vraag heeft gesteld.
Drie patronen. Ze zijn zo herkenbaar dat we ze inmiddels op voorhand herkennen. Als je organisatie een van deze fouten maakt, dan komt de agent er wel. Alleen niet in productie.
Iemand heeft een demo gezien. Een licentie is gekocht. Een team zit bij elkaar om "iets" te maken. Na drie weken is er een prototype dat niets doet wat niet ook met een goede prompt kan.
De ontbrekende vraag: welk proces gaan we verbeteren? Hoe ziet dat proces er nu uit? Waar zit de meeste tijd, frustratie of fouten? Zonder die basis wordt de tool een oplossing die op zoek is naar een probleem. En zo'n oplossing verliest het altijd van een sceptische collega die vraagt: "waar hebben we dit voor nodig?"
De agent draait autonoom. Iedereen is enthousiast. Tot er iets misgaat. Dan blijkt dat niemand kan traceren welke beslissing waarom is genomen. Of wie het had moeten controleren. Of wat de escalatie is als iemand een fout ziet.
Menselijke controle is geen laag die je later toevoegt. Het is ontwerp. Bij welke stap moet iemand goedkeuren? Wanneer stopt de agent uit zichzelf en escaleert hij? Wie is verantwoordelijk als de output klopt en wie als hij faalt? Bouw je een agent zonder deze antwoorden, dan bouw je een risico met een dashboard eraan.
"Geef de agent maar toegang tot alles wat op de bedrijfsschijf staat, dat is handiger." Klinkt praktisch. Tot een medewerker in het klantcontact ontdekt dat de agent netjes antwoord geeft op vragen over salarissen, omdat een oude HR-map niet goed was afgeschermd.
Toegangsrechten en gegevensbeheer horen bij het ontwerp. Welke bronnen mag de agent raadplegen? Wie ziet welke antwoorden? Wat blijft binnen een afgeschermde omgeving en wat mag naar externe modellen? Deze vragen worden meestal op vrijdag om vijf uur pas gesteld, als de agent al draait en iemand iets vreemds ziet.
Voor elke agent die we ontwerpen, staan deze vier vragen bovenaan. Als een van de antwoorden onduidelijk blijft, is bouwen te vroeg. Dat zeggen we ook. Zelfs als dat betekent dat de buildsprint pas twee weken later begint.
Niet "iets doen met AI". Wel: "de eerste reactie op supportvragen brengen we terug van 12 uur naar 30 minuten. Medewerkers zien alleen de gevallen die uit de standaard vallen." Concreet. Meetbaar. Met een nulmeting waar je later op kunt terugvallen.
Per stap in de agent: mag hij autonoom, moet iemand goedkeuren, of moet hij verplicht escaleren? Bij fouten met financiele, juridische of reputatiegevolgen: standaard iemand ertussen. Deze afweging maak je vooraf, niet op de dag dat je erachter komt dat het nodig was.
Alle systemen? Alleen goedgekeurde bronnen? Wat mag naar externe modellen? Wat blijft binnen een afgeschermde omgeving? Toegangsrechten en gegevensverkeer horen in het ontwerp thuis. Niet in de oplevering. En zeker niet op de dag dat je erachter komt dat het nodig was.
Wie beoordeelt of de agent goed presteert? Wie past hem aan als modellen veranderen? Wie draait op voor een fout in de output? Zonder eigenaar wordt de agent verwaarloosd. Dat gaat niet mis in de eerste maand. Dat gaat mis in maand vier, als de bouwer aan een ander project werkt en niemand weet welke instellingen waarom veranderd zijn.
Er is een hardnekkig misverstand dat wie de hype niet mee-schreeuwt de boot mist. Dat is niet zo. De organisaties die nu op basis van deze vier vragen bouwen, hebben over een jaar toepassingen die daadwerkelijk werk verzetten. De organisaties die nu vier pilots aan het zijn zijn zonder deze basis, hebben over een jaar iets anders: teams die niet meer geloven dat AI iets kan bijdragen.
Achterstand ontstaat niet doordat je te laat begint. Achterstand ontstaat doordat drie mislukte pilots je organisatie het vertrouwen kosten om een goede te bouwen.
In onze workshop AI-workflows en agents doorlopen we deze vier vragen voor een concreet proces uit jouw organisatie. Aan het eind ligt er een ontwerp, geen nog-een-pilot.
Bekijk de workshop →