Multi-agent-orkestratie: hoe laat je meerdere AI-agents samenwerken zonder chaos?
Meer agents inzetten lost zelden het probleem op — het verplaatst het naar de coördinatie ertussen. Over één gedeeld draaiboek, vaste rollen en één logboek als waarheid, met lessen uit ons eigen lab.
Meer agents inzetten lost zelden het probleem op waarvoor je ze inzet — het verplaatst het probleem naar de coördinatie tússen de agents. Multi-agent-orkestratie werkt pas zodra je losse bots met losse prompts vervangt door één gedeeld draaiboek: vaste rollen, een expliciete overdracht tussen stappen, en één plek waar de status van een taak daadwerkelijk klopt.
Het korte antwoord: geef elke agent precies één taak en één set bevoegdheden, laat ze schrijven naar één gedeeld logboek in plaats van te gokken naar wat een andere agent al deed, en bouw een expliciet escalatiepad in voor het moment dat een handeling onomkeerbaar wordt of twee agents het oneens zijn. De rest van dit artikel maakt dat concreet — met de architectuur die wij zelf draaien als voorbeeld.
Waarom "gewoon meer agents" meestal averechts werkt
De belofte klinkt logisch: één agent zoekt documenten op, één schrijft de conceptmail, één plant de vervolgstap. In theorie een lopende band. In de praktijk gaat het mis op een saaie plek: agents delen hun toestand impliciet, via chatgeschiedenis of een gokje over wat een andere agent al gedaan heeft. Dat werkt bij twee agents en een simpele taak. Bij drie of meer, met taken die van elkaar afhangen, ontstaan dubbel werk, tegenstrijdige acties en een systeem waarvan niemand — mens of model — nog kan navertellen wat er precies gebeurde en waarom.
Dat is geen modelprobleem. Het is hetzelfde architectuurprobleem dat ook opduikt zodra één agent zelf mag handelen zonder vangrails: de scheiding tussen waarnemen, redeneren en handelen is bij meerdere agents niet minder belangrijk, maar strenger nodig — want nu moet die scheiding ook tússen agents gelden, niet alleen binnen één agent.
Eén draaiboek in plaats van losse prompts
Een draaiboek is geen systeemprompt die "vriendelijk en behulpzaam" voorschrijft. Het is een expliciet, geversioneerd document: welke stappen bestaan er, wie voert elke stap uit, wat is de verwachte output, en aan welke voorwaarde moet zijn voldaan voordat een stap wordt overgedragen aan de volgende agent. Zonder dat document improviseert elke agent zijn eigen interpretatie van "wat er nu moet gebeuren" — en improvisatie is precies waar coördinatie stukloopt.
Het draaiboek hoeft niet ingewikkeld te zijn. Het moet wél bestaan als apart, leesbaar artefact — niet verstopt in de prompt-geschiedenis van één agent — zodat een mens het kan controleren, aanpassen en, net als bij elke andere kritieke wijziging, vooraf kan back-uppen voordat hij het bijwerkt.
Rolverdeling: elke agent één taak, niet één keer alles
De opzet die het beste standhoudt, splitst verantwoordelijkheden net zo strikt als je dat bij één autonome agent al zou willen: een deel van de agents verzamelt alleen informatie en heeft geen bevoegdheid om iets te veranderen. Een deel redeneert en formuleert een voorstel, maar voert dat voorstel niet zelf uit. Eén klein, bewust "dom" onderdeel mag daadwerkelijk muteren — en alleen dat onderdeel. Overlap in bevoegdheid tussen agents is de meest voorkomende bron van tegenstrijdige acties: twee agents die allebei denken dat zij verantwoordelijk zijn voor dezelfde mutatie, handelen soms allebei, met een resultaat dat niemand bedoelde.
Eén logboek, één waarheid
Coördinatie zonder gedeelde waarheid is gokken met extra stappen. Elk signaal, elk voorstel en elke uitgevoerde (of geweigerde) actie hoort in één append-only logboek te staan, met een correlatie-id die alle agents die aan dezelfde taak werkten aan elkaar koppelt. Dat is precies het principe achter Sentinel, onze eigen showcase van een AI-systeem met strikt gescheiden lagen: niet één taalmodel dat alles doet, maar losse onderdelen die elk hun rol spelen en samenkomen in één logboek waaruit een incident — of een taak — als één samenhangend verhaal is terug te lezen, in plaats van als losse fragmenten in vijf verschillende geheugens.
Escalatie: het punt waarop een mens beslist
Niet elk meningsverschil tussen agents hoort automatisch te worden opgelost. Als het redenerende deel van het systeem een voorstel doet dat onomkeerbaar is — een bericht dat de deur uitgaat, een mutatie die niet zomaar terug te draaien is — dan hoort dat voorstel bij een mens te landen vóórdat het wordt uitgevoerd, niet erna. Hetzelfde geldt wanneer twee agents tegenstrijdige conclusies trekken: dat is geen storing die het systeem zelf moet "oplossen" door te gokken welke agent gelijk heeft, maar een signaal dat er iets is dat een mens moet beoordelen. Een systeem dat elk conflict zelf wegmiddelt, verbergt precies de informatie die je nodig hebt om het draaiboek te verbeteren.
Beginnen met orkestratie: de kleine eerste stap
De meest gemaakte fout is beginnen met te veel agents tegelijk. Begin in plaats daarvan met twee: één die informatie verzamelt, één die een voorstel formuleert op basis daarvan — met een mens die het voorstel goedkeurt voordat er iets verandert. Pas als dat paar weken achtereen saai betrouwbaar draait, met een logboek dat je zonder moeite kunt navertellen, is het zinvol om een derde rol toe te voegen. Orkestratie schaalt niet door meer agents toe te voegen, maar door het draaiboek en het logboek overeind te houden terwijl je dat doet. Wat daarbij al wél en nog niet betrouwbaar werkt voor het mkb, staat uitgebreider in ons overzichtsartikel over AI-agents voor het mkb.
Conclusie
Multi-agent-orkestratie is geen kwestie van meer intelligentie toevoegen, maar van minder impliciete aannames toestaan. Eén draaiboek, strikt gescheiden rollen, één gedeeld logboek en een expliciet punt waarop een mens beslist — dat is het verschil tussen agents die elkaar versterken en agents die elkaar in de weg lopen.