Wanneer je "AI orchestration" googelt, krijg je steeds hetzelfde plaatje. Een centrale agent — de orchestrator — die taken uitzet bij subagents. De subagents werken parallel, elk in hun eigen context window. De orchestrator verzamelt de resultaten en combineert ze tot een antwoord.
Elk framework tekent het zo. Elk artikel beschrijft het zo. LangGraph, CrewAI, Anthropic's Agent SDK — allemaal hetzelfde patroon.
Na zes maanden dagelijks multi-agent systemen draaien in productie weet ik: dat is niet orchestration. Dat is delegatie. En het verschil is fundamenteel.
Delegatie vs. orchestration
Stel je voor dat je een projectleider bent met drie teamleden. Je geeft elk een taak en zegt: "Laat me weten als je klaar bent." Wanneer ze klaar zijn, combineer je hun werk.
Dat is delegatie. Het werkt wanneer je teamleden betrouwbaar zijn, de taken onafhankelijk zijn, en de kwaliteit voorspelbaar is.
Orchestration is iets anders. Orchestration is: je geeft elk een taak met specifieke deliverables. Wanneer iemand zegt "klaar", controleer je of de deliverables er daadwerkelijk zijn en of ze aan de eisen voldoen. Als dat niet zo is, stuur je het werk terug met specifieke feedback. Je legt elke interactie vast. En je past de taakverdeling aan op basis van wie goed presteert.
Het verschil zit niet in het verdelen van werk. Het zit in wat er gebeurt nadat het werk is afgeleverd.
Hoe de meeste frameworks het doen
Het dominante patroon in 2026 werkt als volgt:
- Orchestrator-agent ontvangt een complexe taak
- Orchestrator besluit dat de taak te groot is voor één context window
- Orchestrator spawnt subagents — child-processes met een beperkte opdracht
- Subagents werken parallel, elk in hun eigen context
- Subagents leveren resultaat terug aan de orchestrator
- Orchestrator combineert de resultaten
Het argument voor dit patroon is context window management. Anthropic's eigen engineering blog beschrijft hoe gespecialiseerde subagents gerichte taken afhandelen met eigen context windows en een samengevat resultaat terugleveren aan de hoofdagent.
Dat klopt. Maar het lost één probleem op — context overflow — en creëert er drie nieuwe: geen onafhankelijke verificatie, geen audit trail, en geen feedback loop. Ik heb hier uitgebreid over geschreven in waarom ik geen subagents gebruik.
Hoe mijn orchestrator werkt
Mijn systeem — VNX Orchestration — gebruikt geen subagents. Het dispatcht naar parallelle terminals.
Dat klinkt als een semantisch verschil. Het is een architecturaal verschil. Dit is waarom.
Terminal dispatch in plaats van subagent spawning
Een subagent is een child-process van de orchestrator. De orchestrator start hem, geeft hem een opdracht, en wacht op het resultaat. De subagent bestaat alleen binnen de scope van die ene taak.
Een terminal is een volwaardige AI-instance. Claude Opus in Terminal 1. Claude Sonnet in Terminal 2. Codex CLI in Terminal 3. Elk met hun eigen context, hun eigen geheugen, hun eigen capabilities. De orchestrator stuurt een taak naar een terminal — maar de terminal is niet afhankelijk van de orchestrator om te bestaan.
Het cruciale verschil: de orchestrator heeft volledige controle over de dispatch en de verificatie, maar nul controle over hoe de agent het werk uitvoert. De agent is een black box voor de orchestrator — en dat is bewust. Want de verificatie gebeurt niet door naar het proces te kijken, maar door het resultaat te controleren.
Per-output kwaliteitscontrole
Na elke dispatch verifieert het systeem de deliverables. Niet door de agent te vragen "ben je klaar?" maar door onafhankelijk te checken of het resultaat er is en voldoet.
Concreet: als ik een agent vraag om een functie te schrijven met tests, dan controleert het systeem:
- Bestaat het bestand?
- Bevat het de gevraagde functie?
- Zijn er tests?
- Slagen de tests?
Als één van deze checks faalt, is de taak niet af. Ongeacht wat de agent zegt.
Lees ook: Async Quality Gates: Why AI Agents Don't Get to Decide When They're Done — de technische deep-dive in evidence-based closure.
Reject-and-retry met specifieke feedback
Dit is waar het fundamenteel anders werkt dan subagents. Wanneer een resultaat niet voldoet, gaat de taak niet gewoon "opnieuw". De taak gaat terug naar dezelfde agent met specifieke feedback:
"Je deliverable user-service.ts ontbreekt de error handling die in de specificatie staat. Specifiek: er is geen try/catch rond de database call op regel 34, en de fallback voor een mislukte connectie ontbreekt."
De agent krijgt context over wat er mis is — niet alleen "doe het opnieuw". Dit is fundamenteel anders dan retry-mechanismen in frameworks die simpelweg dezelfde prompt opnieuw sturen met exponential backoff.
Bij subagents bestaat dit mechanisme niet. De subagent levert op, de orchestrator accepteert, klaar. Er is geen terugkoppeling. Er is geen kwaliteitscontrole. Er is geen mogelijkheid om specifiek aan te geven wat er beter moet.
NDJSON receipt ledger
Elke interactie wordt vastgelegd. Elke dispatch, elke verificatie, elke reject, elke accept. In een NDJSON formaat dat je achteraf kunt doorzoeken, analyseren en auditen.
Dit is de Glass Box Governance filosofie: als je niet kunt bewijzen wat er is gebeurd, is het niet gebeurd. De technische implementatie van dit ledger beschrijf ik in Why I Chose NDJSON Over Postgres for My AI Agent Audit Trail.
Met subagents is er geen receipt. De subagent doet zijn werk, levert op, en verdwijnt. De enige trace is het resultaat zelf — en resultaten liegen soms. Dat heb ik geleerd om 2 uur 's nachts.
Waarom dit ertoe doet
De Nederlandse AI-markt groeit explosief. 327% groei in multi-agent workflows in 2025 alleen al. Maar de artikelen die ik lees — op Techzine, OpenKlauw, AI.nl — gaan bijna uitsluitend over de mogelijkheden. Meer agents, meer taken, meer parallellisatie.
Niemand schrijft over controle.
Machine Learning Mastery beschrijft de trend naar "bounded autonomy architectures with clear operational limits, escalation paths, comprehensive audit trails". Camunda's rapport over agentic orchestration laat zien dat de meerderheid van organisaties een kloof ervaart tussen hun AI-visie en de productierealiteit. En Deepchecks noemt een complete audit trail als een van de kernvereisten voor productie-AI.
De patronen zijn duidelijk:
- Dispatch, niet spawn. Stuur taken naar volwaardige instances, niet naar wegwerp-subagents.
- Verifieer het resultaat, niet de belofte. Controleer deliverables onafhankelijk van wat de agent zegt.
- Reject met context. Stuur werk terug met specifieke feedback, niet met een generieke retry.
- Leg alles vast. Elke dispatch, elke verificatie, elke beslissing — in een doorzoekbaar formaat.
Lees ook: Human-on-the-Loop: A Production Graduation Path — hoe je van handmatige approvals naar autonome AI agents gaat zonder de controle te verliezen.
Dit is geen framework
Ik verkoop geen framework. Ik beschrijf principes die werken ongeacht welke tools je gebruikt. Je kunt dit bouwen met Claude Code, met Codex CLI, met Gemini — of met een combinatie. Why Architecture Beats Models beschrijft waarom die keuze er niet toe doet. De architectuur is open source.
Het punt is niet welke AI je gebruikt. Het punt is of je kunt bewijzen wat die AI heeft gedaan.
Orchestration zonder verificatie is delegatie. En delegatie zonder controle is hopen dat het goed gaat.
Na 2400+ dispatches in productie kan ik je vertellen: hoop is geen architectuur.
Benieuwd hoe dit er in de praktijk uitziet? Ik heb het complete systeem open source beschikbaar gemaakt op GitHub. En in de Glass Box Governance serie beschrijf ik elke laag van de architectuur — van receipt ledgers tot quality gates.