Multi-agentsystemen: wanneer meerdere agents beter zijn dan één

Eén agent, meerdere agents: waar hebben we het over

Een autonome AI-agent draait alleen, met zijn eigen tools, geheugen en doel. Een multi-agentsysteem zet daarentegen meerdere agents aan het werk op dezelfde taak, elk met een precieze rol. Het idee is niet nieuw in gedistribueerde informatica, maar krijgt een concrete invulling sinds taalmodellen tools kunnen gebruiken en stappen kunnen aaneenschakelen zonder constant toezicht.

De term dekt verschillende realiteiten. Er is het systeem "orkestrator plus subagents", waarbij een hoofdagent het werk verdeelt en stukken delegeert aan meer gespecialiseerde agents. Er zijn ook peer-agents, die onderling communiceren om resultaten te delen zonder strikte hiërarchie. De nuance om te onthouden: "meerdere agents" betekent niet "meerdere identieke instanties die parallel hetzelfde doen", elke agent heeft een eigen reikwijdte. De woordenlijst van Atako werkt dit onderscheid verder uit.

Het principe van orkestratie

Wat een echt multi-agentsysteem onderscheidt van een simpele batch scripts die parallel draaien, is orkestratie: de logica die bepaalt wie wat doet, in welke volgorde, en hoe de resultaten weer worden samengevoegd. Anthropic heeft de architectuur die het gebruikt voor zijn deep research-functie tot in detail gedocumenteerd: een "lead"-agent analyseert de vraag, bepaalt een strategie, en maakt vervolgens subagents aan die elk parallel een spoor verkennen voordat hun resultaten worden samengebracht (bron: Anthropic, "How we built our multi-agent research system", https://www.anthropic.com/engineering/multi-agent-research-system, geraadpleegd op 2026-09-04).

Dit orkestrator-werker-model komt terug in vrijwel alle serieuze implementaties. De hoofdagent doet het werk niet zelf: hij plant, verdeelt, controleert en voegt samen. Dat is wat men agentorkestratie noemt. De subagent zelf is bedoeld om kort en wegwerpbaar te zijn: hij bestaat voor de duur van een subtaak, en verdwijnt daarna.

Waarom meerdere agents soms beter presteren dan één

Het meest aangehaalde resultaat over dit onderwerp komt uitgerekend van Anthropic. In een interne evaluatie presteerde een systeem met een Opus-agent als dirigent en Sonnet-subagents 90,2% beter dan een enkele Opus-agent op dezelfde onderzoekstaken (dezelfde bron als hierboven). De verklaring zit in één woord: parallellisatie. Een enkele agent verkent sporen een voor een, binnen één contextvenster dat uiteindelijk verzadigd raakt. Meerdere agents kunnen meerdere sporen tegelijk verkennen, elk binnen zijn eigen context, voordat hun bevindingen worden samengevoegd.

Dit voordeel is niet universeel. Het manifesteert zich vooral bij "brede" taken: documentonderzoek, het verkennen van meerdere hypothesen, het verwerken van een groot volume losse informatie. LangChain vat de voorwaarde in een referentieartikel over dit onderwerp goed samen: multi-agentsystemen excelleren bij hoogwaardige taken die zich goed lenen voor parallellisatie, en verliezen hun nut zodra het werk sterk sequentieel is of afhankelijk van een gedeelde context (bron: LangChain, "How and when to build multi-agent systems", https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems, geraadpleegd op 2026-09-04).

Anthropic is zelfs zo ver gegaan om statistisch te ontleden wat de prestatieverschillen tussen configuraties verklaart. Drie factoren verklaren samen 95% van de waargenomen variantie: de hoeveelheid gebruikte tokens, het aantal uitgevoerde tool-aanroepen, en de modelkeuze. Tokengebruik alleen al verklaart 80% van die variantie (dezelfde bron). Met andere woorden, het is niet "meerdere agents hebben" dat de prestatiewinst oplevert, het is het vermogen dat dit geeft om meer rekenkracht parallel in te zetten op een probleem dat zich daarvoor leent. Bij een probleem dat zich daar niet voor leent, levert diezelfde capaciteit niets op, ze kost alleen meer voor een vergelijkbaar resultaat als een enkele agent.

De prijs van coördinatie

Deze prestatiewinst heeft een prijs, en die is verre van marginaal. Volgens Anthropic verbruikt een enkele agent al ongeveer 4 keer meer tokens dan een gewoon chatgesprek. Een multi-agentsysteem verbruikt er ongeveer 15 keer meer (dezelfde bron). Dat is geen boekhoudkundig detail: op dit niveau van vermenigvuldiging rechtvaardigen alleen taken met een werkelijk hoge bedrijfswaarde de investering.

De coördinatiekosten blijven niet beperkt tot tokens. LangChain wijst op een meer structureel probleem: gelijktijdige schrijfacties geven veel meer problemen dan gelijktijdige leesacties. Twee agents die dezelfde database parallel lezen, is geen probleem. Twee agents die tegelijk hetzelfde document, hetzelfde ticket of dezelfde coderegel aanpassen, produceert conflicten die daarna moeten worden verzoend, vaak handmatig. Hoe meer agents, hoe groter het faaloppervlak: elke extra agent voegt een laag gedeelde status toe, een communicatieprotocol, en een nieuw punt waarop het systeem kan vastlopen zonder dat iemand meteen begrijpt waarom.

Reken ook de debugkosten mee. Het redeneren van één enkele agent volgen, met zijn actietijdlijn, is al een werk op zich. De opeenvolging van beslissingen tussen meerdere agents die een taak onderling verdelen, met hun berichtenuitwisseling en eventuele afwijkingen, volgen vraagt om een veel geavanceerdere observability. Dat is een project op zich.

Wanneer u niet aan multi-agent moet beginnen

De reflex "meer agents, meer kracht" is een van de zekerste manieren om een AI-budget te laten ontsporen zonder evenredige winst. Gartner heeft het hard becijferd: het bureau voorspelt dat meer dan 40% van de agentische AI-projecten tegen eind 2027 wordt stopgezet, met name door oplopende kosten, slecht gedefinieerde bedrijfswaarde en onvoldoende risicobeheersing (bron: Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027, geraadpleegd op 2026-09-04). Een groot deel van deze mislukkingen komt van projecten die orkestratiecomplexiteit toevoegen zonder dat de taak dat rechtvaardigt.

Concreet blijft u beter bij één agent wanneer de taak binnen één contextvenster past, sterk sequentieel is (elke stap hangt strikt af van de vorige), of wanneer het werkvolume de tokenrekening niet rechtvaardigt. LangChain noemt codering als voorbeeld: in tegenstelling tot onderzoek bevat een ontwikkeltaak zelden echt parallelliseerbaar werk, wat multi-agent minder relevant maakt voor dit specifieke geval dan men zou denken.

De juiste vraag om te stellen voordat u een tweede agent toevoegt is dus niet "kan dit helpen?", maar "heeft deze taak een echte, natuurlijke scheidslijn?". Als een deel van het werk toegang tot bestanden vereist, een ander deel toegang tot een database, en een derde een aanroep naar een externe API, is er een echte opdeling mogelijk. Als alles afhangt van dezelfde redeneerdraad, voegt het toevoegen van agents vooral wrijving toe.

Een eenvoudige checklist voordat u begint: genereert de taak meerdere onafhankelijke sporen om parallel te verkennen? Rechtvaardigt het werkvolume een tokenrekening die meerdere keren hoger is? Schrijven de subtaken naar verschillende systemen, of dreigen ze elkaar in de weg te zitten op dezelfde data? Als het antwoord op een van deze drie vragen nee is, zal één goed uitgeruste agent, met goede toegang en duidelijke instructies, waarschijnlijk sneller gaan en minder kosten dan een architectuur met meerdere agents.

Wat Atako concreet verandert

Bij Atako bestaat deze orkestrator-subagent-logica native: een agent kan een complexe subtaak delegeren aan een tijdelijke subagent, waarvan het werk als stappen verschijnt in de activiteitentijdlijn van de hoofdagent, zonder extra slot te verbruiken. Dat vermijdt de meest voorkomende valkuil: het vermenigvuldigen van "volledige" agents (en hun kosten) terwijl een simpele tijdelijke subagent zou volstaan. Wilt u verder ingaan op het budgetaspect, het volgende artikel behandelt de werkelijke kostenposten van een AI-agent in een bedrijf, en het artikel over ROI-meting helpt u om, eenmaal geïmplementeerd, te controleren of de investering het waard was.