Zelf bouwen of kopen: de laag voor laag keuze die de meeste AI agent teams omdraaien

De keuze tussen zelf bouwen of kopen wordt bij AI agents bijna altijd op het verkeerde niveau gemaakt. Een kamer vol capabele mensen discussieert wekenlang of ze een platform afnemen of zelf iets schrijven, alsof een agent een enkel product is dat je koopt of maakt. Dat is het niet. Een agent bestaat uit 7 afzonderlijke lagen, en elke laag heeft zijn eigen antwoord.

Neem je de beslissing op het verkeerde niveau, dan volgt een duur en herkenbaar patroon. Bedrijven kopen precies de laag waarin hun voorsprong zit, en bouwen zelf de laag die elke leverancier hen voor een paar honderd euro per maand had verhuurd. Ze betalen twee keer. Een keer aan licenties voor iets generieks, en een keer in maanden engineering aan een probleem dat de markt allang heeft opgelost.

Dit artikel is geschreven voor oprichters, CTO's en operationeel verantwoordelijken bij bedrijven met echt volume achter het proces, mensen die op het punt staan een platformcontract te tekenen of 6 maanden engineering goed te keuren. Zoek je een chatbot op een marketingsite, dan is dit veel meer diepgang dan je probleem vraagt.

Wat je hier krijgt: de 7 lagen van een AI agent met per laag een standaardkeuze, de omwisseling die het meeste geld kost, een oefening in 5 stappen waarmee je de beslissing in een middag afrondt, de kosten die noch leveranciers noch engineers in hun offerte zetten, en de omkeerbaarheidstest die elke rekensom verslaat.

‍

Belangrijkste punten

• Zelf bouwen of kopen is geen keuze over de agent. Het zijn 7 keuzes, een per laag van de agent.

• Koop het model, de runtime en de interface. Dat zijn commodities en eigenaarschap levert je daar niets op.

• Bouw de contextlaag, de beslislogica en je eigen evaluatieset. Daarin zit wat jou anders maakt.

• Integratie bepaalt je doorlooptijd, en juist die laag plannen de meeste teams als laatste.

• De duurste fout is je beslislogica huren terwijl je je eigen infrastructuur met de hand bouwt.

• Vraag wat vertrekken kost in maand 18. Omkeerbaarheid scheidt een goede aankoop van een dure val.

• Wachten is een volwaardig derde antwoord als het proces zelf nog te weinig vastligt.

‍

Zelf bouwen of kopen bij AI agents: waar de keuze echt over gaat in 2026

Zelf bouwen of kopen bij een AI agent is de keuze welke onderdelen van de agent jouw team bezit en beheert, en welke je huurt van een leverancier. Het is vrijwel nooit alles of niets, en juist daarom levert een enkele ja of nee vraag zulke slechte antwoorden op.

De verwarring zit in het woord agent. Het klinkt als een product, dus mensen winkelen ernaar als een product. In de praktijk is een agent een samenstelling. Iets redeneert, iets onthoudt, iets mag handelen, iets kijkt mee, en iets zet het voor een mens neer. Dat zijn losse onderdelen uit losse delen van de markt, en op de grenzen daartussen ligt je speelruimte.

Aan de oppervlakte heeft de markt al gekozen. In het enterprise onderzoek van 2025 onder 495 AI beslissers vond Menlo Ventures dat 76 procent van de zakelijke AI oplossingen wordt gekocht in plaats van gebouwd, tegen 53 procent een jaar eerder. Snel gelezen lijkt dat een uitspraak. Zorgvuldig gelezen is het een waarschuwing. Als bijna iedereen dezelfde functionaliteit bij dezelfde handvol leveranciers koopt, is die functionaliteit geen voorsprong meer. Het wordt een basisvoorwaarde, en wat je zelf hield is het enige dat je nog onderscheidt.

Het uitvalpercentage wijst dezelfde kant op. Gartner voorspelt dat ruim 40 procent van de agentic AI projecten voor eind 2027 wordt stopgezet, door oplopende kosten, onduidelijke businesswaarde en te zwakke risicobeheersing. Dat zijn geen modelproblemen. Het zijn scope en eigenaarschapsproblemen, oftewel slecht genomen keuzes tussen bouwen en kopen.

‍

Waarom de vraag over de hele agent de verkeerde vraag is

Stel je de vraag over de agent als geheel, dan dwing je een antwoord op 7 verschillende problemen. Er volgen 3 faalpatronen, en we zien ze alle drie regelmatig in het eerste gesprek met een nieuwe klant.

De voorsprong die je in andermans product verpakte

Een logistiek bedrijf dat we spraken had maanden besteed aan het vastleggen van hun afhandeling van uitzonderingen. Welke vertraagde zending escaleert, welke wordt automatisch omgeboekt, welke vraagt eerst een telefoontje naar de klant. Die logica was het resultaat van 15 jaar operationele ervaring. Ze gaven het vervolgens aan een platform waarvan de workflowbouwer ongeveer 70 procent kon uitdrukken, en lieten de resterende 30 procent stilletjes vallen omdat de tool het niet kon weergeven. De agent werkte. Hun uitzonderingsafhandeling leek daarna ook precies op die van hun concurrent, die hetzelfde platform gebruikt.

Dit is het patroon om het meest voor te vrezen, omdat het onderweg niet als een fout voelt. Alles wordt op tijd opgeleverd. Het verlies komt later, wanneer je onderscheidend vermogen is afgeschuurd tot de vorm van het datamodel van een leverancier.

De infrastructuur die je opnieuw betaalde

De omgekeerde fout komt net zo vaak voor en is makkelijker te zien. Een team besluit te bouwen, en bouwen betekent alles. Dus schrijven ze hun eigen orkestratielaag, hun eigen retry en queue afhandeling, hun eigen promptversiebeheer, hun eigen abstractie over de vector store. Vier tot 6 engineeringmaanden verdwijnen in problemen die een volwassen open source framework of een gehoste runtime op dag 1 had opgelost.

Niemand heeft ooit een klant gewonnen dankzij zijn eigen queue implementatie. Dit is gehuurde infrastructuur die zich gedraagt als een vast activum: duur om te bouwen, duur om te onderhouden, en buiten het bedrijf niets waard.

De evaluatie die nooit eindigt

Het derde patroon is verlamming. Als de vraag te groot is voelt geen enkel antwoord veilig, dus blijft het team evalueren. Zes demo's worden er 12. Een proof of concept loopt een kwartaal en bewijst alleen dat de demo werkt. Ondertussen blijft het proces dat de agent moest oplossen dezelfde uren opslokken als altijd.

De vraag per laag splitsen doorbreekt die impasse, want de meeste lagen blijken helemaal geen twijfelgevallen. Haal je de vanzelfsprekende eruit, dan discussieer je meestal over 2 lagen in plaats van over het hele systeem.

‍

De 7 lagen van een AI agent, en wie welke laag hoort te bezitten

Een AI agent bestaat uit 7 lagen. Beslis per laag en de meeste keuzes maken zichzelf.

De 3 lagen die je zonder veel discussie koopt

De modellaag is een huurmarkt en zo moet je hem behandelen. Topmodellen van Anthropic, OpenAI en Google zijn commodities in economische zin: uitwisselbaar, geprijsd per eenheid, en ze verbeteren sneller dan welke interne inspanning ook kan bijhouden. Een kleiner model finetunen voor een smalle taak met veel volume is soms de moeite waard om kostenredenen, maar dat is een optimalisatie voor jaar 2, geen architectuurkeuze voor maand 1.

De runtime en infrastructuurlaag omvat orkestratie, queues, retries, vectoropslag en het beheer van secrets. Koop die, of neem een goed onderhouden open source framework. Elk uur hier is een uur dat niet naar de onderdelen gaat die je klanten zouden opmerken. De enige kanttekening is dataresidentie: verplicht jouw sector verwerking binnen een bepaald rechtsgebied, dan beperkt dat je keuze aan gehoste runtimes, en dat check je beter voordat je verliefd wordt op een leverancier.

De interfacelaag is waar mensen de agent tegenkomen. Bijna altijd hoort dat een tool te zijn die je team al open heeft staan, of dat nu Slack, Teams, je ticketsysteem of het interne beheerscherm is. Een nieuwe plek bouwen voor een agent is de zekerste manier om hem genegeerd te krijgen. De uitzondering is wanneer de interface zelf je product is, en dan was het nooit een keuze tussen bouwen en kopen.

De 3 lagen die je vrijwel altijd bouwt

De context en rechtenlaag is wat de agent weet en wat hij mag zien. Welke systemen hij leest, hoe vers die data is, welke klantgegevens een bepaalde gebruiker eruit mag halen, en wat er gebeurt als een document verouderd is of een ander tegenspreekt. Geen leverancier kan dit voor je samenstellen, want het is een kaart van jouw bedrijf en jouw toegangsregels. Teams die dit afsnijden door documenten in een index van een leverancier te storten, krijgen een agent die zelfverzekerd fout zit op een manier die niemand kan herleiden.

De beslislogica is de reeks afwegingen die de agent maakt: wanneer hij zelf handelt, wanneer hij vraagt, wanneer hij escaleert, hoe een randgeval eruitziet en welke uitkomsten onacceptabel zijn. Dit is jouw werkproces uitgedrukt in software. Als een concurrent dezelfde logica bij dezelfde leverancier kan kopen, was het nooit veel waard. Bouw het, en houd het in een vorm die je kunt lezen, versioneren en aanpassen zonder een supportticket.

Evaluatie is een gesplitste keuze, en die splitsing doet ertoe. Koop het gereedschap, want evaluatieframeworks en tracingplatforms zijn volwassen en goedkoop. Bouw de testset. Een paar honderd echte gevallen uit je eigen historie, gelabeld met wat een goede uitkomst in jouw bedrijf werkelijk is, is het waardevolste bezit in het hele project. Daarmee kun je met droge ogen zeggen dat de agent klaar is, het overleeft elke wisseling van model of leverancier eronder, en geen leverancier kan het je geven.

De laag die je doorlooptijd bepaalt

Integratie is het gemengde geval, en het bepaalt of je dit kwartaal live gaat of volgend jaar. Waar je systemen gangbaar en goed gedocumenteerd zijn, koop je de connector en ga je door. Waar het gaat om een 12 jaar oud ERP, een sectorspecifiek platform of een database die iemands voorganger ooit ontwierp, reserveer je echte engineeringtijd. Dit is meestal de grootste kostenpost in een agentproject en vrijwel altijd de laatste die iemand inplant.

De praktische test is eenvoudig. Voordat je je aan een leverancier of architectuur verbindt, zet je elk systeem op een rij waaruit de agent moet lezen of waarin hij moet schrijven, en markeer je elk systeem als gedocumenteerde API, ongedocumenteerde API of geen API. Staat er iets in die derde kolom, dan bepaalt die kolom je planning en niets anders.

Breng je dit voor het eerst in kaart, dan loopt onze gratis SaaS AI Blueprint door hoe deze lagen in een echt product samenkomen, inclusief de architectuurkeuzes die later pijnlijk zijn om terug te draaien. Een nuttige aanvulling op de oefening hieronder.

‍

De omwisseling van lagen die het meeste kost

In de projecten die wij beoordelen komt een patroon vaker voor dan alle andere: teams kopen wat ze zouden moeten bezitten en bouwen wat ze zouden moeten huren. Het loont om er direct naar te kijken, want elke helft van die omwisseling faalt op een andere manier.

Je beslislogica huren faalt langzaam. Er gaat niets stuk. Je wordt alleen 18 maanden later wakker zonder de mogelijkheid je eigen proces aan te passen zonder een featureverzoek in te dienen, en zonder een klant te kunnen uitleggen waarom jouw dienst verschilt van de 3 concurrenten op hetzelfde platform.

Je infrastructuur met de hand bouwen faalt zichtbaar. Het project loopt uit, het team is uitgeput voordat de agent een enkel echt geval heeft afgehandeld, en de eerste directiebespreking gaat over de kosten in plaats van over het resultaat. Herstelbaar, maar het kost je een kwartaal dat je niet had.

Het ongemakkelijke is dat zorgvuldige mensen beide fouten maken. De workflow kopen voelt verantwoord omdat het op een kortere weg naar productie lijkt. De infrastructuur bouwen voelt verantwoord omdat het op controle lijkt. De laagbenadering scheidt de verantwoorde keuze van de keuze die alleen verantwoord voelt.

‍

Hoe je de keuze in een middag rondkrijgt

Deze beslissing heeft geen kwartaal nodig. Ze vraagt 3 uur, de juiste mensen en een whiteboard. Doe het met degene die het proces bezit, degene die de systemen bezit en degene die het budget bezit, samen in een kamer.

Stap 1 is het proces benoemen. Kies een workflow met echt volume, geen categorie. Niet klantenservice, maar de eerste reactie op restitutieverzoeken onder 200 euro. Een benoemd proces houdt de discussie bij scope in plaats van techniek, en dat is in dit stadium de enige discussie die de moeite waard is.

Stap 2 is de stack splitsen. Schrijf de 7 lagen op het bord. Alleen dat verandert het gesprek al, want mensen die het hevig oneens waren blijken meestal verschillende vragen te beantwoorden. Wie wilde kopen bedoelde de runtime. Wie wilde bouwen bedoelde de logica. Beiden hadden gelijk.

Stap 3 is de voorsprong markeren. Loop de lagen langs en vraag of een concurrent met hetzelfde budget morgen hetzelfde kan kopen. Zo ja, dan is het een commodity en huur je het. Zo nee, dan hoort het bij jou en bezit je het volledig. In onze ervaring omcirkelt dit vrijwel altijd de contextlaag en de beslislogica, en verder weinig.

Stap 4 is de rest prijzen. Vraag voor elke laag die je als commodity markeerde een echte offerte in plaats van een schatting. Vraag om prijzen bij 10 keer je huidige volume, niet bij het volume van vandaag, want agentgebruik is een van de weinige posten die echt meegroeit met succes. Een prijs per run die in een pilot verwaarloosbaar lijkt, kan binnen een jaar je grootste infrastructuurpost zijn.

Stap 5 is de omkeerbaarheidstest, belangrijk genoeg voor een eigen hoofdstuk hieronder.

Je loopt naar buiten met een beslissing van 1 pagina: 7 lagen, 7 keuzes, een maandlast voor de gekochte delen en een afgebakende bouw voor de rest. Die pagina neem je mee naar een bestuur of een investeerder, en die houdt stand bij doorvragen op een manier die een leveranciersvergelijking nooit haalt.

‍

Wat kopen werkelijk kost

Prijspagina's beschrijven de licentie, niet de kosten. Vier posten vallen structureel buiten de offerte.

• De aanpassingsheffing. Jouw proces past niet precies op het model van de leverancier. Je buigt je proces om of je betaalt voor professional services, en beide zijn echte kosten die na ondertekening opduiken.

• Het integratiewerk dat je toch al moest doen. Een platform kopen lost het connectorprobleem voor je afwijkende systemen niet op. Het verplaatst het alleen.

• Meegroeien met succes. Prijzen per gebruiker, per run en per token stijgen naarmate de agent werkt. Reken de rekening door op het volume dat je hoopt te halen, niet op wat je nu hebt.

• De uitgang. Vraag expliciet wat je meeneemt als je vertrekt: je prompts, je workflowdefinities, je evaluatiehistorie, je logs. Is het antwoord vaag, dan is het antwoord niets.

‍

Wat zelf bouwen werkelijk kost

Engineers schatten meestal de verkeerde helft. De modelintegratie is zelden het dure deel, en het is niet het deel dat uitloopt.

Het geld gaat naar integratie met lastige systemen, naar de contextlaag en de bijbehorende rechten, naar het opbouwen van de evaluatieset, en daarna naar het draaiend houden zodra het live is. Die laatste post wordt het vaakst helemaal vergeten. Een agent in productie heeft monitoring nodig, iemand die de uitzonderingswachtrij bezit, een manier om een slechte wijziging terug te draaien, en een periodieke toets of de antwoorden nog kloppen terwijl het bedrijf verschuift. Begroot voor het tweede jaar, niet alleen voor de lancering.

Het goede nieuws is dat de marginale kosten dalen. Zodra het integratie en contextwerk staat, is uitbreiden naar een tweede en derde workflow dramatisch goedkoper dan de eerste, omdat je hergebruikt wat de moeite kostte. Daarom is de eerlijke vergelijking niet bouwen tegen kopen op 1 workflow. Het zijn de kosten over 3 jaar over alle workflows die je wilt automatiseren.

‍

De omkeerbaarheidstest

Als een keuze echt dicht bij elkaar ligt, stop dan met functies vergelijken en stel 1 vraag: wat kost het ons om dit in maand 18 terug te draaien?

Bij een gekochte laag betekent dat vragen hoe vertrekken eruitziet. Kun je je configuratie in bruikbare vorm exporteren? Houd je je evaluatiehistorie? Hoe lang duurt een migratie en wie doet die? Een laag waar je binnen 2 weken van af komt is een aankoop met laag risico, ook als hij niet perfect is. Een laag die 6 maanden kost om te ontwarren is een strategische verbintenis en verdient die behandeling.

Bij een zelfgebouwde laag draait de vraag om: als een leverancier dit volgend jaar netjes oplost, kun je jouw implementatie dan laten vallen en de hunne overnemen zonder de rest aan te raken? Dat pleit voor schone grenzen tussen lagen, en het is de praktische reden waarom het laagmodel ook na de eerste beslissing waarde houdt.

Omkeerbaarheid is een betere gids dan kosten, want je kostenramingen kloppen niet en je vermogen om van gedachten te veranderen blijft overeind. We gaan dieper op de valkuilen in in onze gids over vendor lock-in bij AI voor SaaS teams.

‍

5 vragen die laten zien of een leverancier een laag aankan

Koop je een laag, dan scheiden deze 5 vragen een capabele leverancier van een goede demo. Stel ze in deze volgorde.

• Laat me een klant in productie zien, geen pilot. Hoe lang duurde het van demo tot echt volume, en wat ging daartussen mis?

• Wat gebeurt er als jullie modelleverancier het gedrag verandert? Wie test dat, wie waarschuwt ons, en wat is de opzegtermijn?

• Kan ik mijn prompts, workflowdefinities, evaluatiehistorie en logs vandaag exporteren, in een formaat dat ik elders kan gebruiken?

• Waar houdt het aanpassen op? Laat me het concrete ding zien dat jullie platform niet kan uitdrukken, en wees daar eerlijk over.

• Wie is verantwoordelijk als een verkeerd antwoord bij een klant terechtkomt? Loop me door jullie laatste geval heen.

De laatste vraag zegt het meest. Een leverancier die nooit een incident had, heeft geen klanten in productie of vertelt niet de waarheid. Een leverancier die er een helder beschrijft, inclusief wat ze daarna veranderden, heeft echt iets in beheer gehad.

‍

Wanneer wachten het juiste antwoord is

Wachten is een volwaardig antwoord en het wordt te weinig gekozen. Drie situaties vragen erom.

• Het proces ligt niet vast. Verandert de workflow elke paar weken omdat het bedrijf nog vorm zoekt, dan legt elke agent die je bouwt een momentopname vast die al achterhaald is. Stabiliseer het proces eerst, op papier, met mensen.

• Niemand bezit het resultaat. Kun je niet benoemen wiens cijfers verbeteren als de agent werkt, dan heeft het project geen thuis en wordt het stil afgeblazen, hoe goed het ook is gebouwd.

• De data is niet bereikbaar. Staat de informatie die de agent nodig heeft in iemands inbox of een spreadsheet op een laptop, dan is het eerste project een dataproject en geen agentproject. Dat is kleiner en waardevoller werk dan wat je op het punt stond te financieren.

Om een van deze redenen wachten is geen besluiteloosheid. Het is hetzelfde oordeelsvermogen dat de andere 6 lagen makkelijk te beslissen maakt.

‍

Hoe wij de keuze maken bij Codelevate

Als een klant met een workflow komt, beginnen we niet bij techniek. We brengen de lagen in kaart, markeren welke hun voorsprong dragen, en discussiëren daarna alleen nog over die. Meestal liggen 5 van de 7 binnen een uur vast, waardoor het echte gesprek, over context en beslislogica, genoeg ruimte krijgt.

Vervolgens bouwen we de lagen die van de klant zijn zo dat ze die na ons vertrek zelf bezitten: leesbare logica, een gedocumenteerde contextlaag, een evaluatieset uit hun eigen historische gevallen, en schone grenzen zodat elke gekochte laag later vervangen kan worden zonder herbouw. Op de commodity lagen doen we een aanbeveling en gaan we uit de weg. Dat is onze hele aanpak van AI development, en het is de reden dat onze klanten een tweede workflow doorgaans veel sneller live krijgen dan de eerste.

‍

De korte versie

Zelf bouwen of kopen bij AI agents is geen beslissing die je een keer neemt. Het zijn er 7, en 5 daarvan zijn geen twijfelgevallen. Huur het model, de runtime en de interface. Bezit de contextlaag, de beslislogica en je evaluatieset. Plan de integratielaag als eerste, want die bepaalt je doorlooptijd. Toets daarna elke keuze aan wat het kost om over 18 maanden van gedachten te veranderen.

Teams die zo beslissen betalen niet twee keer. Ze gaan sneller live, omdat het grootste deel van de stack gekocht is en de discussie smal blijft. En ze houden het deel dat hen de moeite waard maakt, wat het hele punt is van een proces automatiseren waar je al goed in bent.

Wil je het architectuurdenken hierachter uitgebreider, dan is de SaaS AI Blueprint gratis en behandelt hij de keuzes die het lastigst terug te draaien zijn. En voer je dit gesprek liever met iemand die het vaker heeft gedaan, plan dan een vrijblijvend gesprek met ons team en neem 1 workflow mee. Een uur is meestal genoeg om te weten welke lagen echt van jou zijn.