Iedereen wil een autonome agent. Vaak is het juiste antwoord een saaie workflow.

1. Waarom nu: de architectuurvraag

Elk AI-systeem heeft een vorm. Aan het ene uiterste liggen de stappen vast in code en wordt het model op vaste punten aangeroepen. Aan het andere runt het model de show, en beslist het elke zet gaandeweg. Kiezen daartussen, en tussen alles ertussenin, is de architectuurvraag, en die bepaalt meer over kosten en betrouwbaarheid dan het model doet.

De reden om nu precies te zijn is dat de woordenschat eindelijk bestaat. Anthropics "Building Effective Agents", gepubliceerd eind 2024, gaf het veld heldere namen, workflows en agents, en vijf patronen, en die namen zijn de manier geworden waarop serieuze teams over ontwerp praten. Dit dossier gebruikt die woordenschat om door de echte afweging van 2026 te lopen: de trek naar autonome, multi-agent-systemen die krachtig, indrukwekkend en stilletjes heel duur zijn. Krijg de vorm goed en een bescheiden model doet de klus goedkoop; krijg het fout en een duur team agents verbrandt budget om te doen wat een simpel recept voor een fractie van de kosten had gedaan.

2. Workflow of agent

Begin bij de tweesprong.

Een workflow is een systeem waarin de stappen vooraf vastliggen, in code. De runtime voert een script uit dat jij schreef, en roept het model op vaste punten aan. Het is voorspelbaar, goedkoper, en makkelijk te debuggen, en het is de juiste keuze wanneer je de stappen vooraf kent. Een agent is een systeem waarin het model beslist wat het vervolgens doet, beurt voor beurt, en zijn eigen tools en pad kiest. Het is flexibel en krachtig en moeilijker te voorspellen, en het is de juiste keuze wanneer de stappen echt niet vooraf te kennen zijn. Neem één taak en bouw hem op beide manieren om het verschil te voelen:

De fout die bijna iedereen maakt is grijpen naar de agent waar een workflow simpeler, goedkoper en betrouwbaarder was geweest. "Autonoom" klinkt geavanceerd; "een script met vijf stappen" klinkt saai. In productie wint de saaie vaak.

3. De vijf patronen, met echte taken

Tussen die twee polen benoemde Anthropic vijf patronen die, in de praktijk, bijna alles dekken wat je zult bouwen. Ze zijn het makkelijkst te leren gekoppeld aan een echte taak elk.

Lees de rechterkolom en elk patroon houdt op abstract te zijn. Prompt chaining vermindert fouten door elke aanroep minder te laten doen. Routing zet de juiste specialist op elke klus. Parallelization koopt snelheid en breedte. Orchestrator-workers is het patroon achter de meeste indrukwekkende multi-agent-systemen, een lead die een team aanstuurt. En evaluator-optimizer is de loop uit deel één expliciet gemaakt, een generator en een criticus die werk heen en weer geven. Vijf vormen, en je hebt zelden iets exotischers nodig dan een combinatie hiervan.

4. De patronen componeren

De reden dat vijf patronen zo ver komen is dat ze componeren. Het zijn geen vijf aparte architecturen om tussen te kiezen; het zijn bouwstenen die in elkaar nesten. Een routing-stap voedt vaak een prompt chain. Een orchestrator die aan workers delegeert wikkelt vaak een evaluator-optimizer-loop bij elke worker, zodat elke worker zijn eigen output checkt voordat hij terugrapporteert. Een parallelization-stap kan in elk van de anderen zitten. Echte systemen zijn meestal twee of drie van deze patronen op elkaar gestapeld.

Neem een content-pijplijn als klein gecomponeerd voorbeeld. Routing beslist of een inkomend verzoek een blogpost, een productbeschrijving of een advertentie is. Als het een advertentie is, splitst een orchestrator hem in een kop, body en call-to-action, geeft elk aan een worker, en elke worker draait een evaluator-optimizer-loop, concept, kritiek, herschrijven, tot zijn stuk slaagt. Die ene pijplijn is drie patronen genest, en geen ervan is exotisch. Daarom doet de woordenschat er meer toe dan welk enkel diagram ook: zodra je de stukken kunt benoemen, kun je elk AI-systeem beschrijven als een combinatie ervan, en kun je naar een systeem kijken dat niet werkt en vragen welk stuk het probleem is. Bijna elke over-geëngineerde agent is een geval van een zwaarder patroon gebruiken waar een lichter, of een gewone workflow, de klus had geklaard.

5. Multi-agent: de kracht en de prijs

Het meest besproken patroon is orchestrator-workers tot zijn uiterste gedreven: een lead-agent die een heel team subagents aanstuurt, elk parallel werkend. Het is werkelijk krachtig, en het loont om precies te zijn over zowel de kracht als de prijs.

Anthropic rapporteerde dat een multi-agent-opzet, een lead-model dat subagents aanstuurt, een enkele agent op zijn interne research-taak met ongeveer negentig procent versloeg. Dat is een grote winst. Het kwam ook met een prijs, en de prijs is het best te zien als simpele rekenkunde:

Die laatste regel is de hele beslissing. Multi-agent verbrandt ruwweg vijftien keer de tokens van een simpele chat, en tokengebruik alleen verklaarde ongeveer tachtig procent van het prestatieverschil, wat een andere manier is om te zeggen dat het meeste wat je met multi-agent koopt simpelweg meer denken is, parallel, tegen een prijs. Voor een hoogwaardige research-vraag is vijftien keer de kosten voor een negentig-procent-beter antwoord een koopje. Voor een routinematige opzoekactie is het verspilling. Het patroon loont wanneer de waarde van de taak de kosten van de tokens overstijgt, en niet eerder.

6. Wanneer uitwaaieren

Dus wanneer is een team agents werkelijk de juiste zet? Het eerlijke antwoord is smaller dan de hype suggereert.

Uitwaaieren werkt wanneer de taak werkelijk in onafhankelijke delen splitst, wanneer breedte meer telt dan één diepe redeneerlijn, en wanneer de taak waardevol genoeg is om de tokenrekening te rechtvaardigen: research, brede zoektochten, uit veel bronnen tegelijk verzamelen. Het werkt slecht wanneer elke agent dezelfde gedeelde context nodig heeft, wanneer stappen strak van elkaar afhangen, of wanneer de taak laagwaardig of latency-gevoelig is. Anthropics eigen noot is veelzeggend: het meeste programmeren past slecht bij multi-agent, omdat programmeer-stappen strak gekoppeld zijn, elke wijziging hangt van de vorige af, dus het werk splitsen over agents die elkaars wijzigingen niet zien schept chaos. Research past goed omdat het vanzelf splitst: drie subagents kunnen elk een andere concurrent onderzoeken zonder elkaar in de weg te zitten. Vraag vóór het uitwaaieren twee dingen: paralleliseert dit werkelijk, en is het de kosten waard? Veel taken zijn geen van beide, en een enkele agent of een gewone workflow is het juiste antwoord.

7. Een echt systeem: hoe een bank het bedraadde

Het helpt om de patronen samengesteld in het wild te zien. JP Morgans investment-research-team beschreef hun interne systeem, "Ask David", en het is een leerboek-compositie van de ideeën in deze serie.

Lees van boven: een supervisor-agent orkestreert het werk; gespecialiseerde subagents doen elk één klus, retrieval, gestructureerde data, analytics; voordat een antwoord verzendt, controleert een reflectiestap, een LLM die als beoordelaar optreedt, het; en een mens blijft in de lus voor het laatste stuk nauwkeurigheid dat de machine alleen niet kan garanderen. Dat is orchestrator-workers, plus evaluator-optimizer, plus een menselijke gate, vier van de ideeën in deze serie samengesteld in één systeem. Het is ook de vorm die blijft opduiken over serieuze deployments: een lead die plant, specialisten die uitvoeren, een beoordelaar die controleert, en een persoon die de eindbeslissing bezit. Als je de woordenschat kent, zie je hetzelfde skelet onder de meeste productie-agents, en kun je het kopiëren.

8. Begin simpel

Dit alles wijst naar de belangrijkste discipline in dit gebied, en het is degene die de meeste teams negeren: begin simpel.

Het instinct is te beginnen met de meest autonome, meest indrukwekkende optie, een vrij rondlopende agent met veel tools, omdat het goed demot. In productie is dat waar onvoorspelbaarheid en kosten wonen. Anthropics eigen advies loopt de andere kant op: begin met een enkele aanroep of een vaste workflow, en voeg autonomie alleen toe waar het aantoonbaar de uitkomst verbetert. In de praktijk ziet dat eruit als een ladder. Probeer eerst een enkele prompt. Als de taak een paar betrouwbare stappen nodig heeft, gebruik een workflow. Als het moet reageren op wat het vindt, geef het een agent. Als het werk werkelijk splitst en de kosten waard is, grijp dan pas naar een team. Elke sport omhoog koopt flexibiliteit en kost geld en voorspelbaarheid, dus je klimt alleen zo ver als de taak werkelijk vereist. Complexiteit is een kost die je bij elke run betaalt, geen badge die je verdient door iets geraffineerds te bouwen.

9. Wie kiest, jij of het model

Er is een wending het waard om te benoemen, want ze verandert hoe dit in de praktijk uitpakt. Steeds vaker kiest het model het patroon zelf. Gegeven een taak en de juiste tools, beslist een capabel model of het direct antwoordt, subagents opstart, of een verificatie-loop draait, en het combineert ze vaak midden in een taak zonder dat het gezegd wordt. Ethan Mollick maakte dit punt over de nieuwste agent-team-features: veel van de beslissing over welke aanpak te gebruiken wordt nu door de AI gemaakt in plaats van door de mens.

Dat maakt de woordenschat niet overbodig; het maakt hem nuttiger. Als het model kiest tussen deze patronen, dan is ze begrijpen hoe je zijn keuzes overziet. Je kunt een transcript bekijken en zien dat het vijf subagents opstartte voor een vraag die één opzoekactie had beantwoord, en het intomen. Je kunt de guardrails zetten, budgetplafonds, scope-limieten, een regel die zegt "waaier niet uit tenzij de taak deze lat haalt", die zijn autonomie economisch houden. Je gaat van de orkestratie met de hand schrijven naar een orkestratie besturen die het model draait, en je kunt niet besturen wat je niet kunt benoemen.

10. Het eerlijke tegengeluid

Drie kanttekeningen houden dit eerlijk. Ten eerste: de workflow-versus-agent-lijn vervaagt: naarmate modellen beter worden in plannen, kan het betrouwbare, voorspelbare gedrag waarvoor je ooit een handgeschreven workflow nodig had steeds meer aan een agent worden toevertrouwd, dus de balans verschuift over tijd naar autonomie. Wat vandaag over-engineering is kan volgend jaar verstandig zijn. Ten tweede: de tokenkost-cijfers zijn richtinggevend, geen wetten: ze komen uit specifieke taken, en de economie verandert elke keer dat modellen goedkoper worden, wat ze blijven doen, dus een multi-agent-ontwerp dat vandaag onrendabel is kan het waard worden naarmate prijzen dalen.

Ten derde: simpel is een richtlijn, geen dogma. Sommige werkelijk complexe, waardevolle, paralleliseerbare problemen hebben wél een team agents nodig, en er een weigeren uit minimalisme is zijn eigen fout; de research-vraag die een enkele agent met negentig procent verslaat is echt. De rode draad overleeft alle drie: de juiste architectuur is de simpelste die de klus betrouwbaar doet, en de kost van complexiteit is echt en het tellen waard. Grijp naar autonomie en multi-agent wanneer de taak ze verdient, en niet omdat ze het indrukwekkende ding zijn om te bouwen.

11. Wat een bedrijf hiermee doet

Voor een leider is dit een lens om elk AI-voorstel te lezen dat op je bureau belandt. Als iemand een ambitieus multi-agent-systeem pitcht, zijn de vragen nu concreet, en je hoeft niet technisch te zijn om ze te stellen. Kan dit ook een simpele workflow zijn? Paralleliseert de taak werkelijk, of wordt hij uitgewaaierd omdat dat geavanceerd klinkt? Is er een beoordelaar-stap en een menselijke gate, zoals in het banksysteem? En heeft iemand de tokenkost tegen de waarde van de taak afgewogen? Die vragen scheiden een systeem dat werkt en loont van een dat imponeert in een demo en geld bloedt in productie.

Dit is See, Understand, Adopt toegepast op hoe AI-werk is gerangschikt. Zie of een gegeven systeem een workflow of een agent is, en uit welke van de vijf patronen het bestaat. Begrijp dat autonomie en multi-agent krachtig en duur zijn, en dat de discipline is om simpel te beginnen en de ladder alleen zo ver te beklimmen als de taak vereist. Adopteer dan door de architectuur op de taak af te stemmen, en complexiteit alleen te kopen waar de waarde duidelijk aanwezig is. De teams die winnen draaien de minste agents die de klus doen, niet de meeste.

12. Verificatie en bronnen

Dit dossier steunt op live webonderzoek en een persoonlijk archief van meer dan 15.000 bronnen. Dragende cijfers zijn waar mogelijk dubbel gecheckt. De patroon-voorbeelden, de token-rekenkunde en het Ask David-diagram zijn illustratief, gebouwd om de mechaniek uit te leggen. De noten hieronder markeren vertrouwen en de belangrijkste kanttekeningen, in de geest van ons werk laten zien.

Grafieken met "BFF" zijn van onszelf, getekend uit de eronder genoemde bronnen. De patroon-taak-tabel, het token-voorbeeld en het Ask David-diagram zijn illustratief, geschreven om het idee te leren. De grafieklabels zijn in het Engels gehouden zodat termen één op één met de bronnen te vergelijken zijn.