Je vraagt je AI-assistent om het product van een concurrent te onderzoeken, de bevindingen samen te vatten, een vergelijkingsdocument op te stellen en het naar je team te mailen. Een enkele agent kan elk van deze stappen uitvoeren — maar ze allemaal goed doen, achter elkaar, terwijl de context over alle vier de taken behouden blijft, duwt tegen de grenzen van wat één agentsessie soepel aankan. Het context window raakt vol. De agent verliest het overzicht over eerdere stappen. De kwaliteit van de uiteindelijke output daalt omdat het model te veel zaken tegelijk moet jongleren.
Dit is het probleem dat agent-swarms oplossen. In plaats van één agent die alles doet, breekt een coördinator-agent de taak op in deeltaken en delegeert elk aan een gespecialiseerde agent. De onderzoeksagent doorzoekt het web en levert gestructureerde bevindingen. De schrijfagent neemt die bevindingen en stelt het document op. De e-mailagent verstuurt het resultaat. Elke agent werkt in zijn eigen container, met zijn eigen context window, gefocust op één ding.
Het idee is niet nieuw — CrewAI en AutoGen verkennen multi-agent-patronen al meer dan een jaar. Wat anders is aan NanoClaw's aanpak is dat elke agent in de swarm in zijn eigen geïsoleerde container draait, wat betekent dat de beveiligings- en isolatiegaranties die gelden voor single-agent-gesprekken automatisch doorwerken naar multi-agent-workflows. ## Hoe swarms werken in NanoClaw
NanoClaw's swarm-architectuur is gebouwd op een eenvoudige primitieve: een agent kan andere agents starten. Wanneer Claude Code in een container draait, is een van de beschikbare tools agentdelegatie — de mogelijkheid om een deeltaak te beschrijven en NanoClaw een nieuwe container te laten starten om deze af te handelen. De bovenliggende agent krijgt het resultaat terug wanneer de onderliggende agent klaar is.
De orkestratie verloopt op natuurlijke wijze via Claude's eigen redenering. Je hoeft geen workflowgrafiek te definiëren of agentrolleen te configureren in een YAML-bestand. Je beschrijft wat je wilt, en Claude beslist of het dit direct afhandelt of delen delegeert aan sub-agents. De beslissing is gebaseerd op dezelfde redenering die Claude goed maakt in het opsplitsen van complexe problemen — het herkent wanneer een taak onafhankelijke componenten heeft die baat hebben bij gerichte aandacht.
In de praktijk ziet dit eruit als een boom van containers. De rootcontainer ontvangt je bericht, beslist dat het webonderzoek en documentschrijven nodig heeft, start twee onderliggende containers, wacht op hun resultaten en synthetiseert een definitief antwoord. Elke onderliggende container heeft zijn eigen CLAUDE.md-context, zijn eigen gemounte werkruimte en zijn eigen set tools. De onderzoeksagent heeft webbrowsing ingeschakeld; de schrijfagent heeft schrijftoegang tot de gedeelde werkruimte. Geen van beide kan de context of tools van de ander benaderen.
Waarom containerisolatie belangrijk is voor swarms
De meeste multi-agent-frameworks draaien alle agents in hetzelfde proces. CrewAI's agents delen een Python-runtime. AutoGen's agents delen een gespreksthread. Dit werkt voor demo's, maar het creëert problemen op schaal die achteraf moeilijk te repareren zijn.
Het eerste probleem is schaderadius. Als één agent in een swarm een prompt-injection tegenkomt — een kwaadaardige website die probeert het gedrag van de agent te kapen — is de injectie beperkt tot die ene container. Het kan de bovenliggende agent niet beïnvloeden, kan de contexten van andere onderliggende agents niet benaderen en kan de gespreksgeschiedenis van de oorspronkelijke gebruiker niet lezen. De gecompromitteerde container wordt afgebroken wanneer deze klaar is, en de bovenliggende agent ontvangt de geproduceerde output (die de bovenliggende kan evalueren op kwaliteit voordat deze wordt gebruikt).
Het tweede probleem is resourceconcurrentie. Agents in een gedeeld proces concurreren om hetzelfde context window, hetzelfde geheugen en dezelfde CPU. In NanoClaw heeft elke container zijn eigen resources. Een onderzoeksagent die zware webpagina's bekijkt vertraagt geen schrijfagent die een document opstelt. De containers draaien gelijktijdig op aparte threads, en het resourcebeheer van de host regelt de planning.
Het derde probleem is credential-scoping. Een onderzoeksagent heeft webtoegang nodig maar zou geen schrijfrechten voor bestanden moeten hebben. Een bestandsbeheeragent heeft schijftoegang nodig maar zou geen webtoegang moeten hebben. In een shared-process-framework vereist het afdwingen van deze grenzen toegangscontroles op applicatieniveau die omzeild kunnen worden. In NanoClaw zijn de grenzen container-mounts — de onderzoeksagent kan letterlijk niet naar schijf schrijven omdat er geen beschrijfbaar pad in zijn container is gemount. ## Praktische swarm-patronen
De patronen die uit werkelijk gebruik ontstaan zijn interessanter dan de theoretische architectuur. Het meest voorkomende is het onderzoek-en-synthese-patroon: een bovenliggende agent start 3-5 onderzoeksagents om verschillende aspecten van een vraag parallel te onderzoeken, verzamelt hun bevindingen en produceert een gesynthetiseerd antwoord dat grondiger is dan wat een enkele agent in één keer zou kunnen produceren.
Het tweede veelvoorkomende patroon is concept-en-review. Een agent schrijft een eerste concept, en start vervolgens een reviewer-agent met instructies om het te bekritiseren. De feedback van de reviewer gaat terug naar de oorspronkelijke agent (of een nieuwe schrijfagent) voor revisie. Dit levert merkbaar betere output op dan single-pass-generatie, omdat de reviewer-agent een vers context window heeft en het concept kan evalueren zonder de cognitieve belasting van het zelf geschreven te hebben.
Het derde patroon is toolspecialisatie. Sommige taken vereisen tools die duur of risicovol zijn — webbrowsing, shell-commandouitvoering, bestandssysteemwijzigingen. Een bovenliggende agent kan deze operaties delegeren aan onderliggende agents met specifieke tooltoegang, waardoor zijn eigen context schoon blijft en zijn eigen rechten minimaal. De bovenliggende raakt het bestandssysteem of het netwerk nooit direct aan; het verwerkt alleen de resultaten die onderliggende agents terugsturen.
De grenzen van swarms
Swarms zijn niet gratis. Elke onderliggende agent is een aparte Claude API-aanroep, wat aparte tokenkosten betekent. Een swarm die vijf onderzoeksagents start kost ruwweg vijf keer zoveel als een enkele agent die al het onderzoek doet. Voor eenvoudige vragen — "wat is het weer?" of "vertaal deze zin" — zijn swarms pure overhead.
De latentie stapelt zich ook op. Zelfs met parallelle uitvoering moet de bovenliggende agent wachten tot de langzaamste onderliggende klaar is voordat het resultaten kan synthetiseren. Een swarm van vijf agents waarvan er één 30 seconden nodig heeft om een trage website te bekijken, betekent dat de gebruiker 30 seconden plus synthesetijd wacht, ongeacht hoe snel de andere vier waren.
NanoClaw gaat hier pragmatisch mee om. Claude beslist wanneer swarms te gebruiken op basis van taakcomplexiteit — eenvoudige vragen krijgen directe antwoorden, complexe meerdelige verzoeken worden gedelegeerd. De gebruiker configureert geen swarm-gedrag; ze stellen gewoon vragen, en het systeem schaalt zijn aanpak naar de complexiteit. Het doel is niet om overal swarms te gebruiken — het is om ze te gebruiken waar ze oprecht betere resultaten opleveren dan een enkele agent zou kunnen.
De multi-agent-toekomst gaat niet over het vervangen van enkele agents. Het gaat over het geven aan enkele agents van de mogelijkheid om hulp in te roepen wanneer ze die nodig hebben, op een manier die veilig, geïsoleerd en transparant is. NanoClaw's container-per-agent-model maakt dat mogelijk zonder de beveiligingscompromissen die komen kijken bij het draaien van meerdere agents in een gedeelde omgeving.