Wanneer bouw je geen AI-agent (doe dit in plaats daarvan)

Inhoudsopgave

Gepubliceerd augustus 2026.

TL;DR: De meeste AI-agentideeën zijn de verkeerde tool voor de klus. Voordat ik agentcode schrijf, controleer ik op vijf signalen die het diskwalificeren — een onstabiel proces, lage frequentie, geen slaag/faal-test, een simpeler middel dat al werkt, of een onomkeerbaar faalscenario dat ik niet op tijd kan afgrendelen. Als een ervan geldt, bouw ik niet. In plaats daarvan doorloop ik een ladder van goedkopere alternatieven, en pas als niets daarvan standhoudt, kom ik terug op een eigen agent.

[Operatorsperspectief] Ik beheer meer dan 30 agents in productie voor een consultingmerk en Pickleland, een pickleballlocatie in Pflugerville, TX. Ik heb minstens evenveel agentideeën geschrapt als ik heb gelanceerd, en bijna geen ervan sneuvelde omdat het idee slecht was — ze sneuvelden omdat een agent de verkeerde tool was voor die specifieke klus. Dit is het filter dat ik toepas voordat “moet ik dit bouwen” verandert in “hoe bouw ik dit.”

Het standaardantwoord is nee

Het ROI-framework dat ik gebruik vertelt je of een automatisering de bouw- en onderhoudskosten terugverdient. Dat is de juiste tweede vraag. De eerste vraag is eenvoudiger en wordt voortdurend overgeslagen: moet dit überhaupt een agent zijn?

“Agent” is het standaardlabel geworden voor alles waar een LLM bij betrokken is, net zoals “app” vijftien jaar geleden het standaardlabel werd voor alles waar een scherm bij betrokken was. Niet alles wat een model raakt heeft een permanent, autonoom, tool-aanroepend systeem nodig dat op triggers wacht en zelfstandig acties onderneemt. Veel van wat mensen “een agent bouwen” noemen, is eigenlijk “een heel goede prompt schrijven en die handmatig uitvoeren” — en dat is geen mislukking, het is vaak de juiste eindtoestand.

Ik behandel “een eigen agent bouwen” als de duurste optie op een ladder van opties, niet als de eerste trede. Voordat ik ernaar reik, controleer ik of de taak zichzelf diskwalificeert.

Vijf signalen dat een agent de verkeerde tool is

Elk van deze op zich is meestal genoeg om me tegen te houden.

1. Het proces is nog niet stabiel. Als de workflow de afgelopen maand twee keer is veranderd omdat het bedrijf zelf nog aan het uitzoeken is wat het wil, legt een agent de huidige versie van een proces vast dat op het punt staat opnieuw te veranderen. Je herschrijft de prompt, het tool-schema en de evalset elke keer dat het proces verschuift — wat betekent dat je een agent onderhoudt in plaats van een bedrijf runt. Doe het handmatig totdat het een kwartaal lang stilstaat, en automatiseer dan de vaststaande versie.

2. Het komt te weinig voor om zich terug te verdienen. Een taak die twee keer per jaar voorkomt, accumuleert niet genoeg uitvoeringen om bouwtijd, testtijd en een evalset te rechtvaardigen, hoe goed hij eenmaal gebouwd ook zou presteren. Lage frequentie met hoge bouwinspanning is bijna het slechtste kwadrant voor automatisering — je betaalt de volledige bouwkost en int nauwelijks besparingen.

3. Je kunt er geen slaag/faal-test voor schrijven. Als je niet vooraf kunt beschrijven wat een correcte uitvoer eruitziet, goed genoeg om het programmatisch te controleren, kun je er geen eval-harnas voor bouwen — en een agent die je niet kunt evalueren, is een agent waarbij je blind vliegt. Taken die pure smaak zijn (“klinkt dit als mij”) of pure oordeelsvorming zonder consistente maatstaf erachter, blijven handmatig, of blijven elke keer door een mens beoordeeld — wat het doel van automatiseren tenietdoet.

4. Een simpeler middel doet het werk al. Vraag jezelf, voordat je een agent scoped, af wat een spreadsheetformule, een Zapier/Make/n8n-workflow met één LLM-stap, of een opgeslagen prompt zou opleveren. Als het eerlijke antwoord “90% van de weg” is, rechtvaardigt de laatste 10% zelden een agent met zijn eigen infrastructuur, monitoring en onderhoudsbelasting. Ik heb agents gescoped voor taken die een filterweergave en een terugkerende agenda-herinnering net zo goed hadden opgelost.

5. Het faalscenario is onomkeerbaar en je hebt geen tijd om de poort goed te bouwen. Sommige acties — een massa-e-mail versturen, een terugbetaling, een openbaar bericht — kunnen niet ongedaan worden gemaakt. Poorten met menselijke controle bestaan precies hiervoor, maar een overhaaste poort die niemand daadwerkelijk beoordeelt, is erger dan geen automatisering: het creëert de schijn van toezicht zonder de inhoud. Als je geen tijd hebt om de poort goed te bouwen en te bemensen, is dat een signaal om te vertragen, niet een reden om de poort over te slaan.

Als geen van de vijf van toepassing is — het proces is stabiel, het komt vaak genoeg voor, je kunt “correct” definiëren, geen simpeler middel dekt het, en het faalscenario is ofwel omkeerbaar ofwel goed afgegrendeld — dan is het de moeite waard om de ROI-rekensom erop los te laten.

De ladder die ik beklim voor ik ga bouwen

Wanneer een taak niet door een van de vijf checks komt — of zelfs voordat ik zover ben gekomen — doorloop ik onderstaande lijst in volgorde, en ik stop bij de eerste trede die het probleem daadwerkelijk oplost.

1. Vraag het model gewoon rechtstreeks. Geen wrapper, geen tool-aanroepen, geen permanente infrastructuur. Open Claude, plak de context, stel de vraag, gebruik het antwoord. Dit lost meer eenmalige en incidentele taken op dan mensen verwachten, omdat het “agent”-instinct zelfs oplaait bij dingen die maar één keer hoeven te gebeuren.

2. Een opgeslagen prompt of projectinstructies. Als hetzelfde soort verzoek herhaaldelijk voorkomt maar elk geval nog steeds een mens nodig heeft om de invoer te verzamelen en de uitvoer te beoordelen, sla dan de prompt op als sjabloon — projectinstructies, een aangepaste instructieset, een snippet — in plaats van de trigger te automatiseren. Je krijgt het consistentievoordeel van een agent zonder de infrastructuur.

3. Een no-code automatiseringstool met één LLM-stap. Voor taken die echt een trigger nodig hebben (een nieuwe formulierinzending, een nieuwe rij in een spreadsheet) maar waarvan de logica zelf eenvoudig is, is een workflowtool met één modelaanroep in het midden aanzienlijk goedkoper om te bouwen en te onderhouden dan eigen code. Ik grijp hiernaar voordat ik naar eigen infrastructuur reik, telkens als de trigger standaard is en het volume laag tot gemiddeld.

4. Een handmatig uitgevoerd sjabloon. Sommige processen hebben meer baat bij een checklist dan bij automatisering, omdat de waarde zit in een mens die elke stap doordenkt, niet in snelheid. Automatiseer het denkwerk niet weg bij taken waar het denken het hele punt is.

5. Uitbesteden. Voor alles met echte ambiguïteit of oordeelsvorming waarbij je geen tijd hebt om een evalset te bouwen en te onderhouden, is een persoon — een VA, een specialist, een gepakketteerde dienst-aanbieder — vaak sneller op te starten en onderweg makkelijker te corrigeren dan een agent die je nog aan het afstellen bent.

6. Pas dan: een eigen agent. Als je de ladder hebt doorlopen en niets ervan houdt stand — de trigger vereist echte oordeelsvorming onder druk, het volume is te hoog voor handmatige of uitbestede afhandeling, en het komt door de ROI-rekensom — dan is dat het moment waarop een op maat gebouwde agent met zijn eigen betrouwbaarheidsstack zijn bouwkosten terugverdient.

De schaduwtest van twee weken

Voor alles wat op het randje zit — slaagt voor de vijf checks maar ik ben nog niet zeker — voer ik een schaduwtest van twee weken uit voordat ik me aan een build verbind. Ik doe de taak zelf, met het model als copiloot in plaats van als autonoom systeem: dezelfde prompt die ik uiteindelijk aan de agent zou geven, dezelfde invoer, maar ik lees elke uitvoer voordat die ergens naartoe gaat.

Er komen twee dingen uit die test. Ten eerste, of het model daadwerkelijk goed is in de taak op het kwaliteitsniveau dat ik nodig heb — als ik de helft van zijn uitvoer handmatig herschrijf, is de taak nog niet klaar om te automatiseren, ongeacht al het andere. Ten tweede, een echte evalset: twee weken invoer en de uitvoer die ik als correct beoordeelde zijn precies wat een eval-harnas nodig heeft, en die heb ik meestal gratis verzameld tegen de tijd dat ik besluit te bouwen.

De schaduwtest legt ook edge cases bloot voordat ze in productie zitten. Het is veel goedkoper om tijdens een handmatige proef te ontdekken dat 15% van de invoer speciale behandeling nodig heeft, dan om het te ontdekken via een klantklacht nadat de agent live is gegaan.

Een regel die ik toepas na het schrappen van een idee

Een agentidee schrappen is niet hetzelfde als het onderliggende probleem oplossen. Als een taak zich voor nu diskwalificeert — het proces verschuift nog, het volume is te laag — schrijf ik op waarom en stel ik een ruw herbeoordelingspunt vast (meestal gekoppeld aan een specifieke trigger: “opnieuw beoordelen zodra boekingen boven de 50/week komen”, niet gewoon een datum). Agentideeën die eenmaal worden geschrapt en nooit worden herbezocht, veranderen stilletjes in permanent handwerk dat niemand zich herinnert twee keer geëvalueerd te hebben.

De omgekeerde discipline is net zo belangrijk: een idee dat de vijf checks en de ROI-rekensom doorstaat, wordt niet automatisch vandaag gebouwd. Het komt in dezelfde wachtrij als al het andere, gerangschikt tegenover de automatiseringen die zich al bewezen hebben terug te verdienen. Het filter doorstaan levert een taak een plek in de rij op, geen vrijstelling van prioritering.

FAQ

Is dit niet gewoon een argument tegen automatisering?

Nee — het is een argument tegen het standaard kiezen voor de duurste vorm van automatisering. De meeste alternatieven op de ladder hierboven zijn nog steeds automatisering; ze zijn alleen lichter van gewicht. Ik draai tientallen agents in productie. Het punt is niet om bouwen te vermijden; het is om te stoppen met meteen doorschakelen naar “bouw een eigen agent” wanneer een opgeslagen prompt of een no-code workflow je dezelfde uitkomst geeft voor een fractie van de bouw- en onderhoudskosten.

Wat als de taak duidelijk later in volume zal groeien?

Dat is een legitieme reden om vooruit te bouwen op de huidige aantallen — ik behandel deze uitzondering in het ROI-framework. Het overstemt de vijf signalen hierboven echter niet. Als het proces nog onstabiel is of je nog geen correcte uitvoer kunt definiëren, betekent groeiend volume alleen dat je op grotere schaal een kapotte agent gaat onderhouden. Los eerst instabiliteit en testbaarheid op; schaal is een reden om eerder te bouwen zodra die zijn opgelost, geen reden om ze over te slaan.

Hoe weet ik of een no-code-toolstap “goed genoeg” is versus dat er eigen code nodig is?

Probeer het eerst en meet het tegen je evalset, ook een informele. No-code LLM-stappen kunnen goed overweg met eendoelige, één-invoer-taken. Ze beginnen te haperen zodra je meerstaps-tool-gebruik, aanhoudende status tussen runs, of conditionele logica nodig hebt die de bouwer van de tool niet netjes kan uitdrukken. Als je die muur raakt, is dat een echt signaal om naar eigen infrastructuur te verhuizen — geen reden om daar te beginnen.

Geldt dit anders voor interne tools dan voor klantgerichte tools?

De vijf signalen gelden op dezelfde manier, maar de inzet verschilt. Een intern tool met een onstabiel proces verspilt alleen de tijd van je eigen team wanneer het kapotgaat. Een klantgericht tool met een onstabiel proces ondermijnt het vertrouwen van mensen die zich niet hebben aangemeld als jouw evalset. Ik houd klantgerichte automatiseringen aan een strengere versie van signaal vijf in het bijzonder — de lat voor “goed afgegrendeld” ligt hoger wanneer een vreemde, niet een collega, aan de andere kant van een fout staat.

Wat is de meest voorkomende reden waarom je een agentidee schrapt?

Signaal drie — geen duidelijke slaag/faal-test. Het is het makkelijkst te missen tijdens het scopen, omdat de taak goed gedefinieerd aanvoelt totdat je probeert vooraf op te schrijven wat een correcte uitvoer eigenlijk is. Als ik dat niet in een of twee zinnen kan doen, weet ik dat de agent onevalueerbaar wordt, wat betekent onverbeterbaar, wat betekent dat hij nog niet gebouwd wordt.