De meeste AI-projecten hebben geen agent nodig

De meeste organisaties die vastlopen met AI zoeken de oplossing in een agent. Maar in 9 van de 10 keer zit de beste oplossing in een AI-workflow. Barry Zhang, die bij Anthropic de infrastructuur achter agents bouwt, gaf onlangs een talk met een nuchtere boodschap: bouw niet voor elke taak een autonome agent. Kun je de stappen vooraf uittekenen, dan is een vaste workflow goedkoper, sneller en betrouwbaarder. Een agent verdient zijn plek alleen bij taken die echt ambigu en waardevol zijn. Dit stuk legt het verschil uit, geeft je vier vragen om de keuze te maken, en vertaalt het naar wat je nu concreet doet voordat je iets laat bouwen.

Waarom "agent" overal opduikt en zelden nodig is

Het woord "agent" is in een jaar tijd van technische term tot verkoopargument geworden. Elke leverancier heeft er een, elke demo laat er een zien, en op de directietafel landt de vraag: moeten wij ook agents? De aanname onder die vraag is dat een agent het hoogste niveau van AI is, en dat alles daaronder een tussenstap is die je zo snel mogelijk voorbij wilt.

Wij ondersteunen die aanname niet, want het strookt niet met wat wij zien werken in de praktijk. Ook uit een andere hoek, wellicht niet direct verwacht, horen we hetzelfde geluid. Barry Zhang bouwt bij Anthropic aan de systemen die agents draaiend houden. Samen met collega Erik schreef hij eind 2024 het invloedrijke stuk Building Effective Agents. Begin dit jaar gaf hij op de AI Engineer Summit een talk van een kwartier die je het beste kunt samenvatten als een vriendelijk verzoek: stop met overal een agent op zetten. De volledige talk staat hieronder, en is de moeite van het kijken waard.

Stop met overal een agent op zetten - Chef Agents bij Anthropic

Waarom dit ertoe doet voor wie keuzes maakt over AI-budget: de architectuur die je kiest bepaalt je kosten, je betrouwbaarheid en hoe snel je iets werkends in productie hebt. Kies je een agent waar een workflow had volstaan, dan betaal je meer, wacht je langer en krijg je een systeem dat lastiger te vertrouwen is. Bij Dubbel.ai bouwen we workflows en agents voor onze klanten, en we zien in de praktijk wat Zhang vanuit Anthropic beschrijft: de teams die NU werkende AI opleveren, kozen meestal de saaie optie en waren daardoor twee keer zo snel klaar.

Wat is het verschil tussen een workflow en een agent

Anthropic maakt een helder onderscheid, en het loont om dat scherp te hebben voordat je een keuze maakt. Beide vallen onder de noemer "agentic systems", maar ze werken anders.

Een workflow is een systeem waarin taalmodellen en tools via vooraf vastgelegde stappen worden aangestuurd. Jij tekent de route uit. Het model vult de stappen in, maar de volgorde ligt vast in code. Een agent bepaalt zijn eigen route. Je geeft het een doel en een set tools, en het model beslist zelf welke stap het zet, leest de uitkomst, en beslist op basis daarvan wat het daarna doet. Het werkt vrijwel zelfstandig, op basis van feedback uit zijn omgeving.

Het verschil zit dus in wie de regie over de route heeft. Bij een workflow ben jij dat. Bij een agent is dat het model. Dat klinkt als een graduele stap, maar het is een principiële. Geef je een systeem meer eigen beslissingsruimte, dan wordt het flexibeler en kan het meer aan. Tegelijk stijgen de kosten, de wachttijd en de gevolgen van een fout. Zhang vat het samen: hoe meer zelfstandigheid je een systeem geeft, hoe nuttiger het kan zijn, maar ook hoe duurder en risicovoller.

Een belangrijk inzicht dat vaak wegvalt: een workflow staat op zichzelf, met eigen patronen die hun waarde in productie bewijzen. Anthropic beschrijft er een handvol.

• Prompt chaining: je hakt een taak in vaste deelstappen, waarbij elke modelaanroep voortbouwt op de vorige. Denk aan: eerst een tekst schrijven, dan vertalen. Tussen de stappen kun je een controle inbouwen die checkt of het nog klopt.

• Routing: je classificeert de input en stuurt hem naar de juiste vervolgstap. Eenvoudige klantvragen naar een snel, goedkoop model, complexe vragen naar een zwaarder model. Zo houd je grip op kwaliteit en kosten tegelijk.

• Parallellisatie: je laat meerdere modelaanroepen tegelijk werken en voegt de uitkomsten samen. Handig voor snelheid, of om meerdere perspectieven op dezelfde vraag te krijgen.

• Orchestrator-workers: een centraal model verdeelt het werk over deeltaken en voegt de resultaten samen, waarbij de deeltaken niet vooraf vastliggen.

• Evaluator-optimizer: het ene model schrijft, het andere geeft feedback, in een lus tot het resultaat goed genoeg is. Vergelijkbaar met hoe een schrijver een tekst aanscherpt op commentaar van een redacteur.

Voor de meeste taken die organisaties willen automatiseren is een van deze patronen genoeg. Sterker nog: vaak is zelfs een enkele goede modelaanroep met de juiste context al voldoende. De goede vraag is hoe eenvoudig je systeem mag blijven en nog steeds werkt.

Waarom je bijna altijd met een workflow wint

Anthropic geeft een vuistregel die simpel klinkt en in de praktijk veel geld bespaart: zoek de eenvoudigste oplossing die werkt, en voeg pas complexiteit toe als die zich aantoonbaar terugverdient. Soms betekent dat helemaal geen agentic systeem bouwen.

De kern van Zhangs boodschap: kun je de beslisboom van een taak vooraf uittekenen, bouw die dan expliciet. Optimaliseer elke stap. Dan heb je een systeem dat goedkoper is, sneller reageert en voorspelbaarder werkt dan een agent die elke keer opnieuw zelf moet uitvogelen wat de volgende stap is. Die zelfstandige verkenning is namelijk niet gratis. Een agent verbruikt bij elke beslissing tokens, en die tokens lopen op.

Zhang maakt dat concreet met een rekenvoorbeeld. Stel je bouwt een klantenservicesysteem met hoog volume en je budget is ongeveer tien cent per taak. Dan heb je ruimte voor 30.000 tot 50.000 tokens per taak. Dat is te weinig voor een agent die vrij mag rondzoeken. Maar het is ruim genoeg voor een workflow die de meest voorkomende scenario's afhandelt. En juist die meest voorkomende scenario's vormen het leeuwendeel van je waarde. Met een workflow vang je de 80 procent die telt, tegen een fractie van de kosten.

Dit raakt aan iets dat we vaker zien in de praktijk. De vraag "moet ik kopen of bouwen, en hoe geavanceerd" speelt op meerdere niveaus tegelijk. We werkten die afweging eerder uit voor de keuze tussen een kant-en-klare tool en maatwerk bij AI-agents, waar de gevoeligheid van je data de doorslag geeft. De achterliggende denkbeweging is dezelfde: begin bij wat het probleem oplost, en voeg geavanceerdheid pas toe als die nodig is.

Een mooi voorbeeld van de eenvoudige weg die toch grootschalig werkt: Mercedes-Benz gaf zijn medewerkers de mogelijkheid om zelf AI-workflows te bouwen op een low-code platform. Vaste, controleerbare workflows die de medewerkers zelf in elkaar zetten, zonder autonome agents die de fabriek besturen. IT bewaakt de spelregels, de medewerkers doen de rest. Saai? Misschien. Maar het draait, op de schaal van een wereldconcern.

Wanneer een agent zijn kosten wel waard is

Agents zijn een krachtige manier om complexe, waardevolle taken op te schalen. Ze zijn alleen geen standaard-upgrade voor elke toepassing. De kunst zit in de keuze. Anthropic geeft daar een checklist voor, en wij hebben die voor de directietafel teruggebracht tot vier vragen. Loop ze in volgorde af voordat je iets laat bouwen.

Vraag 1: kun je de stappen vooraf uittekenen?

Agents komen tot hun recht in problemen waar de route niet vastligt. Coderen is daar het schoolvoorbeeld van: van een ontwerpdocument naar werkende code is een open, onvoorspelbaar pad. Je weet vooraf niet hoeveel bestanden er aangepast moeten worden of in welke volgorde. Maar als je de beslisboom van een taak wél netjes kunt uittekenen, bouw die dan gewoon. Een workflow geeft je dan meer controle en lagere kosten. Deze vraag overlapt sterk met de check die we klanten meegeven voordat ze een AI-project starten: hoe helder en gestructureerd is het proces dat je wilt automatiseren?

Vraag 2: rechtvaardigt de waarde de kosten?

De verkenning die een agent doet kost tokens, en dus geld. De taak moet die kosten waard zijn. Bij een taak van tien cent past geen vrij rondzoekende agent. Bij een taak waar je antwoord op zou geven met "het maakt me niet uit hoeveel het kost, als hij maar af komt", past hij wel. Tussen die twee uitersten ligt het grootste deel van het werk, en daar is de afweging het belangrijkst. Reken het door voordat je begint.

Vraag 3: zijn de kritieke stappen betrouwbaar genoeg?

Voordat je een agent loslaat, check of er geen zwakke schakel in zijn route zit. Bij een codeer-agent wil je zeker weten dat hij goede code schrijft, kan debuggen, en zich kan herstellen van zijn eigen fouten. Zit daar een bottleneck, dan is dat zelden fataal, maar het vermenigvuldigt wel je kosten en wachttijd. De oplossing zit meestal in minder scope: versmal de taak, vereenvoudig hem, en probeer opnieuw.

Vraag 4: wat kost een fout, en zie je hem op tijd?

Dit is de vraag die op de directietafel het zwaarst weegt. Zijn de fouten van het systeem ingrijpend en moeilijk te ontdekken, dan wordt het lastig om een agent zelfstandig te laten handelen. Je kunt het risico beperken door de scope te beperken, door alleen leesrechten te geven, of door een mens op vaste punten te laten meekijken. Maar elke rem die je inbouwt, beperkt ook hoe ver je de agent kunt opschalen. Coderen werkt zo goed als agent-toepassing juist omdat de uitkomst makkelijk te controleren is: een unit-test en een code-review laten direct zien of het klopt.

Vier vragen, één rode draad. Een agent verdient zijn plek bij taken die tegelijk ambigu zijn, genoeg waarde hebben, betrouwbaar uit te voeren zijn, en waar een fout zichtbaar en te overzien is. Voldoet je taak daar niet aan, dan is een workflow de betere keuze. Sneller live en makkelijker te vertrouwen.

Anthropic ziet in de praktijk twee domeinen waar agents hun kosten structureel terugverdienen. Het eerste is klantenservice, waar een gesprek van nature heen en weer gaat en de agent onderweg klantdata ophaalt, bestellingen nakijkt en acties uitvoert. Het succes is meetbaar: is de vraag opgelost of niet? Sommige aanbieders rekenen zelfs alleen af per opgeloste zaak, een teken dat ze vertrouwen op wat hun agent levert. Het tweede domein is software bouwen, waar de uitkomst objectief te toetsen is met een test. Zie je dat patroon terug in je eigen taak, een open verloop met een heldere maatstaf voor succes en een mens die op de belangrijke punten meekijkt, dan is een agent goed te verdedigen.

Een offerte is een workflow, vooronderzoek een agent

Een voorbeeld maakt het concreet. Neem een salesteam dat sneller offertes wil opstellen. Het intakeproces van een offerte ligt grotendeels vast: gegevens uit een aanvraag halen, de juiste tekstblokken kiezen, een prijsopgave berekenen, een concept opstellen. Die stappen kun je uittekenen. Een workflow loopt ze betrouwbaar af en levert in minuten een concept waar een mens de laatste hand aan legt. Snel live, en je weet precies wat het systeem doet.

Vergelijk dat met een ander deel van hetzelfde salesproces: het vooronderzoek naar een nieuwe prospect. Daar ligt de route niet vast. De ene keer vind je het antwoord in een jaarverslag, de andere keer in een nieuwsbericht of een vacaturetekst, en wat je vindt bepaalt waar je daarna zoekt. Dat is het ambigue, open pad waar een agent in uitblinkt. Geen vaste stappen, wel een helder doel en de tools om er zelf naar te zoeken.

Hetzelfde onderscheid zie je op de redactievloer. Een uitzending omzetten naar een artikel volgt een vaste vorm en leent zich voor een workflow. Een open researchvraag die je dwingt om bronnen te volgen die je vooraf niet kent, leunt richting een agent. De les is steeds dezelfde: de aard van de taak bepaalt de architectuur. Begin daar, en het woord "agent" verliest vanzelf zijn magie.

Hou het simpel, ook als je wel voor een agent kiest

Stel, je hebt de vier vragen langs je taak gelegd en een agent is echt de juiste keuze. Dan is de tweede les van Zhang minstens zo waardevol: hou het zo lang mogelijk simpel. Een agent is volgens hem in de kern drie dingen. Een omgeving waarin hij werkt. Een set tools waarmee hij iets kan doen en feedback krijgt. En een system prompt die het doel, de grenzen en het gewenste gedrag beschrijft. Het model draait die drie in een lus, en dat is een agent.

Alles wat daar bovenop komt, denk aan caching, orkestratie, meerdere agents die samenwerken, is later zorg. Vooraf complexiteit toevoegen doodt vooral je snelheid om te leren en bij te sturen. Zhang vertelt dat ze bij Anthropic drie heel verschillende agent-toepassingen bouwden, voor zichzelf en voor klanten, die er op de buitenkant totaal anders uitzien, maar vrijwel dezelfde ruggengraat delen. Soms zelfs vrijwel dezelfde code. De twee echte ontwerpkeuzes zijn telkens: welke tools geef je de agent, en welke instructie schrijf je mee.

Die tools zijn geen bijzaak. De manier waarop een agent met zijn omgeving praat, loopt via die tools, en de standaard die dat tegenwoordig regelt heet MCP. We legden eerder uit wat MCP is en waarom het uitmaakt voor je organisatie. De korte versie: het is de stekker waarmee je een model veilig op je eigen systemen aansluit. Hoe beter je die tools beschrijft, hoe betrouwbaarder de agent ermee werkt.

Denk zoals je agent, niet zoals jezelf

Zhang komt met een heel praktisch inzicht: kijk naar de taak door de ogen van het model, niet door je eigen ogen. Doe je dat, dan snap je ineens waarom een agent een fout maakt die voor jou onlogisch lijkt, en kun je hem beter bouwen. Veel mensen doen het omgekeerde en ontwerpen vanuit hun eigen blik op de wereld. Het probleem: jij overziet de hele context, de agent niet. Alles wat het model op een bepaald moment weet, staat in die 10.000 tot 20.000 tokens die het op dat moment voor zich heeft. Niet meer.

Zhang gebruikt een beeld dat blijft hangen. Stel je voor dat je zelf een agent bent die een computer bedient. Je krijgt een statische schermafbeelding en een matig geschreven opdracht. Je kunt nadenken zoveel je wilt, maar alleen je tools veranderen iets. Je klikt ergens, en terwijl de actie wordt uitgevoerd doe je drie tot vijf seconden je ogen dicht. Dan open je ze weer en zie je een nieuw scherm. Misschien werkte je klik. Misschien heb je de computer uitgezet. Je weet het niet. En dan begint het opnieuw.

Wie die oefening een keer echt doet, snapt ineens wat een agent nodig heeft. Welke schermresolutie heeft hij, zodat hij weet waar hij kan klikken? Welke acties zijn aan te raden, en welke verboden, zodat hij niet onnodig gaat verkennen? Die context lijkt vanzelfsprekend als je hem mist, maar je geeft hem alleen mee als je door de ogen van het model kijkt.

Het mooie is dat we systemen bouwen die onze eigen taal spreken. Je kunt het model dus gewoon vragen om zichzelf te begrijpen. Plak je system prompt terug in Claude en vraag: is hier iets onduidelijk? Snap je deze instructie? Gooi een tool-beschrijving erin en vraag of het model weet hoe het die moet gebruiken, of het meer of minder parameters wil. Bij Anthropic gooien ze geregeld de hele route van een agent terug in het model met de vraag: waarom denk je dat we hier deze beslissing namen, en wat had je nodig om een betere keuze te maken? Het brengt je dichter bij hoe de agent de wereld ziet, zonder je eigen oordeel te vervangen.

Waar agents de komende jaren beter in worden

Zhang sloot zijn talk af met drie dingen die hem bezighouden, en ze zijn het waard om in je achterhoofd te houden bij keuzes voor de komende jaren.

Het eerste is dat agents budgetbewust moeten worden. Bij een workflow weet je vooraf ongeveer wat een taak kost. Bij een agent heb je daar nu weinig grip op. Zodra je een agent een maximum aan tokens, tijd of euro's kunt meegeven, wordt hij veel beter inzetbaar in productie. Voor wie op kosten stuurt, is dat het verschil tussen een experiment en een betrouwbare post op de begroting.

Het tweede is dat agents hun eigen gereedschap gaan verbeteren. We gebruiken modellen nu al om tool-beschrijvingen aan te scherpen. De volgende stap is dat een agent zelf zijn tools bijschaaft voor de taak die voorligt. Dat maakt hem breder inzetbaar zonder dat jij voor elke nieuwe situatie iets hoeft te bouwen.

Het derde is samenwerking tussen meerdere agents. Aparte agents voor aparte deeltaken houden elkaars context schoon en laten zich goed parallel draaien. De open vraag is hoe die agents onderling communiceren, want onze systemen zijn nu gebouwd rond een strak ritme van vraag en antwoord tussen mens en model.

Wat deze drie delen: ze draaien allemaal om grip op een technologie die steeds zelfstandiger wordt. Precies de denkrichting die ook de keuze tussen workflow en agent stuurt. Wie vandaag leert om bewust te kiezen, staat sterker zodra deze mogelijkheden volwassen worden.

Vijf stappen voordat je iets laat bouwen

Wat betekent dit voor de keuzes die jij deze week maakt over AI-budget en projecten? Vijf concrete stappen.

Begin bij de taak, niet bij de technologie. Schrijf op welk proces je wilt verbeteren en teken de stappen uit. Lukt dat netjes, dan heb je je antwoord al: een workflow volstaat. Lukt het niet omdat het pad echt onvoorspelbaar is, dan komt een agent in beeld.

Leg de vier vragen langs elk voorstel. Krijg je een offerte of een intern plan voor "een AI-agent", check dan of de taak ambigu genoeg is, of de waarde de kosten dekt, of de kritieke stappen betrouwbaar zijn, en wat een fout kost. Wordt geen van die vier overtuigend beantwoord, dan bouw je waarschijnlijk te zwaar.

Reken de kosten per taak door. Vraag bij elk AI-project naar het verwachte tokenverbruik en de kosten per uitvoering. Een agent die per taak een veelvoud kost van een workflow, moet dat verschil ergens terugverdienen. Kan niemand uitleggen waar, dan is dat een signaal.

Begin klein en betrouwbaar, schaal daarna op. Bouw eerst de eenvoudige versie die werkt. Leadsignalen ophalen, een document samenvatten, een vraag routeren. Bewijs dat het klopt, en breid pas daarna uit. Dat is precies de volgorde die we klanten meegeven: waarde bewijzen in een afgebakend deel van het werk, en pas opschalen op basis van bewezen resultaat.

Test door de ogen van het systeem. Laat wie het bouwt een keer de hele taak doorlopen vanuit het perspectief van het model, met alleen de informatie die het model krijgt. Dat ongemakkelijke half uur legt feilloos bloot waar de context tekortschiet.

We schreven al vaker over wat autonome agents betekenen voor organisaties die grip willen houden. Bekijk alle artikelen over AI-agents in de kennisbank.

Hoe wij dit bij klantvragen toepassen

Wat ik in klantgesprekken het vaakst hoor, is een organisatie die "agent" zegt en "betrouwbare automatisering" bedoelt. Dat zijn twee verschillende dingen. Een agent is gereedschap. Het heeft een prijskaartje en een foutmarge. Voor het overgrote deel van wat onze klanten vragen, ophalen, samenvatten, routeren, opstellen, is een goed ontworpen workflow sneller live en makkelijker te vertrouwen.

We bouwen agents waar ze echt verschil maken. Maar mijn eerlijke boodschap aan de directietafel is simpel: het doel is betrouwbaarheid. Autonomie is hooguit een middel, en vaak niet eens nodig. Die betrouwbaarheid haal je vaker met de saaie oplossing dan met de slimme.

Die nuchterheid versnelt juist het resultaat. Kies ik met een klant de saaie oplossing waar het kan, dan houden we budget en aandacht over voor de paar plekken waar een agent het verschil maakt.

De vraag voor jouw organisatie

Loop de AI-projecten op je lijst eens langs met één vraag in je hoofd: hoeveel van deze plannen heten "agent" omdat de taak het vraagt, en hoeveel omdat agent nu eenmaal het woord van het moment is? Eerlijk antwoord geven kan je een hoop geld en frustratie besparen.

Wil je weten welke van jouw processen vragen om een agent en welke prima met een workflow werken? Plan een kennismaking in, we denken graag mee.