---
title: "AI-agents maken: het stappenplan (en wanneer uitbesteden)"
description: "Een AI-agent maken doe je in vijf stappen: van doel tot livegang. Ontdek wat er echt bij komt kijken, en wanneer je het beter kunt uitbesteden aan een bureau."
canonical: "https://www.whatsnext-ai.com/nl/blog/building-an-ai-agent"
published: "2026-09-02T00:00:00.000Z"
updated: "2026-09-02T13:50:23.750Z"
---

# AI-agents maken: het stappenplan (en wanneer uitbesteden)

Een AI-agent maken doe je in vijf stappen: van doel tot livegang. Ontdek wat er echt bij komt kijken, en wanneer je het beter kunt uitbesteden aan een bureau.

![Building an AI agent: a five-step flow from goal to launch](https://fgzcpjbyiakhjifaciaj.supabase.co/storage/v1/object/public/media/pexels-dkomov-34804017.jpg)

Een AI-agent maken doe je in vijf stappen: doel bepalen, data en koppelingen in kaart brengen, kiezen tussen no-code en code, testen met duidelijke grenzen, en livezetten met onderhoud. Zodra betrouwbaarheid telt, is uitbesteden vaak sneller dan zelf verder bouwen.

### De vijf stappen op papier, en de realiteit erachter

Vraag Google hoe je een [AI-agent](https://www.whatsnext-ai.com/glossary/ai-agent) maakt en het antwoord klinkt als een wizard, vijf stappen die je op een middag zou moeten doorlopen:

- Stap 1: Doel bepalen
- Stap 2: Platform kiezen
- Stap 3: Instructies en kennis toevoegen
- Stap 4: Koppelen
- Stap 5: Testen en live zetten

Die vijf stappen kloppen ook, tot op zekere hoogte. Het probleem is niet de volgorde, maar wat er in elke stap echt gebeurt zodra het geen speeltuin meer is.

Kijk op r/AI_Agents, waar bouwers hun eigen ervaring delen, en het beeld kantelt. Drie weken aan tutorials, framework-keuzes die niemand durft te maken, en nog steeds geen werkende agent. "De demo loog tegen me" is een terugkerende zin. Het gat tussen die twee werelden, de vlotte handleiding en de vastgelopen praktijk, is precies waar dit artikel over gaat.

We lopen de vijf stappen af zoals ze in een echt project verlopen. Bij elke stap staat het moment waarop "doe het zelf" begint te wringen, zodat je zelf kunt bepalen tot waar je komt en waar het slimmer wordt om hulp te halen. Wil je eerst weten wat een AI-agent precies is voordat je gaat bouwen, lees dan [wat is een AI-agent](https://www.whatsnext-ai.com/blog/what-is-an-ai-agent) als basis.

### Stap 1. Scope: één proces, niet "een AI-agent"

Begin bij één afgebakend proces, niet bij "een AI-agent voor het bedrijf". Dat laatste is geen opdracht, het is een categorie, en het is meteen de eerste fout, nog voor de eerste regel code.

Een agent wordt bruikbaar op het moment dat de agent op één afgebakend proces staat. Niet klantenservice, maar "beantwoord productvragen over onze catalogus". Niet de administratie, maar "haal de bedragen uit binnenkomende facturen en zet ze klaar voor controle". Hoe smaller de opdracht, hoe eerder je iets hebt dat werkt en hoe makkelijker je kunt controleren of het klopt.

Bij [Borgh](https://www.whatsnext-ai.com/cases/borgh-answers-every-product-question-in-seconds-across-15000-skus), de bevestigings- en gereedschapsspecialist met een assortiment van ruim 15.000 Milwaukee- en Makita-artikelen, was de scope glashelder: elke productvraag correct beantwoorden, in seconden, zonder een verkeerd artikelnummer te verzinnen. Die ene zin bepaalde de hele bouw. Alles wat niet bijdroeg aan "correct antwoord over de juiste SKU" viel buiten de eerste versie.

Waar DIY nog prima werkt: het scopen zelf. Dit is denkwerk, geen techniek. Als je je eigen proces goed kent, doe je dit beter dan welk bureau ook. Schrijf op wat de agent moet kunnen, wat "goed" betekent, en wat er misgaat als de agent het fout doet.

### Stap 2. Data en koppelingen: waar de meeste projecten vastlopen

Breng eerst je data en koppelingen in kaart, want daar ligt het echte werk en daar stopt het bij de meeste zelfbouwprojecten. Een agent is zo goed als de data waar de agent bij kan en de systemen waarmee de agent praat.

De vragen die je moet beantwoorden zijn zelden spannend, maar wel bepalend. Staat je productinformatie op één plek of verspreid over een webshop, een ERP en een spreadsheet? Zijn de velden consistent gevuld? Wat is de bron van waarheid als twee systemen elkaar tegenspreken? En kan de agent überhaupt bij die systemen, met de juiste rechten, zonder dat je een beveiligingsgat opent?

Deze inventarisatie is geen bureaucratie, het is de basis onder de betrouwbaarheid. Een agent die "meestal" de juiste bron raadpleegt, is in productie niet bruikbaar. De agent moet weten welk systeem leidend is, welke velden je kunt vertrouwen en wat er moet gebeuren als een veld leeg of tegenstrijdig is. Dat vastleggen kost tijd, maar het is precies wat een demo overslaat en een productiesysteem niet mag overslaan.

Bij Borgh begon het niet met een model, maar met een eerlijke inventarisatie van de data. Welke velden waren betrouwbaar, welke niet, en wat betekende "correct" als de brondata zelf rommelig was. Milwaukee en Makita structureren hun productdata bovendien op onverenigbare manieren, dus "de catalogus" was in de praktijk twee catalogi die niet op elkaar aansloten. Pas toen dat helder was, had bouwen zin.

Waar DIY begint te breken: de koppelingen. Een demo op je eigen laptop met een nette voorbeeldset is één ding. Een agent die live data uit je ERP haalt, met wisselende kwaliteit en echte uitzonderingen, is een ander vak. Dit is het punt waarop veel teams drie weken verliezen aan integraties die "bijna" werken.

### Stap 3. Platform kiezen: no-code of code

Nu pas komt de vraag waar iedereen mee begint: welk platform. En het eerlijke antwoord is dat het ervan afhangt hoe ver je wilt komen.

In een no-code bouwer voeg je de instructies en de kennis met de hand toe, precies de "instructies toevoegen"-stap uit de handleiding. Let daarbij op één onderscheid dat vaak door elkaar loopt: een Copilot ondersteunt een mens die de knopen doorhakt, terwijl een agent een afgebakende taak zelfstandig afhandelt binnen grenzen die je vooraf vastlegt. Voor een prototype is dat handmatig instrueren prima. Het wringt zodra die instructies betrouwbaar en herhaalbaar moeten zijn.

No-code bouwers als Copilot Studio, n8n of Make zijn uitstekend voor een prototype. Je zet snel iets in elkaar, je laat het aan collega's zien, je test of het idee hout snijdt. Voor een intern hulpje met een handjevol gebruikers houdt dat prima stand. Wil je zien hoe die tools zich onderling verhouden, dan hebben we [n8n vs Make vs Zapier](https://www.whatsnext-ai.com/blog/n8n-vs-make-vs-zapier) apart uitgewerkt.

Het kantelpunt is geen mening over "echte" software, maar een set concrete symptomen. Je flow laat stilletjes een randgeval vallen en niemand merkt het tot een klant belt. Een bug is niet te reproduceren, omdat je niet kunt zien welke stap wat deed. Een kleine wijziging breekt iets anders, en je ontdekt het pas in productie, omdat er geen manier is om vooraf te testen. Zodra een agent honderden of duizenden keren per dag draait, klantcontact raakt of aan je kernsystemen hangt, tellen die symptomen op tot een echt risico.

Dat is het punt om over te stappen op een gecodeerde agent, waarin de logica en de grenzen vastliggen, die je los kunt testen en waarvan de code van jou is. What's Next bouwt productie-agents in code, juist omdat klanten er jaren op moeten kunnen leunen en er zelf eigenaar van willen zijn. Waar no-code oprecht standhoudt, voor een prototype of een klein intern proces, is het vaak de snelste route. Voor de definitie en de code-versus-low-code afweging in het kort, zie [wat is een AI-agent](https://www.whatsnext-ai.com/blog/what-is-an-ai-agent).

Waar DIY het langst meekomt: het prototype en het kleine interne proces. Zolang een handjevol collega's de agent gebruikt en een fout hooguit een schouderophalen oplevert, is er geen reden om code te schrijven. De rekening komt pas als je diezelfde no-code flow probeert op te schalen naar iets waar klanten of kernsystemen aan hangen.

### Stap 4. Testen en grenzen: wanneer handelt de agent zelf, wanneer escaleert hij naar een mens

Een agent die alleen praat is een chatbot. Een agent die iets doet, moet weten wat de agent zelfstandig mag en wanneer de agent een mens erbij haalt. Dat verschil bepaal je hier.

De grenzen horen in de architectuur, niet in een losse instructie die je erbij typt. Wat mag de agent zelf afhandelen, welke acties vereisen bevestiging, en wat gebeurt er bij twijfel? Bij Borgh was de belangrijkste regel niet "geef een antwoord", maar "verzin nooit een artikelnummer". Liever geen antwoord dan een verkeerd antwoord. Die grens zat ingebouwd, niet als bijzin in een prompt.

Testen betekent hier niet alleen "werkt het", maar "wat doet de agent als het misgaat". Voer de rare gevallen in, de half ingevulde vragen, de tegenstrijdige data. Een agent die 95 procent van de tijd goed werkt maar in de resterende 5 procent zelfverzekerd onzin verkoopt, is in productie gevaarlijker dan geen agent.

Waar DIY meestal tekortschiet: het bewust stukmaken. Zelfbouwers testen of hun agent werkt; ze testen zelden systematisch waar de agent breekt. Dat verschil is het verschil tussen een demo en een systeem waar je op durft te leunen.

### Stap 5. Livegang en onderhoud: het stopt niet bij de lancering

Reken na de livegang op een periode van meekijken en bijsturen, want de lancering is niet de finish maar de start van de fase die telt. Data verandert, processen schuiven, en gebruikers stellen vragen die je vooraf niet had bedacht.

Kijk in die periode wat de agent goed afhandelde, waar de agent terecht escaleerde, en waar de agent tegen iets aanliep dat je moet oplossen. Bij Borgh duurde het van eerste onderzoek tot een agent die betrouwbaar in productie draaide ongeveer drie maanden. Het resultaat: rond de 0,005 euro per gesprek, ongeveer 1.000 keer goedkoper dan dezelfde vraag door een specialist laten uitzoeken, en geen enkel verzonnen artikelnummer.

Die drie maanden zijn geen vertraging, het is het verschil tussen iets dat demonstreert en iets dat draait. Wie die fase overslaat, levert een agent op die er in de demo goed uitziet en in de praktijk vertrouwen kost.

Waar DIY tekortschiet: het volhouden. Een agent bouwen is een project, een agent onderhouden is een gewoonte. Een gecodeerde agent laat zich versioneren en testen bij elke wijziging, zodat je ziet wat er breekt voordat een klant dat doet. Een dichtgetimmerde no-code flow moet je bij elke verandering met de hand opnieuw natrekken.

### Wanneer schakel je een bureau in

Je hoeft niet alles uit te besteden, en niet alles hoeft in code. De vraag is per stap waar jouw grens ligt.

Blijf je zelf doen zolang de scope klein is, de data op één plek staat, het om een intern proces gaat en een foutje geen schade veroorzaakt. Een prototype in Copilot Studio of n8n is dan een prima startpunt. Haal hulp op zodra betrouwbaarheid begint te tellen: als de agent klantcontact raakt, aan je kernsystemen hangt, op volume moet draaien, of als een fout geld of vertrouwen kost. Dat is ook het moment waarop de koppelingen en de tests, stap 2 en 4, plots het meeste werk worden.

Een goed bureau neemt niet je proces over, maar bouwt het proces dat jij kent om tot een systeem dat blijft werken, en levert code die van jou is. Wil je verkennen of jouw proces daar klaar voor is, of het beter zelf kan? [Boek een gratis adviesgesprek](https://www.whatsnext-ai.com/contact), dan kijken we er samen naar. Meer over het uitbesteden zelf, kosten en aanpak, lees je op [een AI-agent laten bouwen](https://www.whatsnext-ai.com/ai-agents). En waarom uitbesteden vaak wint van zelf een team optuigen, staat in [waarom een AI-bureau inschakelen slimmer is dan zelf bouwen](https://www.whatsnext-ai.com/blog/why-hiring-an-ai-agency-beats-building-it-yourself).

*Verantwoording: de cijfers in dit artikel, rond de 0,005 euro per gesprek, ongeveer 1.000 keer goedkoper dan het handmatige alternatief, circa drie maanden tot een stabiele productieversie en een assortiment van ruim 15.000 SKU's, zijn onze eigen resultaten uit het [Borgh-project](/cases/borgh-answers-every-product-question-in-seconds-across-15000-skus).*