Multi-agentsystemen: wanneer ze helpen en wanneer ze een dure omweg zijn

Multi-agentarchitecturen zijn het huidige standaardantwoord op "onze agent werkt niet goed genoeg". Splits hem op in een onderzoeker, een schrijver, een criticus en een orchestrator, en de kwaliteit gaat omhoog.

Soms. Vaak gaat het zijwaarts: vijf agents leveren een slechter resultaat dan één deed, tegen vier keer de kosten en zes keer de latency, en nu zijn er vijf dingen te debuggen in plaats van één.

Dit is de eerlijke versie van wanneer delegeren loont.

Wat een subagent daadwerkelijk kost

Elke delegatie brengt vaste overhead mee die makkelijk over het hoofd wordt gezien:

• Context opnieuw opbouwen. De subagent begint koud. Alles wat hij nodig heeft, moet opnieuw worden uitgelegd of ontdekt.
• Opnieuw verkennen. Hij zal bestanden herlezen, zoekopdrachten overdoen en conclusies opnieuw afleiden die de ouder al had.
• Rapport genereren. Hij schrijft een samenvatting.
• Rapport consumeren. De ouder leest die samenvatting en redeneert erover.
• Informatieverlies. De samenvatting is per definitie lossy. Nuance die de subagent zag, overleeft de retour niet.

Voor een taak die de ouder in vier tool-aanroepen had afgerond, overstijgt die overhead het werk. Je hebt vijf keer de tokens betaald voor een slechter geïnformeerd resultaat.

Delegeer wanneer de opbrengst die overhead duidelijk overstijgt. Anders niet.

Wanneer delegeren echt wint

1. Echte parallelliteit over onafhankelijk werk. Twaalf bestanden te analyseren, geen onderlinge afhankelijkheden. Zes concurrenten te onderzoeken. Veertig testsuites te draaien. De doorlooptijd daalt evenredig met de fan-out. Dit is de sterkste case en degene om voor te bouwen.

2. Contextisolatie bij verkenning met groot oppervlak. Een codebase of documentcorpus onderzoeken genereert enorme tussencontext — gelezen bestanden, doodlopende sporen — die de ouder nooit nodig heeft. Een subagent absorbeert dat en levert een gedestilleerde bevinding. Je ruilt tokens voor een schone oudercontext, wat bij langlopend werk vaak de bindende beperking is.

3. Tegensprekende review. Een verifieerder met frisse context en een expliciete opdracht om problemen te vinden, presteert consequent beter dan zelfkritiek, omdat de context van de schrijver alle redenering bevat die de fout produceerde. Frisse ogen werken bij modellen om dezelfde reden als bij mensen.

4. Echt verschillende expertise. Andere systeemprompts, andere tools, andere modellen, andere beperkingen. Een code-schrijvende agent en een security-review-agent zijn legitiem verschillende configuraties. Een "onderzoeker" en een "schrijver" die alleen in één zin prompt verschillen, meestal niet.

Wanneer niet

Sequentiële afhankelijkheden. Heeft B de volledige output van A nodig, dan voegt splitsen er voor niets een lossy samenvattingsstap tussen.

Kleine taken. Alles wat de ouder in een handvol tool-aanroepen afrondt. Dit is met afstand de meest gemaakte fout.

Routineverificatie. Je eigen werk controleren hoort in de hoofdlus, niet in een gespawnde agent. Huidige topmodellen verifiëren prima zonder dat je het vraagt — en opdragen een verificatiestap toe te voegen levert vaak overbodige controle op in plaats van betere resultaten.

Eén bescheiden taak over meerdere agents verdelen. Parallelle subagents zijn voor echt onafhankelijke sporen, niet om één middelgrote klus in stukken te hakken die daarna weer aan elkaar moeten.

Compenseren voor een slechte prompt of ontbrekende tools. Faalt één agent omdat hij de juiste retrieval of de juiste tool mist, dan falen vijf agents vijf keer parallel. Repareer het onderliggende gat.

Het richtingprobleem

Iets om te weten voor wie agentsystemen over modelgeneraties heen onderhoudt: het standaard delegatiegedrag van topmodellen is omgeslagen.

De ene generatie greep te wéinig naar subagents en had expliciete aanmoediging nodig om te delegeren. De volgende grijpt er vrijelijk naar en heeft een expliciete rem nodig. Promptrichtlijnen geschreven om het eerste probleem op te lossen, creëren actief het tweede.

Neem je een "delegeer agressiever"-instructie mee een modelupgrade in, verwacht dan dat je tokenverbruik zich vermenigvuldigt. Herijk delegatiegedrag bij elke modelwissel, en verkies een deterministisch plafond op het aantal spawns boven richtlijnen in proza — een harde limiet is de enige knop die betrouwbaar standhoudt.

Architectuurpatronen die werken

Orchestrator + workers. Eén coördinator houdt het doel en het plan; workers voeren afgebakende deeltaken uit. De coördinator krijgt het topmodel op hogere diepte; de workers goedkopere modellen op lagere diepte. Dit is de standaard en past op de meeste echte problemen.

Verkies asynchroon delegeren boven spawn-en-wacht. Langlevende workers die hun context tussen deeltaken behouden, presteren op twee manieren beter: ze bouwen hun context niet elke keer opnieuw op (waardoor hun promptprefix gecachet blijft), en de orchestrator zit niet vast te wachten op de traagste. Ondersteunt je platform persistente worker-threads, gebruik ze.

Schrijver + verifieerder. Twee agents, tegengestelde prikkels. De schrijver produceert; de verifieerder probeert het te breken tegen expliciete criteria. Itereer tot de verifieerder slaagt of je een limiet raakt. Uitstekend voor alles met controleerbare output — code, gestructureerde deliverables, compliancegevoelige content.

Map-reduce. Waaier identiek werk uit over N items, verzamel, synthetiseer. Ideaal voor bulkanalyse. De synthesestap is waar de kwaliteit wordt gewonnen of verloren — brief hem goed.

De zeven regels waar wij aan vasthouden

1. Begrens de fan-out. Een hard getal in code. Twintig parallelle agents op een taak die er drie nodig had, is een kostenincident — en modellen doen het als het mag.
2. Brief precies, in één keer. Het duurste patroon is een vage subagent starten, wachten, en dan opnieuw briefen. Specificeer vooraf: doel, beperkingen, hoe "klaar" eruitziet, wat er terug moet komen.
3. Sta achter de delegatie. Heb je gedelegeerd, gebruik dan het resultaat. Een orchestrator die de bevindingen van zijn subagent opnieuw afleidt, heeft twee keer betaald voor één antwoord.
4. Start parallel werk in één batch. Onafhankelijke subagents horen gelijktijdig te starten, niet achter elkaar. Dit is een harnas-kwestie en gaat vaak mis — controleer of je framework echt parallelliseert in plaats van elk apart af te wachten.
5. Eén niveau diep. Subagents die subagents spawnen, produceren onnavolgbare kosten en onleesbare traces. Veel platforms dwingen dit inmiddels af; doe het zelf als de jouwe dat niet doet.
6. Geef workers smalle tools. Een worker die concurrenten onderzoekt heeft geen schrijfrechten nodig. Minimale rechten beperken zowel schade als afleiding.
7. Trace alles, per agent. Je hebt tokenaantallen per agent, duur per agent en de volledige berichtgraaf nodig. Zonder die is een trage, dure run niet te diagnosticeren.

Kort kostenmodel

Een ruw model dat voor planning dicht genoeg zit:

kosten één agent      ≈ T
kosten georkestreerd  ≈ T_orchestrator + Σ(T_worker) + Σ(overdrachtsoverhead)

De overdrachtsoverhead per worker is ruwweg: context opnieuw opbouwen + rapport genereren + rapport consumeren. In de praktijk vaak 20–40% van het eigen tokenverbruik van de worker.

Een fan-out van vijf over werk dat serieel ~2× het tokenverbruik van één agent zou zijn, landt dus rond 2,5–3× in totale kosten — teruggekocht als ruwweg 5× minder doorlooptijd.

Dat is een goede ruil als latency telt en een slechte als dat niet zo is. Een nachtelijke batchjob heeft geen latencybeperking; draai hem serieel. Een interactief onderzoeksverzoek wel; waaier die uit.

De toets

Voordat je een tweede agent toevoegt, beantwoord je:

Wat kunnen twee agents hier dat één niet kan?

Geldige antwoorden: echt onafhankelijk werk gelijktijdig draaien; een groot verkenningsoppervlak buiten de oudercontext houden; reviewen met echt frisse ogen; een wezenlijk andere configuratie van model, tools en beperkingen toepassen.

Ongeldige antwoorden: het voelt geavanceerder; de enkele agent is net niet goed genoeg; het architectuurdiagram ziet er beter uit.

Is het eerlijke antwoord het tweede lijstje, repareer dan de enkele agent. Betere retrieval, betere tools, betere beslisgrenzen, een betere eval-set. Dat werk gaat later mee naar de multi-agentversie, als je die ooit echt nodig hebt. Andersom geldt niet — een slecht verankerde agent wordt niet beter door hem te klonen.

---

Wij bouwen georkestreerde systemen als het werk echt parallel is, en één goede agent als dat niet zo is. Plan een auditgesprek.