Waarom de volgorde uitmaakt
Een werkende AI-agent bouwen kost tegenwoordig verrassend weinig code. De lus eronder — vraag het model wat het wil doen, voer dat uit, geef het resultaat terug — is een paar dozijn regels. Dat is dan ook niet waar projecten op stranden.
Ze stranden op de dingen eromheen, en bijna altijd in dezelfde volgorde: er is geen afspraak over wanneer het resultaat goed genoeg is, de gegevens blijken halverwege niet bereikbaar, of de agent doet het prima op de nette gevallen en valt om op de rest. Elk van die drie is te voorkomen, maar alleen als je ze vóór het bouwen afhandelt in plaats van erna.
Hieronder staat de volgorde die wij aanhouden. Stap 1 tot 3 kosten samen meer tijd dan het bouwen zelf, en dat is geen vertraging maar het werk. Na stap 2 en na stap 5 zit bewust een go/no-go-moment: twee punten waarop stoppen een verstandige uitkomst is.
Waar dit stappenplan op aansluit
Dit stuk gaat over de route. Wil je weten hoe een agent technisch in elkaar zit, met code voor de agent-lus, dan staat dat in AI-agent maken: van idee naar werkende agent. Twijfel je nog of je hier überhaupt aan moet beginnen en wat een pilot kost, begin dan bij AI-agents in je bedrijf: waar begin je. Zoek je voorbeelden uit je eigen sector, zie AI-agents per branche.
Het stappenplan in acht stappen
Kies één taak en schrijf op wanneer het goed is
Eén taak. Niet "onze klantenservice" maar "een binnengekomen aanvraag voorbereiden tot een concept-antwoord". De taak moet vaak terugkomen, merkbaar tijd kosten en duidelijke spelregels hebben — en iemand in de organisatie moet die spelregels kunnen uitleggen.
Schrijf daarna op wanneer het resultaat goed genoeg is, in een vorm die je kunt nakijken. Niet "de agent begrijpt de aanvraag", maar bijvoorbeeld: "bij 8 van de 10 aanvragen is het concept zonder inhoudelijke wijziging te versturen". Dat is de enige manier om achteraf niet te hoeven discussiëren over de uitkomst.
Oplevering: één A4 met de taak, de stappen die een medewerker nu doorloopt, en de norm waaraan je gaat meten. Nodig: degene die het werk nu doet.
Breng de bronnen in kaart en controleer of je erbij kunt
Loop de stappen uit stap 1 langs en noteer per stap welke informatie nodig is en waar die staat: het ERP, een mailbox, een netwerkschijf met pdf's, een CRM, een Excel die iemand bijhoudt. Dat laatste is geen grap — het staat er vaker dan je denkt, en het is maar zelden een blokkade.
Vraag vervolgens per bron technische toegang aan en controleer het met een echte aanroep. Niet met de mededeling dat het kan, maar met een rij data die daadwerkelijk binnenkomt. Dit is de stap die het vaakst wordt overgeslagen en het vaakst de planning omgooit: toegang tot een systeem regelen duurt in veel organisaties langer dan het bouwen van de agent.
Oplevering: per bron een geslaagde test-aanroep en de rechten die daarbij horen. Nodig: de beheerder of leverancier van elk systeem.
Bepaal wat de agent mag beslissen en waar een mens goedkeurt
Zet de handelingen uit de taak op een rij en zet achter elk ervan: doet de agent dit zelf, of bereidt hij het alleen voor? De lijn die wij aanhouden is simpel — alles met gevolgen naar buiten of naar een klant gaat langs een mens. Verzenden, toezeggen, vastleggen, betalen.
Spreek ook af wat de agent doet als hij het niet zeker weet. Een agent die bij twijfel een gat laat staan met een vraag erbij, is bruikbaar. Een agent die bij twijfel iets plausibels invult, is gevaarlijk, omdat je aan het resultaat niet ziet welke velden je nog moet nakijken.
Oplevering: een tabel van handelingen met per regel "zelf" of "voorbereiden", en de afspraak over wat er bij twijfel gebeurt. Nodig: degene die verantwoordelijk is voor het proces.
Bouw de kleinste versie die de taak echt doet
Nu pas bouwen. De agent krijgt alleen de tools die deze taak nodig heeft: één bron ophalen, één document uitlezen, één concept opleveren. Geen framework zolang de kern niet staat — die abstractielaag maakt het vooral moeilijker te zien waar iets misgaat. En geen tweede taak erbij, hoe klein die ook lijkt.
Bouw meteen op echte gegevens, niet op verzonnen voorbeelden. Verzonnen invoer is netter dan de werkelijkheid, en juist die rommeligheid is wat je moet zien terwijl je bouwt.
Oplevering: een agent die de taak van begin tot eind doorloopt op echte data. Nodig: degene die bouwt, met iemand uit stap 1 om mee te kijken.
Test op echte gevallen uit het verleden
Pak twintig tot vijftig gevallen die in het verleden zijn afgehandeld en laat de agent ze alle doorlopen. Vergelijk zijn uitkomst met wat er destijds daadwerkelijk is besloten. Dit kost een dag en het is de meest informatieve dag van het hele traject.
Neem bewust de rommelige gevallen mee: de aanvraag met de ontbrekende bijlage, de factuur van die ene leverancier met de afwijkende opmaak, het geval waarin iemand telefonisch iets anders had afgesproken. Een agent die alleen op nette gevallen is getest, valt in productie precies om op de rest — en dat is vaak een derde van het werk.
Oplevering: een overzicht van de gevallen met per geval goed, fout of terecht overgeslagen, afgezet tegen de norm uit stap 1. Nodig: iemand die kan beoordelen of een uitkomst klopt.
Zet grenzen en bewaking erop
Voordat er iets live gaat: een harde bovengrens op het aantal modelaanroepen per taak, een maandbudget met een melding, en een logboek waarin elke stap van de agent wordt vastgelegd — welke bron hij heeft aangeroepen, wat hij terugkreeg, welke keuze hij maakte.
Dat logboek is niet voor de boekhouding maar voor jezelf. Zonder is "de agent gaf een vreemd antwoord" een onoplosbare melding. Mét kun je achteraf teruglopen en zien of het de bron was, de instructie, of het model.
Oplevering: limieten ingesteld, budgetmelding actief, elke uitkomst herleidbaar. Nodig: degene die bouwt.
Laat de agent eerst meelopen naast de mens
Zet de agent een aantal weken in het echte werkproces, maar gebruik zijn uitkomst nog niet. Hij doet de taak, een medewerker doet de taak, en je vergelijkt. Dat levert iets op wat de test uit stap 5 niet kan geven: hoe de agent zich houdt op invoer die niemand had voorzien, in het tempo van een gewone werkdag.
Deze periode is ook waar het vertrouwen vandaan komt. Een team dat een paar weken heeft gezien dat de voorstellen kloppen, gaat er anders mee om dan een team dat op een maandagmorgen hoort dat het nu via de agent gaat.
Oplevering: een vergelijking over een paar weken echte invoer, en een besluit om live te gaan of eerst bij te stellen. Nodig: het team dat het werk doet.
Neem in productie, meet, en breid pas daarna uit
Nu mag de uitkomst van de agent het werk in, met de controlemomenten uit stap 3 op hun plek. Meet vanaf dag één drie dingen: doorlooptijd van de taak, hoe vaak een mens inhoudelijk moet bijsturen, en de kosten per uitgevoerde taak.
Pas als die cijfers een paar weken kloppen met wat je in stap 1 had opgeschreven, is het tijd voor de tweede taak. Uitbreiden vóór dat moment is de meest voorkomende manier om een werkende agent weer stuk te maken: je verdubbelt de oppervlakte terwijl je nog niet weet of de eerste helft klopt.
Oplevering: de agent in productie, met cijfers die je kunt vergelijken met de norm. Nodig: iemand die mag besluiten dat het zo blijft.
De twee momenten waarop stoppen beter is
Een stappenplan dat alleen vooruit gaat, is geen plan maar een hoop. Er zitten twee punten in waarop de eerlijke uitkomst "niet nu" kan zijn.
Na stap 2. Blijken de gegevens die deze taak nodig heeft niet bereikbaar, of staan ze er in zo'n vorm dat niemand kan zeggen welke versie de juiste is, dan heeft doorbouwen geen zin. Je bouwt dan een agent die gaat raden. Dit is geen afgebroken project: je weet nu precies welk stuk data eerst aandacht nodig heeft, en dat is gewoon data-engineeringwerk dat vaak op zichzelf al waarde oplevert — ook zonder AI erbovenop.
Na stap 5. Zit de agent er structureel naast op het normale werk, niet alleen op de uitzonderingen, dan is er iets mis met de taak en niet met de agent. Meestal blijkt dan dat de spelregels uit stap 1 in werkelijkheid minder vast zijn dan ze op papier leken, en dat ervaren medewerkers onbewust veel meer afwegen dan ze hadden opgeschreven. Ook dat is waardevolle informatie, maar het betekent dat deze taak zich niet leent voor automatisering in deze vorm.
Wat dit stappenplan niet belooft
Je ziet hier geen besparingspercentages of klantcases, en dat is een bewuste keuze. Wat een agent in jouw situatie oplevert, hangt af van de taak, de staat van de gegevens en hoeveel mensenwerk eromheen blijft bestaan. De cijfers die je nodig hebt, komen uit stap 8 — uit je eigen proces, niet uit een brochure.
Wat het kost aan tijd en mensen
De doorlooptijd hieronder is een realistische orde van grootte voor één afgebakende taak, niet een belofte. Wat hem vooral oprekt, is stap 2: wachten op toegang tot systemen.
| Stap | Orde van grootte | Wie je daarvoor nodig hebt |
|---|---|---|
| 1. Taak kiezen en norm afspreken | Enkele dagen | Degene die het werk nu doet |
| 2. Bronnen in kaart en toegang | 1–4 weken, sterk wisselend | Systeembeheer of leverancier |
| 3. Bevoegdheden en controlemomenten | Enkele dagen | Proceseigenaar |
| 4. Kleinste werkende versie bouwen | 1–2 weken | Bouwer, met meekijker uit het team |
| 5. Testen op historische gevallen | 1–3 dagen | Iemand die uitkomsten kan beoordelen |
| 6. Grenzen en bewaking | Enkele dagen | Bouwer |
| 7. Meelopen naast de mens | 2–4 weken | Het team dat het werk doet |
| 8. Productie en meten | Doorlopend | Iemand met beslisbevoegdheid |
Opvallend: van de acht stappen zijn er maar drie technisch. De rest is afspreken, nakijken en besluiten. Dat is ook waarom een agent zelden mislukt op het model en vaak op de organisatie eromheen.
Dit stappenplan voor jouw eerste taak doorlopen?
Onder de naam AIpartner365 bouwen we AI-agents en procesautomatisering die aansluiten op de processen, systemen en data die er al zijn. We beginnen bij stap 1 — samen één taak kiezen en afspreken wanneer het goed is — en zeggen het ook als AI voor dit werk niet de beste route is.
Vijf manieren om dit mis te laten gaan
Deze vijf komen we het vaakst tegen, en ze zijn alle vijf een afwijking van de volgorde hierboven.
- Beginnen bij het model. Weken vergelijken welk model het beste is, terwijl de taak nog niet is afgebakend. De modelkeuze is zelden wat het verschil maakt; de koppelingen naar je eigen systemen zijn dat.
- De norm pas achteraf bepalen. Zonder afspraak uit stap 1 wordt de oplevering een smaakdiscussie, en die verlies je altijd — want er is altijd één geval te vinden waarin de agent het fout deed.
- Testen op nette voorbeelden. Een demo op drie zorgvuldig gekozen gevallen zegt niets. De uitzonderingen zijn niet de uitzondering: ze zijn vaak een derde van het werk.
- De agent laten beslissen omdat hij het toch bijna altijd goed heeft. "Bijna altijd" is precies het probleem bij handelingen met gevolgen naar buiten. Het controlemoment uit stap 3 mag per stap verschuiven, maar verdwijnt niet.
- Uitbreiden voor stap 8 af is. Een tweede taak erbij terwijl de eerste nog niet gemeten is, verdubbelt waar je naar moet kijken op het moment dat je nog niets zeker weet.
Conclusie
Een AI-agent bouwen is voor het grootste deel geen technisch project. De lus is een paar dozijn regels code; het werk zit in één taak scherp krijgen, bij betrouwbare gegevens kunnen, afspreken wat de agent mag beslissen, en testen op het werk zoals het echt binnenkomt.
Houd daarom de volgorde aan, ook als het verleidelijk is om meteen te gaan bouwen. En behandel de twee go/no-go-momenten als echte momenten: na stap 2 en na stap 5 kan "niet nu" de juiste uitkomst zijn, en dan heb je nog altijd iets geleerd dat de volgende poging goedkoper maakt.
Wil je de techniek onder de motorkap zien, inclusief code voor de agent-lus? Dat staat in AI-agent maken: van idee naar werkende agent. Twijfel je nog over de businesskant — wat een pilot kost en hoe je de eerste taak kiest — begin dan bij AI-agents in je bedrijf: waar begin je. En voor voorbeelden per sector: AI-agents per branche.
Veelgestelde vragen
Hoe lang duurt het bouwen van een AI-agent?
Voor één afgebakende taak is zes tot tien weken een realistische doorlooptijd, waarvan het bouwen zelf het kortste deel is. Het meeste tijd gaat naar toegang tot de bronnen regelen, afspreken wat de agent wel en niet mag, en testen op echte gevallen. Een agent die in twee dagen werkt in een demo is meestal een agent die nog geen van die drie heeft gehad.
Wat is de eerste stap bij het bouwen van een AI-agent?
Eén taak kiezen en opschrijven wanneer het resultaat goed genoeg is. Niet de techniek, niet het model, niet het framework. Zonder die afspraak op papier blijft het achteraf een kwestie van mening of de agent werkt, en dat is precies waar pilots op stranden.
Wanneer moet je stoppen met een AI-agent-project?
Als je na stap 2 merkt dat de benodigde gegevens niet bereikbaar of niet eenduidig zijn, of als na de test op historische gevallen blijkt dat de agent er structureel naast zit op het normale werk in plaats van alleen op de uitzonderingen. Stoppen is dan geen verlies: je weet nu welk stuk data eerst aandacht nodig heeft, en dat is vaak op zichzelf al waardevol werk.
Heb je een eigen dataplatform nodig voordat je een AI-agent bouwt?
Nee, niet voor een eerste toepassing. Wat je nodig hebt is dat de bronnen die déze ene taak gebruikt bereikbaar en betrouwbaar zijn. Vaak blijkt tijdens het bouwen juist welk stuk data aandacht verdient; dan is dat een concreet vervolg in plaats van een aanname vooraf.
Hoeveel testgevallen heb je nodig om een AI-agent te beoordelen?
Twintig tot vijftig afgehandelde gevallen uit het verleden is genoeg om te zien of de richting goed is. Belangrijker dan het aantal is de samenstelling: neem bewust de rommelige gevallen mee, want een agent die alleen op de nette gevallen is getest, valt in productie om op precies de rest.
Wie heb je nodig in een team dat een AI-agent bouwt?
Drie rollen, waarvan er maar één technisch is: iemand die het werk nu doet en kan uitleggen hoe het hoort, iemand die de bouw doet en de koppelingen legt, en iemand die mag besluiten dat de agent live gaat. Ontbreekt de eerste, dan bouw je op aannames; ontbreekt de laatste, dan blijft het een pilot die nooit afkomt.
Wat kost het draaien van een AI-agent per maand?
De kosten zitten in tokens: je betaalt per verwerkte tekst, wat doorgaans uitkomt op enkele centen per uitgevoerde taak. Wat de rekening laat oplopen is niet de prijs per aanroep maar het aantal: een agent die in een lus blijft hangen of telkens de volledige context meestuurt. Daarom horen een harde bovengrens op het aantal aanroepen en een maandbudget bij het bouwen, niet bij het opruimen achteraf.