Wanneer kies je voor multi-agent systemen en wanneer voor single-agent: het beslissingskader

Gartner: 40% van de agentic AI-projecten wordt eind 2027 geannuleerd. Een belangrijke oorzaak — architecturale mismatch. Teams kozen voor multi-agent terwijl een goed afgestemde single agent de klus had kunnen klaren. Ze investeerden zes maanden en $800.000 in infrastructuur voor een probleem dat dat niet vereiste.

Keerzijde is net zo duur. Teams kozen voor single-agent bij complexe, multi-source synthese-taken die distributed reasoning vereisten. Ze besteedden een jaar aan het itereren op prompts en retrieval en haalden nooit de kwaliteitsdrempel, simpelweg omdat de architectuur niet kon ondersteunen wat ze vroegen.

Dit is het beslissingskader dat je helpt om correct te kiezen voordat je je vastlegt.

Het Architecturale Verschil in Één Zin

Single agent: één reasoning chain van input naar output, met tools gekoppeld.

Multi-agent: een orchestrator agent die een taak decomposeert en sub-tasks verdeelt over specialist agents, waarna de outputs worden gesynthetiseerd tot een definitieve reactie.

Dat verschil — één reasoning chain versus een decomposition-synthesis loop — is de as waar vrijwel elke beslissing om draait.

De Ware Kosten van Multi-Agent

Voordat we bij het beslissingskader komen, moet de kostenkant helder zijn. Multi-agent is geen gratis upgrade van single agent. Het voegt toe:

Token-overhead per agent: elke agent in een multi-agent systeem heeft zijn eigen context nodig — instructies, system prompt, relevante data. Voeg drie agents toe en je betaalt voor drie context loads per query. Onderzoek uit agentic AI productiedeployments: multi-agent systemen kunnen tot 15x meer tokens verbruiken dan single agent voor equivalente taken.

Coördinatielatentie: wanneer één agent afhankelijk is van de output van een andere agent, tel je de tijd van die handover op. In een twee-agent systeem is dit behapbaar. In een vijf-agent orchestratie met parallelle en seriële afhankelijkheden, stapelt de latentie zich op.

Debugging-complexiteit: een single-agent trace is lineair. Je kunt de reasoning chain van input naar output lezen. Een multi-agent trace is een graaf — agent A riep agent B aan, die agent C aanriep parallel aan agent D, wiens outputs werden gevoed naar agent E. Als er iets misgaat, is de vraag niet wat er gebeurde. Het is welke agent er fout was, en of de fout lag in de reasoning van die agent of in de instructie die hij ontving van de orchestrator.

API-kosten vermenigvuldiging: gecontroleerde experimenten in productie agentic systemen tonen een 3.7x toename in API-kosten voor multi-agent versus single agent op vergelijkbare taaktypes. Niet 3.7% — 3.7x. Dit getal is relevant wanneer je een product beprijst.

Wanneer Single-Agent de Juiste Keuze Is

Single-agent architectuur is correct — en vaak onderschat — wanneer:

De workflow lineair is: de taak gaat van input naar een enkele reasoning chain naar output. Er is geen betekenisvolle vertakking, geen parallelle sub-taken, geen specialistische kennisgebieden nodig. Een klantenserviceagent die uit een knowledge base ophaalt en een reactie genereert, is een single-agent probleem. De reasoning is sequentieel: begrijpen, ophalen, synthetiseren, reageren.

Sterke identifiers beschikbaar zijn: de agent moet entiteiten en intents betrouwbaar identificeren uit de input. Wanneer sterke identifiers bestaan — specifieke productnamen, duidelijke intent-categorieën, goed gestructureerde data — handelt een single agent met goede prompting deze consistent af.

De chaos-factor laag is: de inputvariatie is begrensd. De agent komt niet onvoorspelbare combinaties van vereisten tegen die verschillende reasoningbenaderingen vereisen. Een single agent, getraind voor één domein, presteert beter dan een multi-agent systeem dat meerdere domeinen moet afhandelen.

De AI engineering-capaciteit beperkt is: multi-agent systemen vereisen doorlopend orchestratie-onderhoud. Als je team uit twee engineers bestaat en één van hen is de enige die het agentic framework begrijpt, is single-agent de juiste keuze. Het beste multi-agent systeem, gebouwd door een team dat het niet kan onderhouden, faalt in productie.

De context in de context window past: single-agent schittert wanneer alle relevante context — de input, opgehaalde kennis, conversatiegeschiedenis, output-format-instructies — in de context window van het model past. Wanneer dat niet het geval is, is dat vaak een retrieval-probleem, geen multi-agent probleem.

Het anti-pattern: teams voegen agents toe omdat het voelt als geavanceerder. De eigenlijke taak — genereer een reactie uit een knowledge base, classificeer een e-mail, extraheer gestructureerde data uit een document — was een single-agent probleem dat ze hebben over-architectured.

Wanneer Multi-Agent Gerechtvaardigd Is

Multi-agent architectuur verdient zijn kosten wanneer:

De taak echte multi-domein expertise vereist: de input vereist reasoning uit fundamenteel verschillende kennisgebieden die een enkele context zouden overbelasten. Een juridisch-financiële onderzoekstaak heeft een juridische reasoning agent en een financiële analyse agent nodig — niet één agent die probeert beide te zijn.

Parallelle verwerking echter helpt: meerdere onafhankelijke sub-taken kunnen gelijktijdig draaien en hun outputs moeten worden gesynthetiseerd. De latentiereductie door parallelle executie weegt op tegen de coördinatie-overhead. Voorbeeld: drie agents die gelijktijdig verschillende databases doorzoeken voor een comprehensive due diligence report.

Fault tolerance een harde vereiste is: als één agent faalt, moet het systeem graceful degraderen in plaats van volledig falen. Een multi-agent systeem waar elke agent onafhankelijk kan herstellen, of waar een supervisor agent taken kan omleiden, handelt failure beter af dan een single point of failure.

De kwaliteitskloof aangetoond is: na het bouwen en optimaliseren van een single-agent baseline, ligt de outputkwaliteit op complexe taken meetbaar onder de kwaliteitsdrempel. De kloof is geen prompt engineering-probleem — het is een reasoning capacity-probleem dat een specialist agent kan oplossen.

De coördinatielogica het product is: wanneer hoe taken worden gedecomposeerd en gesynthetiseerd zelf een concurrentievoordeel is — routing, prioritering, specialist selectie — is multi-agent architectuur de juiste fundering omdat die logica is wat je bouwt.

Het anti-pattern: teams kiezen multi-agent omdat het geavanceerder klinkt. De eigenlijke taak was haalbaar met een goed gepromptte single agent, en de multi-agent infrastructuur is overhead die iteratiesnelheid vertraagt zonder kwaliteitsvoordeel.

Het Beslissingsdiagnosticum — 5 Vragen

Pas dit toe voordat je je vastlegt aan multi-agent:

Vraag 1: Is de input-complexiteit begrensd of onbegrensd?

Als begrensd — de input komt in bekende categorieën met voorspelbare structuur — is single-agent waarschijnlijk voldoende. Als de inputvariatie open-ended is en verschillende reasoningbenaderingen vereist afhankelijk van wat de input bevat, kan multi-agent gerechtvaardigd zijn.

Vraag 2: Kan één prompt de kwaliteitsdrempel halen?

Schrijf de prompt. Test hem op 50 echte voorbeelden. Als de outputs consistent onder de kwaliteitsdrempel liggen en de failure modes reasoning-fouten zijn die een betere prompt niet kan oplossen, heb je een capacity-probleem — wat multi-agent kan adresseren. Als de failures retrieval-fouten of format-fouten zijn, zijn die oplosbaar binnen single-agent architectuur.

Vraag 3: Wat is het tokenbudget voor deze taak?

Als de taak meer context vereist dan de effectieve context window van je model betrouwbaar aankan, heb je een compressie- of retrieval-probleem, geen architectuurprobleem. Fix de retrieval eerst. Als de context legitiem te groot is omdat het meerdere domeinen omvat, is dat een signaal voor multi-agent.

Vraag 4: Speelt latentie een rol bij deze taak?

Als dit een synchrone, gebruikersgerichte taak is waar 3-5 seconden latentie acceptabel is, is single-agent waarschijnlijk prima. Als je sub-second responses nodig hebt of als de taak asynchroon kan draaien, verandert de latentievergelijking.

Vraag 5: Wat gebeurt er als er iets misgaat?

In een single-agent systeem: je leest de trace, vindt de fout, fix de prompt of retrieval. In een multi-agent systeem: je leest de orchestratiegraaf, identificeert welke agent faalde, bepaalt of de failure in de reasoning van die agent lag of in de instructie die hij ontving, en fix dan of de agent of de routinglogica. Het debugging-oppervlak is groter.

Als je niet de observability tooling hebt om een multi-agent systeem te debuggen — en de meeste teams bouwen dit niet voordat ze het nodig hebben — is single-agent de juiste keuze.

De Microsoft AI Agent Decision Tree

Het Azure CAT-team van Microsoft publiceerde een decision tree voor AI agent architectuur. De ruggengraat ervan is:

Kan één model call dit afhandelen? → Ja → Single agent
Vereist de taak meerdere specialistische kennisgebieden? → Ja → Multi-agent
Vereist de taak parallelle executie om redenen van latentie of throughput? → Ja → Multi-agent
Vereist de taak fault tolerance voorbij retry-logica? → Ja → Multi-agent
Anders → Single agent met betere prompting en retrieval

De laatste tak is degene die teams het vaakst overslaan. Ze grijpen naar multi-agent voordat ze het single-agent optimalisatiepad hebben uitgeput. Het Microsoft-framework identificeert correct dat multi-agent het antwoord is op specifieke, geïdentificeerde problemen — niet een default architectuur.

De Anti-Patterns om te Vermijden

Anti-pattern 1: Multi-agent omdat het geavanceerder klinkt

Dit is de architecturale equivalent van enterprise software kopen omdat het serieuzer klinkt dan de startup-versie. De multi-agent infrastructuur die je bouwt, zal je iteratiesnelheid beperken. Als de taak het niet vereiste, heb je complexiteit toegevoegd zonder voordeel.

Anti-pattern 2: Single-agent voor echte complexe synthesetaken

Een single agent die tegelijkertijd moet reasonen over juridisch risico, financiële impact en operationele haalbaarheid, presteert onder ten opzichte van een systeem met specialist agents voor elk domein. Het prompt engineering-pad om een single agent alle drie goed te laten doen, is langer dan het multi-agent pad. Meet de kloof voordat je beslist.

Anti-pattern 3: De tokenkostenvergelijking negeren

Multi-agent tegen 3.7x de tokenkosten van single-agent is geen probleem wanneer de multi-agent output aantoonbaar beter is. Het is wel een probleem wanneer de outputs equivalent zijn en je koos voor multi-agent omdat het geavanceerder leek.

Praktische Vervolgstappen

Begin met een single-agent baseline: bouw de eenvoudigst mogelijke single-agent versie van wat je probeert te doen. Gebruik goede prompting, goede retrieval en een goed gestructureerde system prompt. Deze baseline is je referentiepunt.

Meet de kloof: run de baseline tegen echte productie-inputs. Meet outputkwaliteit met een rubric, niet met een gevoel. Als de kwaliteit consistent onder de drempel ligt, identificeer de specifieke failure modes.

Pas het diagnosticum toe: voor elke failure mode, vraag je af of het een prompting-probleem, een retrieval-probleem, een context window-probleem of een reasoning capacity-probleem is. Prompting- en retrieval-problemen zijn oplosbaar in single-agent. Reasoning capacity-problemen — wanneer het model meerdere dingen moet doen die moeilijk te combineren zijn in één prompt — zijn het signaal voor multi-agent.

Bouw multi-agent alleen wanneer de kloof aangetoond is en het diagnosticum ernaar wijst: niet eerder.

De projecten die falen, zijn degene die beginnen met multi-agent omdat het goed klinkt en dan zes maanden proberen de architectuur te laten werken. De projecten die slagen, beginnen met single-agent, meten eerlijk en voegen agents alleen toe wanneer het specifieke probleem het vereist.

Boek een gratis 15-min gesprek: https://calendly.com/agentcorps

Gerelateerd: Multi-Agent AI Systems · Top Multi-Agent AI Frameworks 2026 · AI Agent Onboarding