Van één naar meerdere AI agents: zo bepaal je of de stap loont

TL;DR: Voor de meeste MKB-use cases in 2026 is één goed gebouwde agent beter dan drie slecht gecoördineerde. Multi-agent wordt pas waardevol zodra je processen echt parallel kunnen lopen of zodra ze fundamenteel verschillende kennisdomeinen vragen. Hetzelfde geldt wanneer lange gesprekken bij hoog volume zoveel context opbouwen dat de kwaliteit van een enkel model begint te zakken. In dit artikel vind je het beslismodel waarmee je dat voor je eigen situatie bepaalt.

Je hebt een klantcontact-agent gebouwd die prima werkt voor standaardvragen. Zodra een gesprek over technische details gaat en er tegelijk een CRM-lookup en escalatie-routing nodig zijn, loopt hij vast. Het gevoel dat dan opkomt is herkenbaar: "ik heb twee of drie specialist-agents nodig." Soms klopt dat gevoel, maar vaker los je het op met een betere toolset en een strakkere prompt-architectuur binnen de agent die je al hebt, zonder extra orchestratie-overhead.

Wie zoekt op "multi-agent systemen MKB" vindt vrijwel uitsluitend hype-content en service pages van partijen die beweren dat multi-agent "de logische volgende stap" is na één agent. Dat beeld klopt niet. Multi-agent is een architectuurkeuze die je bewust maakt, en die keuze volgt zeker niet vanzelf uit het hebben van een eerste agent. De drempel ligt hoger dan die content suggereert en de kosten vallen in productie hoger uit dan de vendor-demo's laten zien.

Het besliskader hieronder is gebaseerd op de agents die ik zelf in productie draai, van content-agents tot een trading-agent. Het zegt wanneer een tweede of derde agent zinvol is en wanneer je er beter nog even mee wacht. Daarna rekenen we voor wat orchestratie-overhead je kost, want dat deel blijft in de meeste verkoopgesprekken buiten beeld.

Kort samengevat

• Voor de meeste MKB-use cases in 2026 is één goed gebouwde agent beter dan drie slecht gecoördineerde; multi-agent volgt niet vanzelf uit het hebben van een eerste agent.
• Een tweede of derde agent loont pas als de subtaken echt parallel kunnen lopen, als de kennisdomeinen fundamenteel verschillen, of als lange gesprekken bij hoog volume zoveel context opbouwen dat de kwaliteit van een enkel model zakt.
• Je krijgt er spijt van als de hele flow in 5-10 regels logica past, als je eerste agent nog geen drie maanden stabiel draait, of als je geen expliciete foutpropagatie hebt ontworpen.
• De overhead is reëel: hogere API-kosten, één tot drie seconden extra latency per agent-hop, fors langere debugging en verplichte distributed tracing. Reken die last door in een expliciete businesscase voordat je splitst.
• Bij klantcontact is een toolcall-aanpak binnen één agent vaak voldoende; splitsen wordt pas gerechtvaardigd als meer dan 30-40% van de gesprekken echt parallelle subtaken heeft.

Zo zit een multi-agent systeem in elkaar

Laat de theoretische definities even links liggen. Vanuit bouwperspectief werkt het zo: een orchestrator-agent ontvangt een taak, breekt die op in subtaken en delegeert elke subtaak aan een specialist-agent. Elke specialist heeft zijn eigen systeemprompt, toolset en kennisdomein. De orchestrator coördineert de uitvoering, integreert de output en geeft het eindresultaat terug aan de gebruiker.

Zo ziet dat eruit bij een klantcontact-agent:

Inkomend gesprek
      |
      v
[Orchestrator-agent]
   |           |           |
   v           v           v
[FAQ-agent] [CRM-opzoek-  [Escalatie-
             agent]        agent]
   |           |           |
   v           v           v
[Orchestrator integreert resultaten]
      |
      v
Klant krijgt antwoord

De orchestrator stuurt de vraag naar de juiste specialist, wacht op de resultaten en combineert die tot een coherent antwoord. Dat klinkt logisch, en het ís logisch als de situatie erom vraagt. Bedenk wel dat elke pijl in dit schema staat voor extra latency en extra API-kosten, en dat elke overdracht een plek is waar iets mis kan gaan. Die overhead weeg je af tegen wat de splitsing je oplevert, en die afweging werken we hieronder uit.

Drie voorwaarden waaronder multi-agent loont

Voorwaarde 1: parallellisme is mogelijk én aantoonbaar waardevol

Je agent rondt stap A af voordat hij aan stap B kan beginnen, terwijl A en B feitelijk niets met elkaar te maken hebben. Een single-agent werkt nu eenmaal altijd sequentieel. Multi-agent kan wel parallelliseren, en dat is het enige architectuurvoordeel dat de eindgebruiker direct merkt in de responstijd. Anthropic noemt zware parallellisatie dan ook als eerste van de taken waarin multi-agent systemen uitblinken, naast informatie die niet in één contextvenster past en het werken met veel complexe tools.

Neem een lead-research-agent die zowel LinkedIn-profieldata als concurrent-informatie ophaalt. Die twee opzoekingen hebben niets met elkaar te maken; ze kunnen tegelijk draaien. Bij een sales-team dat 50+ leads per dag verwerkt, is dat een tijdwinst die de orchestratie-overhead rechtvaardigt. Dit wordt pas zinvol als de tijdwinst van het parallel draaien blijvend groter is dan de latency van de extra agent-hop, dus niet alleen op een goede dag. In de agents die ik zelf draai kost elke agent-hop één tot drie seconden extra. De overdracht zelf is daarvan het kleinste deel: onderzoek naar latency-bewuste orchestratie meet een routing-overhead onder de 50 milliseconden, tegenover 2 tot 15 seconden voor elke modelaanroep. De specialist-agent doet een eigen modelaanroep, en die seconden tellen op.

Voorwaarde 2: kennisdomeinen zijn fundamenteel anders

Een agent die tegelijkertijd klantenservice, technische documentatie én juridische compliance moet afhandelen, wordt instabiel. Dat gebeurt zelden meteen. Naarmate de kennisbank groeit en de systeemprompt zwaarder wordt, neemt de kans op ongewenste interacties tussen domeinen toe. De agent gaat "lekken": juridische voorzichtigheid sijpelt door in klantgerichte communicatie, of technische nuance verdwijnt omdat de prompt te veel kanten op wijst.

Aparte agents met aparte systeemprompts en kennisbanken zijn in die situatie betrouwbaarder en makkelijker te onderhouden. De grens hangt daarbij minder af van het aantal onderwerpen dan van de vraag of de domeinen fundamenteel andere beslislogica, een andere toon of andere databronnen vereisen. Drie productonderwerpen in één agent werken prima. Combineer je klantenservice met compliance-advies en orderverwerking, dan heb je een serieuze kandidaat voor opsplitsing.

Voorwaarde 3: context rot bij lange gesprekken en hoog volume

Op een gegeven moment wordt de context van een single-agent een bottleneck. Het volume speelt daarbij mee, maar de gespreksduur weegt minstens zo zwaar. Bij de huidige modellen loopt het contextvenster tijdens een lang klantgesprek zelden echt vol; de vensters zijn daar te groot voor geworden. Wat wel gebeurt, is dat de kwaliteit daalt naarmate de context groeit. Naarmate het aantal tokens toeneemt, gaan nauwkeurigheid en recall achteruit; Anthropic noemt dat context rot. Chroma's onderzoek naar context rot laat over een reeks modellen hetzelfde zien: de kwaliteit zakt ruim voordat het venster vol is. Bij een klantcontact-agent die lange, complexe gesprekken voert met een rijke productcatalogus als kennisbank merk je dat direct: de agent "vergeet" vroegere context of gaat inconsistent antwoorden.

Dit treedt het eerst op bij lange gesprekken in combinatie met een grote kennisbank; korte gesprekken en compacte kennisbanken blijven doorgaans stabiel. Test dit daarom eerst met context-compressie en betere retrieval-strategieën, want een slechte retrieval-opzet is vaker de bottleneck dan de context zelf. Anthropic biedt hiervoor inmiddels server-side compaction, zodat je de compressie niet zelf hoeft te bouwen.

Drie situaties waarin je te vroeg gaat voor multi-agent

Situatie 1: de hele flow past in 5-10 regels logica

Als jouw "multi-agent systeem" bij nader inzien een vaste if-then-flow is met één AI-call erin, bouw je te vroeg. Een eenvoudige routeringslogica met toolcalls binnen één agent is sneller en goedkoper, en draait stabieler in productie. Meerdere agents zijn gerechtvaardigd als de beslislogica adaptief is en de uitkomst van agent A niet op voorhand te voorspellen valt. Is die uitkomst wel voorspelbaar, dan bouw je in feite een workflow en heeft een agent-architectuur je weinig extra's te bieden. Anthropic maakt in Building effective agents hetzelfde onderscheid tussen een workflow met vooraf gedefinieerde codepaden en een agent die zelf stuurt, en adviseert om de eenvoudigste oplossing te zoeken en complexiteit pas toe te voegen als het nodig is.

Situatie 2: je eerste agent is nog niet gestabiliseerd

Een multi-agent systeem bovenop een instabiele eerste agent zetten levert vooral nieuwe problemen op. Ik hanteer voor mijn eigen agents een minimum van drie maanden productie-stabiliteit voordat ik over uitbreiding nadenk. In die drie maanden leer je de randgevallen kennen en groeit je monitoring-setup mee naar een volwassen niveau. Je krijgt bovendien een duidelijk beeld van wat de agent wel en niet aankan. Zonder die basis weet je niet of de problemen die je wil oplossen met agent B, niet eigenlijk problemen zijn van agent A die je nog niet hebt opgelost. Lees Waarom je AI agent na 3 maanden verslechtert voor de onderhoudsproblemen die je eerst moet aanpakken.

Situatie 3: je hebt geen expliciete foutpropagatie ontworpen

Multi-agent debugging is veel lastiger dan single-agent debugging. Bij één agent zie je in de logs meestal exact wat misging; bij multi-agent zit de oorzaak van een fout vaak verborgen in de handoff tussen agents. Anthropic beschrijft hoe fouten in agentsystemen zich opstapelen: een kleine afwijking die in gewone software onschuldig is, kan een agent volledig van zijn pad brengen, en agents nemen tussen twee runs andere beslissingen, zelfs met identieke prompts. Cognition komt in Don't Build Multi-Agents tot dezelfde conclusie en noemt multi-agent-architecturen fragiel door contextverlies en conflicterende beslissingen tussen agents.

Een incident uit mijn eigen agents: een orchestrator stuurde een product-opzoekvraag door naar de CRM-agent. De CRM-agent gaf een lege array terug omdat de klant-ID niet overeenkwam met het verwachte formaat. De orchestrator interpreteerde de lege response als "geen CRM-data beschikbaar" en ging door, zonder foutmelding. De eindgebruiker kreeg een generiek antwoord, en dat gebeurde stilzwijgend, zonder log-entry die direct naar de oorzaak wees. Dit soort stille fouten duikt in multi-agent systemen steeds weer op. Voordat je dit verantwoord in productie brengt, heb je expliciete foutpropagatie en state management nodig, plus distributed tracing om een fout achteraf terug te kunnen vinden. Die investering staat los van de agent-logica zelf.

De werkelijke kosten van multi-agent

De meeste vendor-content toont de upside van multi-agent, zoals schaalbaarheid en de mogelijkheid om per kennisdomein een specialist in te richten die je los kunt verbeteren of vervangen. De downside zit in de operationele laag, en daarover hoor je in een verkoopgesprek zelden iets.

Kostenpost	Single-agent	Multi-agent (3 agents)	Verschil
API-kosten per gesprek (gpt-4o-mini basis)	€0,003-€0,008	€0,009-€0,025	Circa 3x hoger
Latency per respons	1,2-2,5 sec	2,8-5,5 sec	+1-3 sec per agent-hop
Debugging-tijd bij een onverwacht resultaat	15-30 min	45-120 min	3-4x hoger
Onderhoudsinspanning per maand (promptdrift, kennisbank-rot)	1 eenheid	3 eenheden	Lineair met agent-aantal
Benodigde monitoring-setup	Basis logging	Distributed tracing verplicht	Hogere setup-drempel

Eigen schattingen uit mijn productie-omgeving, gerekend met de publieke API-tarieven voor gpt-4o-mini van juli 2024: 15 dollarcent per miljoen input-tokens en 60 dollarcent per miljoen output-tokens. Dat model is inmiddels gedateerd; het gaat om de verhouding tussen de kolommen. Reken de tabel na met de actuele tarieven van je eigen provider, voor Claude via de prijzenpagina van Anthropic.

Reken het verschil na met de tabel. Aan de onderkant is dat 0,009 min 0,003 = 0,006 euro per gesprek, aan de bovenkant 0,025 min 0,008 = 0,017 euro per gesprek. Bij 1.000 gesprekken per week kom je dan uit op 6 tot 17 euro per week extra, en over 52 weken op ruwweg 300 tot 900 euro per jaar puur aan API-kosten. Dat bedrag alleen breekt geen enkele businesscase. Twee kanttekeningen horen erbij. De tabel rekent met een goedkoop model: Anthropic mat in zijn eigen research-systeem dat multi-agent ongeveer 15 keer zoveel tokens verbruikt als een chatinteractie, tegenover ongeveer 4 keer voor één agent, en op een duurder model tikt zo'n factor wel door. En de duurste posten in de tabel zijn de onderhoudsinspanning en de debugging-tijd, en die staan in uren. Tel die bij elkaar op, en multi-agent heeft alsnog een expliciete businesscase nodig om zichzelf terug te verdienen. Zie Terugverdientijd AI agent MKB voor de rekenmethode.

State management is een aparte bottleneck die vaak wordt onderschat. Iets moet bijhouden wat agent A al heeft uitgevoerd als agent B halverwege faalt. In de agent-architectuur van BeeManaged, het platform waarop mijn eigen agents draaien, los ik dit op via een central state store die elke agent-stap logt en idempotent maakt. Anthropic pakt het in Claude Managed Agents vergelijkbaar aan, met een append-only log van alles wat er gebeurd is, zodat een agent onderbroken, herstart of verplaatst kan worden zonder kwijt te raken wat hij al deed. Zonder zo'n log is een mislukte agent-run bij hoog volume niet hervatbaar, wat leidt tot dataverlies of dubbele verwerking. Het onderhoud verveelvoudigt ook. Met drie agents heb je drie kennisbanken die verouderen en drie prompts die langzaam gaan driften, en elke agent vraagt zijn eigen monitoring. Je kunt daar prima voor kiezen, zolang je het bewust doet en de extra last meeneemt in de businesscase.

Het beslismodel: kopieerbare matrix

Gebruik deze matrix als je de keuze moet maken. De matrix beschrijft acht situaties in vier kolommen.

Situatie	Single agent volstaat	Multi-agent zinvol	Reden
Eenvoudige FAQ-bot (max 50 onderwerpen)	Ja	Nee	Laag domein-volume, geen parallellisme nodig
Klantcontact met CRM-lookup + escalatiepad	Ja (via toolcalls)	Eventueel bij >5K gesprekken/week	Toolcalls zijn goedkoper dan agent-hops
Lead-research: LinkedIn-data + concurrent-analyse tegelijk ophalen	Nee	Ja	Parallellisme rechtvaardigt de split
Klantenservice + compliance-advies + orderverwerking in één agent	Nee	Ja	Fundamenteel verschillende kennisdomeinen en toon
Bulk-verwerking van 10K documenten per dag	Eerst testen	Ja als latency bewezen bottleneck is	Volumeschaling vereist meting, geen aanname
Vaste if-then-routing met één AI-call erin	Ja	Nee	Dit is workflow-logica, geen agent-architectuur
Twee teams beheren elk hun eigen kennisdomein onafhankelijk	Nee	Ja	Organisatorische grens is architectuurgrens
Eerste agent staat nog geen 3 maanden stabiel in productie	Ja	Nee	Stabiliseer eerst; multi-agent op wankele basis lost niets op

Die regel over twee teams sluit aan op de uitzonderingen die Microsoft in zijn Cloud Adoption Framework noemt: wie meteen met multi-agent begint, doet dat omdat het systeem security- en compliancegrenzen kruist, omdat er meerdere teams bij betrokken zijn, of omdat er duidelijke groei wordt verwacht.

Checklist voor de stap naar multi-agent

Kopieer deze checklist en gebruik hem bij elke architectuurkeuze:

Multi-agent readiness checklist
=================================

Groene lichten (alle drie nodig voor "go"):
[ ] Eerste agent is minimaal 3 maanden stabiel in productie
[ ] Er is een aantoonbare parallelle of fundamenteel domeingesplitste use-case
[ ] Distributed tracing en state management zijn geïmplementeerd of concreet gepland

Rode lichten (één "ja" = stop, eerst oplossen):
[ ] Het patroon past in 5-10 regels deterministische logica
[ ] Je loopt al achter op het onderhoud van je eerste agent
[ ] Er is geen expliciete foutpropagatie tussen agents ontworpen
[ ] De businesscase (extra API-kosten x volume x tijd) is niet doorgerekend

Oranje (verder onderzoek vereist):
[ ] Context rot vermoed maar niet gemeten
    -> test eerst retrieval-optimalisatie en context-compressie
[ ] Meerdere domeinen, maar hetzelfde team en dezelfde toon
    -> overweeg prompt-compartimentering binnen één agent
[ ] Parallellisme aantrekkelijk maar niet gemeten
    -> meet eerst latency-bottleneck in productie

Een doorgerekend scenario: splitsen of wachten

Onderstaand scenario is illustratief. Stel dat een klantcontact-agent voor een maakbedrijf richting 1.000+ gesprekken per week groeit. Dan komt de vraag op tafel of je moet splitsen in meerdere specialist-agents.

De use-case bestaat uit klantvragen die soms vragen om (a) productinformatie ophalen, (b) openstaande ordergegevens opvragen uit het ERP en (c) bij complexe vragen doorsturen naar een medewerker. Dat zijn drie taken, en dus zou je in het schema drie agents kunnen tekenen. De uitkomst van zo'n analyse is alleen vaak dat je beter nog even kunt wachten. Daar zijn drie redenen voor.

Ten eerste zijn de drie taken niet echt parallel. In dit scenario heeft 70% van de gesprekken maar één van de drie nodig, 25% twee, en slechts 5% raakt alle drie tegelijk aan. Dat rechtvaardigt geen permanente orchestratie-overhead voor 95% van het volume.

Ten tweede is een toolcall-aanpak binnen één agent vaak voldoende. Geef de agent drie tools (product-lookup, ERP-query, escalatie-webhook) met duidelijke instructies wanneer welke tool te gebruiken, en meet daarna of de kwaliteit stabiel blijft.

Ten derde weegt de debugging-last mee. Een architectuursplit vraagt een distributed tracing-setup waarvan de implementatie al snel meer tijd kost dan de verwachte winst in de eerstvolgende zes maanden.

Mijn vuistregel na deze evaluatie is dat de switch naar multi-agent pas gerechtvaardigd is als meer dan 30-40% van de gesprekken daadwerkelijk parallelle subtaken heeft die niet oplosbaar zijn via toolcalls binnen één agent. Voor de meeste MKB-klantcontact-use-cases in 2026 ligt dat percentage lager dan de hype doet vermoeden. Dit sluit aan op het advies in het Cloud Adoption Framework van Microsoft: begin met één agent en een prototype, en stap pas over naar multi-agent als aantoonbare beperkingen een architecturale scheiding verplichten.

Er bestaat ook een tegenhanger. Voor een lead-enrichment-workflow die LinkedIn-data, KvK-data én een eerste AI-kwalificatie tegelijk ophaalt, is multi-agent wél het juiste antwoord. Daar zijn de opzoekingen echt parallel en onafhankelijk van elkaar, en bij voldoende volume verdient de overhead zichzelf terug, mits distributed tracing vanaf het begin is ingericht. De keuze hangt dus af van de meetbare eigenschappen van de flow, en veel minder van het type use-case.

Veelgestelde vragen over multi-agent systemen

Wat is een multi-agent systeem precies?

Een orchestrator-agent ontvangt een taak, breekt die op in subtaken en delegeert elke subtaak aan een specialist-agent met een eigen systeemprompt, toolset en kennisdomein. De orchestrator coördineert de uitvoering, integreert de output en geeft het eindresultaat terug aan de gebruiker. Elke overdracht tussen agents kost extra latency en extra API-kosten en is een plek waar iets mis kan gaan.

Wanneer is een tweede of derde agent zinvol?

In drie gevallen: als subtaken echt parallel kunnen lopen en die tijdwinst blijvend groter is dan de extra agent-hop, als de kennisdomeinen fundamenteel andere beslislogica, toon of databronnen vragen, of als lange gesprekken bij hoog volume zoveel context opbouwen dat de kwaliteit van een enkel model zakt. Komt geen van die drie voor, dan is één goed gebouwde agent doorgaans de betere keuze.

Wanneer ga ik te vroeg over op multi-agent?

Als je hele flow in 5-10 regels deterministische logica past, bouw je in feite een workflow en geen agent-architectuur. Ook als je eerste agent nog geen drie maanden stabiel in productie draait, of als je geen expliciete foutpropagatie tussen agents hebt ontworpen, ga je te vroeg. In die gevallen los je met een tweede agent vooral problemen op die in de eerste agent thuishoren.

Is multi-agent altijd beter dan één agent?

Nee. Voor de meeste MKB-use cases in 2026 is één goed gebouwde agent beter dan drie slecht gecoördineerde. Multi-agent volgt niet vanzelf uit het hebben van een eerste agent; het is een bewuste architectuurkeuze die je alleen maakt als aantoonbare beperkingen een scheiding verplichten. Vaak kom je verder met een betere toolset en een scherpere prompt-architectuur binnen de agent die je al hebt.

Wat kost multi-agent extra ten opzichte van één agent?

De API-kosten per gesprek lopen op, elke agent-hop voegt één tot drie seconden latency toe, debugging duurt fors langer en distributed tracing wordt verplicht. Bij 1.000 gesprekken per week komt het verschil uit de kostentabel neer op 6 tot 17 euro per week extra, ruwweg 300 tot 900 euro per jaar aan API-kosten op een goedkoop model. De grotere kostenpost zit in de onderhoudsinspanning en de debugging-tijd, en daardoor heeft multi-agent een expliciete businesscase nodig om zichzelf terug te verdienen.

Helpt een extra agent tegen context rot?

Misschien, maar test dat eerst. Context rot, het kwaliteitsverlies dat optreedt naarmate de context groeit, treedt het eerst op bij lange gesprekken in combinatie met een grote kennisbank. Een slechte retrieval-opzet is vaker de bottleneck dan de context zelf, dus test eerst context-compressie en betere retrieval-strategieën voordat je een agent toevoegt.

---

Verwante entries in dit cluster

• Microsoft Copilot of maatwerk AI-agent? Keuzegids voor het MKB: de architectuurkeuze vóórdat je naar multi-agent kijkt
• Waarom je AI agent na 3 maanden verslechtert: onderhoudsproblemen oplossen voordat je uitbreidt

Wil je dit beslismodel op je eigen agent toepassen, dan kun je de matrix samen doorlopen via AI consultancy vanuit eigen praktijk.

Bronnen

• Choosing Between Building a Single-Agent System or Multi-Agent System, Microsoft Cloud Adoption Framework, 1 december 2025
• How we built our multi-agent research system, Anthropic Engineering, 13 juni 2025
• Building effective agents, Anthropic, 19 december 2024
• Don't Build Multi-Agents, Cognition, 2025
• Context windows, Claude Platform Docs, geraadpleegd 24 september 2026
• Context Rot, Chroma, 2025
• Learning Latency-Aware Orchestration for Multi-Agent Systems, arXiv 2601.10560, januari 2026
• GPT-4o mini: advancing cost-efficient intelligence, OpenAI, 18 juli 2024
• Pricing, Claude Platform Docs
• Scaling Managed Agents: Decoupling the brain from the hands, Anthropic Engineering, 8 april 2026