Orchestrators, sub-agents en de mens in de loopOrchestrators, sub-agents and the human in the loop
Hoe meer ik met multi-agent-systemen werk, hoe duidelijker het wordt: de kracht zit niet in de agents zelf, maar in hoe je ze afbakent.The more I work with multi-agent systems, the clearer it gets: the power isn't in the agents themselves, but in how you scope them.
Een orchestrator die taken verdeelt. Sub-agents die elk hun eigen domein kennen. Mensen die beslissen. Dat is het patroon achter de Kantoortuin. Maar ook het patroon achter een project dat deze week van start gaat voor een klant. Andere sector, andere use case, dezelfde fundamentele architectuur.
De kracht zit in de afbakening
Hoe meer ik met dit patroon werk, hoe meer ik zie dat de kracht niet in de agents zelf zit. Het zit in hoe je ze afbakent. Een agent die te veel kan is een agent die niets goed doet. De vragen die ertoe doen: wat doet deze agent wel? Wat doet hij expliciet niet? Waar stopt zijn verantwoordelijkheid en begint die van een andere agent?
Dat lijkt simpel. Maar het is het moeilijkste onderdeel van het ontwerp. Want als de scope niet klopt, krijg je agents die over elkaars grenzen gaan. Conflicterende output. Onduidelijke verantwoordelijkheid. En uiteindelijk een systeem waar niemand meer op vertrouwt.
De orchestrator is daarin cruciaal. Die herkent de intentie, bepaalt welke agent aan zet is en zorgt dat de juiste context meekomt. Niet te veel. Niet te weinig.
Waarom ik mijn skills niet zomaar drop
Online vind je overal skills, plugins en tools. Gratis te downloaden, één klik om te installeren. Op LinkedIn deelt iemand zijn volledige stack, zijn skills, zijn instellingen. Veel likes, veel connectieverzoeken. Ik doe dat niet. Niet omdat ik niks wil delen, ik ben juist heel erg van sharing is caring. Maar wat voor mij werkt, werkt niet automatisch voor jou.
Een skill is gebouwd op context. Mijn CLAUDE.md, mijn architectuur, mijn manier van werken. Download je een skill die voor een DDD-architectuur is gebouwd terwijl jij met een heel andere structuur werkt, dan doet hij iets. Maar niet wat je verwacht. Soms helemaal niets. Soms iets wat je project juist verstoort. Begrijp dus eerst wat het doet en of het aansluit op hoe jij werkt. Sluit het niet aan, finetune het dan of bouw het zelf. Want als je het niet kunt uitleggen of op papier kunt schrijven, kun je het ook niet goed toepassen.
Hetzelfde geldt voor het tempo waarin alles verschijnt. De ene dag een nieuwe tool, de volgende dag alweer een update. Ik spring niet op elke hype. Ik laat dingen bezinken en onderzoek een tool of techniek pas als ik echt denk dat het nuttig voor mij kan zijn. Liever één tool die je echt begrijpt en goed inzet dan tien tools die je half kent. De hypetrein rijdt altijd. Jij bepaalt wanneer je instapt. FOMO kun je gerust negeren.
De mens blijft in control
Wat ik altijd inbouw: het systeem publiceert niets zelfstandig. Drafts landen op de juiste plek. Het team beslist. Dat is geen beperking, dat is een ontwerpkeuze.
Guardrails zijn daarin essentieel. Je definieert vooraf wat een agent wel en niet mag doen. Wat binnen scope valt en wat niet. Wil een agent daarbuiten gaan, dan stopt het systeem en vindt er een menselijke check plaats. Niet achteraf, maar op het moment zelf.
Want AI die autonoom handelt zonder menselijke check is niet slim. Het is roekeloos.
An orchestrator that distributes tasks. Sub-agents that each know their own domain. People who make the decisions. That's the pattern behind the Kantoortuin. And it's also the pattern behind a project that kicks off this week for a client. Different sector, different use case, same fundamental architecture.
The power is in the boundaries
The more I work with this pattern, the more I see that the power isn't in the agents themselves. It's in how you scope them. An agent that can do too much is an agent that does nothing well. The questions that matter: what does this agent do? What does it explicitly not do? Where does its responsibility end and another agent's begin?
That sounds simple. But it's the hardest part of the design. Because if the scope is off, you get agents crossing each other's boundaries. Conflicting output. Unclear responsibility. And eventually a system nobody trusts anymore.
The orchestrator is crucial here. It recognises the intent, decides which agent is up and makes sure the right context comes along. Not too much. Not too little.
Why I don't just drop my skills
Online you'll find skills, plugins and tools everywhere. Free to download, one click to install. On LinkedIn someone shares their entire stack, their skills, their settings. Lots of likes, lots of connection requests. I don't do that. Not because I don't want to share, I'm very much a sharing-is-caring person. But what works for me doesn't automatically work for you.
A skill is built on context. My CLAUDE.md, my architecture, my way of working. Download a skill built for a DDD architecture while your project is structured completely differently, and it will do something. Just not what you expect. Sometimes nothing at all. Sometimes something that actively disrupts your project. So first understand what it does and whether it fits how you work. If it doesn't fit, fine-tune it or build it yourself. Because if you can't explain it or write it down on paper, you won't be able to apply it well either.
The same goes for the pace at which everything appears. One day there's a new tool, the next day another update. I don't jump on every hype. I let things settle and only dig into a tool or technique when I genuinely think it could be useful to me. Better one tool you truly understand and use well than ten tools you half know. The hype train is always running. You decide when to get on. FOMO is safe to ignore.
The human stays in control
Something I always build in: the system publishes nothing on its own. Drafts land in the right place. The team decides. That's not a limitation, that's a design choice.
Guardrails are essential here. You define up front what an agent may and may not do. What's in scope and what isn't. If an agent wants to go beyond that, the system stops and a human check takes place. Not afterwards, but right at that moment.
Because AI that acts autonomously without a human check isn't smart. It's reckless.