Wat is een AI Orchestrator Agent?

Een AI Orchestrator Agent is de centrale agent die een taak opdeelt, de juiste specialist inschakelt en bewaakt dat alles in de goede volgorde gebeurt — vergelijkbaar met een dirigent die meerdere muzikanten aanstuurt. In plaats van één agent alles zelf te laten doen, laat je een hoofdagent coördineren en besteed je afgebakende deeltaken uit aan sub-agents.

Dit patroon heeft een officiële naam in de literatuur: het orchestrator-worker pattern. Anthropic beschrijft het als een opzet waarin "een centrale LLM dynamisch taken opdeelt, ze delegeert aan worker-LLM's en hun resultaten samenvoegt" — bij uitstek geschikt voor taken waarvan je vooraf níet weet hoeveel deelstappen er nodig zijn (Anthropic, Building Effective Agents). OpenAI noemt vrijwel hetzelfde het manager pattern: een centrale "manager" die gespecialiseerde agents aanstuurt en zelf de regie over het gesprek houdt (OpenAI, A practical guide to building agents).

Een nuance die het de moeite waard maakt om te onthouden: niet elke orchestrator is een "agent" in strikte zin. Anthropic maakt onderscheid tussen workflows (waarbij LLM's via vooraf vastgelegde code-paden worden aangestuurd) en agents (waarbij de LLM zelf dynamisch bepaalt hoe een taak wordt aangepakt) (Anthropic, Building Effective Agents). Een orchestrator kan dus deterministisch routeren (workflow) óf zelf beslissen hoe het werk wordt opgedeeld (agent). Dat verschil bepaalt hoeveel autonomie — en hoeveel onvoorspelbaarheid — je in je systeem introduceert.

Hoofdagent en sub-agents

De hoofdagent houdt de regie: hij begrijpt het gebruikersdoel, maakt een plan, kiest welke specialist nodig is en combineert de deelresultaten tot één eindantwoord. Sub-agents zijn juist smal ontworpen: één voor research, één voor review, één voor code, of één voor broncontrole. Dat maakt het systeem vaak betrouwbaarder, omdat elke agent op een kleiner en duidelijker probleem werkt (Google Cloud, Vercel AI SDK).

Het cruciale detail dat veel uitleg overslaat: de kwaliteit van het systeem staat of valt met hoe scherp de hoofdagent zijn opdrachten formuleert. Anthropic ontdekte dat een sub-agent vier dingen nodig heeft om niet te ontsporen — een helder doel, een gewenst outputformaat, richtlijnen over welke tools en bronnen te gebruiken, en duidelijke taakgrenzen. Ontbreekt één van die vier, dan gaat de sub-agent zwerven: agents dupliceerden elkaars werk, lieten gaten vallen of voerden exact dezelfde zoekopdrachten uit als hun buren (Anthropic, How we built our multi-agent research system).

Een tweede les uit datzelfde onderzoek: schaal de inzet mee met de complexiteit van de vraag. Vroege prototypes spawnden soms 50 sub-agents voor een simpele vraag. Anthropic loste dat op door expliciete regels in de orchestrator-prompt te bakken — grofweg één agent voor losse feiten, twee tot vier voor directe vergelijkingen, en meer dan tien voor echt breed onderzoek (Anthropic, How we built our multi-agent research system).

Sub-agent als tool call

Een sterke implementatie is om een sub-agent te verpakken als een gewone tool call, zodat de hoofdagent controle houdt over de conversatie en alleen een duidelijke input en output ziet. Zo'n sub-agent draait autonoom met een eigen model, eigen instructies en een eigen context window, en levert daarna alleen het resultaat terug aan de hoofdagent (Vercel AI SDK, Google Cloud). Dat is vaak beter dan alle specialistische logica in één grote prompt stoppen, omdat je interfaces scherper worden en de hoofdagent niet hoeft te weten hóe de specialist intern werkt.

Hier loont het om de twee dominante multi-agent patronen tegenover elkaar te zetten, want ze worden vaak door elkaar gehaald:

• Agents-as-tools (manager pattern): de hoofdagent roept specialisten aan zoals hij een functie zou aanroepen. De specialist neemt het gesprek niet over; hij doet zijn deeltaak en geeft het resultaat terug. De hoofdagent blijft de enige die met de gebruiker praat en het eindantwoord samenstelt. Dit houdt de controle gecentraliseerd en de coördinatie simpel.
• Handoffs (decentralized pattern): een agent draagt de hele conversatie over aan een specialist, die het vanaf dat punt overneemt. Geschikt voor triage — denk aan een klantenservice-agent die een terugbetalingsvraag volledig doorzet naar de refund-specialist.

OpenAI vat de keuze bondig samen: gebruik agents-as-tools wanneer een specialist moet helpen met een afgebakende deeltaak maar de hoofdagent verantwoordelijk blijft voor het eindantwoord; gebruik handoffs wanneer de routering zélf het werk is en je wilt dat de gekozen specialist het stokje overneemt (OpenAI Agents SDK, Agent orchestration). Voor de orchestrator-architectuur die jij beschrijft is agents-as-tools meestal de natuurlijke keuze, juist omdat de hoofdagent dan de regie nooit kwijtraakt.

Goedkopere modellen

Sub-agents zijn een uitstekende plek om kosten te drukken, omdat je voor repetitieve of beperkte taken vaak geen duur topmodel nodig hebt. Een veelgebruikt patroon — model routing — is: het sterkste model voor de hoofdagent, en snellere of goedkopere modellen voor sub-agents die bijvoorbeeld bronnen verzamelen, tekst structureren of simpele controles uitvoeren (Claude Code, Sub-agents, Anthropic, Building Effective Agents).

Dit is geen theorie. In Anthropics eigen onderzoekssysteem draait Claude Opus 4 als orchestrator met Claude Sonnet 4 als sub-agents — en juist die combinatie presteerde 90,2% beter dan één enkele Opus 4-agent op hun interne research-benchmark (Anthropic, How we built our multi-agent research system). Het principe dat jij benoemt klopt dus precies: je reserveert je duurste rekenkracht voor planning en beslissingen, en laat uitvoerend werk afhandelen tegen lagere kosten en hogere snelheid.

Minder context bloat

Een orchestrator-architectuur helpt vooral tegen context bloat: de hoofdagent hoeft niet alle tussenstappen, logs en ruwe tool-output in zijn eigen context te houden. In plaats daarvan werkt elke sub-agent in een eigen, kleinere context en geeft hij alleen de uitkomst of een compacte samenvatting terug (Anthropic, How we built our multi-agent research system, Vercel AI SDK).

Er zit een diepere reden onder waarom dit werkt. Sub-agents fungeren als filters én compressoren: ze verkennen elk een eigen deel van de vraag in een afzonderlijk context window en condenseren pas daarna het belangrijkste terug naar de hoofdagent. Daardoor kan het systeem méér terrein dekken dan in één enkele context zou passen — Anthropic koppelt de prestatiewinst expliciet aan het kunnen verdelen van redeneerwerk over meerdere onafhankelijke context windows. De hoofdagent houdt bovendien een eigen geheugen bij voor het plan, zodat dat niet verloren gaat wanneer een lang onderzoek het tokenbudget overschrijdt (Anthropic, How we built our multi-agent research system). Het netto-effect is precies wat jij beschrijft: de hoofdagent blijft scherp, het tokengebruik per context daalt, en belangrijke informatie verdrinkt niet in een steeds groeiende prompt.

Wanneer wél, wanneer niet

Hier is het eerlijk om de keerzijde te benoemen, want orchestration is geen gratis lunch. De winst heeft een prijs en een duidelijk toepassingsgebied.

De prijs is tokens. Een multi-agent systeem verbruikt al snel zo'n 15x meer tokens dan een gewoon chatgesprek, simpelweg omdat meerdere agents parallel redeneren en zoeken. Dat maakt het patroon vooral geschikt voor taken waarbij de waarde van het resultaat ruim opweegt tegen die kosten (Anthropic, How we built our multi-agent research system).

Het werkt niet voor alles. De grens loopt langs de vraag of een taak nette, onafhankelijke deelstromen kent. Breedte-onderzoek — meerdere onafhankelijke richtingen tegelijk verkennen — leent zich perfect voor parallelle sub-agents. Maar sterk verweven taken zoals coderen, waarbij elke beslissing afhangt van de vorige, gaan juist stuk in een naïeve multi-agent opzet (Anthropic, How we built our multi-agent research system).

Cognition — het team achter Devin — schreef hierover de bekendste tegenwerping, Don't Build Multi-Agents. Hun argument: zodra sub-agents parallel beslissingen nemen zonder elkaars volledige context te kennen, stapelen kleine misverstanden zich op tot tegenstrijdige resultaten. Hun illustratie is een Flappy Bird-kloon waarbij de ene sub-agent een Mario-achtige achtergrond bouwt terwijl de andere een vogel in een totaal andere stijl maakt, omdat geen van beide weet wat de ander doet. Hun twee principes: deel zoveel mogelijk context (en deel volledige agent-traces, niet losse berichten), en splits beslissingen niet op manieren die kunnen botsen (Cognition, Don't Build Multi-Agents).

De praktische synthese is dat beide kanten gelijk hebben binnen hun eigen domein: orchestration excelleert bij echt parallelle, onafhankelijke taken, en faalt bij taken die voortdurend gedeelde context en gecoördineerde beslissingen vereisen. De gangbare wijsheid van zowel Anthropic als OpenAI is daarom: begin met één agent, voeg pas extra agents toe wanneer ze de zaak meetbaar beter maken — meer specialisatie, scherpere prompts, of betere traceerbaarheid — en niet eerder (OpenAI, A practical guide to building agents, Anthropic, Building Effective Agents).

Voorbeeld: deep research

Stel dat een gebruiker vraagt om een deep research-rapport met bronnen over een markt of technologie. De orchestrator kan dan een research-sub-agent aanroepen om bronnen te zoeken, een tweede om die bronnen te controleren en een derde om de inzichten te structureren — terwijl de hoofdagent alleen de samengevatte bevindingen en bronverwijzingen ontvangt.

Zo werkt het ook echt in productie. In Anthropics onderzoekssysteem analyseert de lead agent de vraag, bepaalt een strategie en spawnt drie tot vijf sub-agents die elk in hun eigen context window een ander aspect parallel uitzoeken. De lead agent synthetiseert hun bevindingen en beslist of er nóg een ronde nodig is. Pas als er genoeg materiaal is, gaat het geheel naar een aparte CitationAgent, die de bronvermeldingen koppelt aan de juiste plekken in het rapport zodat elke claim netjes is toe te schrijven (Anthropic, How we built our multi-agent research system). Belangrijk detail: de sub-agents weten niets van elkaars bestaan en coördineren niet onderling — elke beslissing over wat er daarna gebeurt, leeft uitsluitend bij de orchestrator.

Het eindresultaat is dan één helder antwoord met bronnen, zonder dat de hoofdagent alle zoekresultaten, tussenanalyses en controlelogs volledig hoeft mee te slepen in zijn context. Precies daarom is deep research het schoolvoorbeeld van orchestration: het is breed, parallelliseerbaar, en de waarde van een goed onderbouwd rapport rechtvaardigt de extra rekenkracht.