Opus 4.6 Agentteams: Mijn Complete Installatiegids
Ik bracht vorige donderdagmiddag door met het kijken naar zes AI-agents die discussieerden over een state management-patroon voor een React-component. De ene agent vond useReducer de juiste keuze. Een andere hield vast aan Zustand. Een derde was al begonnen met useState en trok zich niets aan van de mening van de anderen. De teamleider — ook een AI-agent — moest tussenbeide komen, een beslissing nemen en iedereen op één lijn brengen.
Dit was geen simulatie. Dit waren zes onafhankelijke Claude Code-instanties die in afzonderlijke terminalsessies op mijn machine draaiden, communiceerden via een gedeeld postvak en samenwerkten aan een echte applicatiebouw. Welkom bij agentteams — de functie in Opus 4.6 die stilletjes alles heeft veranderd in hoe ik met AI werk.
Ik gebruikte sub-agents van Claude Code al maanden voordat dit uitkwam. Ze zijn solide voor geïsoleerde taken. Maar het moment dat ik twee agents nodig had die écht met elkaar konden praten over wat ze aan het bouwen waren, viel het hele systeem uit elkaar. Ik laat je precies zien waarom dat zo is, en belangrijker: hoe agentteams een coördinatieprobleem oplossen dat multi-agent AI-workflows al kwelt sinds het concept werd geboren.
Wat Sub-Agents Goed Deden (En Waar Ze Vastliepen)
Voordat agentteams bestonden, vertrouwde ik sterk op sub-agents voor alles wat parallelle verwerking vereiste. Het mentale model was eenvoudig: spin een mini-sessie op, geef het een afgebakende taak, krijg een resultaat terug. Nette delegatie.
Mijn typische opzet zag er zo uit. De hoofdsessie verwerkt de architectuurbeslissingen en orkestratie. Sub-agent #1 leest een codebase en extraheert API-eindpunten. Sub-agent #2 genereert testbestanden op basis van een specificatie. Sub-agent #3 verwerkt documentatie. Elke agent opereert in zijn eigen contextvenster — wat eigenlijk een sterkte is, omdat ze elkaars werkgeheugen niet besmetten.
Het probleem deed zich voor zodra taken niet volledig onafhankelijk waren.
Stel je voor: ik bouw een API met authenticatiemiddleware. Sub-agent #1 genereert de route-handlers. Sub-agent #2 bouwt de auth-middleware. Beide taken lijken onafhankelijk. Maar de middleware moet weten welk responsformaat de route-handlers gebruiken, en de route-handlers moeten weten wat de middleware in het verzoekobject injecteert. Geen van beide agents weet wat de andere doet.
Mijn oplossing was lelijk. Ik liet agent #1 draaien, pakte de output, plakte relevante details handmatig in de prompt voor agent #2, en ging daarna terug om het werk van agent #1 bij te werken op basis van wat agent #2 had geproduceerd. De "orkestrator" in deze workflow was ik — kopiëren en plakken tussen terminalvensters als een soort menselijke berichtentussenpersoon.
Dat is de leemte die agentteams zijn ontworpen om te vullen. En het verschil is niet incrementeel — het is structureel.
De Architectuur Achter Agentteams
Hier is hoe agentteams daadwerkelijk werken, ontdaan van marketingtaal.
Wanneer je een agentteam opstart, wordt één instantie de teamleider. Denk hieraan als je projectmanager. Die schrijft niet direct code (al kan dat wel). De primaire taak is teamleden spawnen, taken toewijzen, voortgang bewaken en resultaten samenvatten.
De overige agents zijn teamleden. Elk krijgt een volledig onafhankelijke terminalsessie met zijn eigen contextvenster. Ze kunnen bestanden lezen, code schrijven, opdrachten uitvoeren — alles wat een normale Claude Code-sessie kan doen. Maar hier is het verschil met sub-agents: teamleden hebben toegang tot twee gedeelde bronnen die alles veranderen.
Ten eerste is er het gedeelde postvak. Elke agent in het team kan een bericht sturen naar elke andere agent, direct. Geen tussenliggende bestanden. Geen wachten op de orkestrator om informatie door te sturen. Wanneer agent #3 een inconsistentie in het databaseschema ontdekt, stuurt hij direct een bericht naar agent #1, die de ORM-laag aan het bouwen is.
Ten tweede is er de gedeelde takenlijst. De teamleider maakt taken aan, kent ze toe aan teamleden en houdt de voltooiingsstatus bij. Teamleden kunnen taken markeren als geblokkeerd, voltooid of in-uitvoering. Ze kunnen ook afhankelijkheden aangeven — "Ik kan de frontend auth niet starten totdat agent #2 klaar is met de API-routes." De teamleider ziet dit alles en kan prioriteiten real-time herorganiseren.
Al deze staat — de takenlijst, teamlidmaatschap, berichten, voortgang — leeft in een lokale .dotcloud-map op je machine. Je kunt het inspecteren, versiebeheer erop uitvoeren, en als er iets misgaat, zie je precies wat elke agent deed en zei.
Ik wil eerlijk zijn over één ding: dit is een experimentele functie. Anthropic laat het standaard uitgeschakeld, en je moet het handmatig inschakelen met een omgevingsvlag. De ruwe kantjes zijn echt — ik heb agents gehad die soms postvakberichten misten, en de teamleider probeert soms het werk van teamleden zelf uit te voeren in plaats van te delegeren. Dit zijn geen dealbreakers, maar je moet weten wat je kunt verwachten.
Agentteams Inschakelen (Het Deel Dat Niemand Goed Uitlegt)
Hier is de praktische setup. Agentteams zijn verborgen achter een experimentele vlag. Je vindt geen schakelaar in de instellingen-UI van Claude Code — je moet het instellen via de opdrachtregel.
De omgevingsvariabele is:
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Voeg dit toe aan je shellprofiel (.zshrc, .bashrc) als je het persistent wilt hebben. Start daarna je terminal opnieuw.
Dat is alles. Geen npm-pakket te installeren, geen configuratiebestand te bewerken.
Om daadwerkelijk een team te starten, open je een normale Claude Code-sessie en geef je aan dat het als team moet werken:
Maak een agentteam met 3 teamleden om een taakbeheer-dashboard te bouwen
Pro tip: Expliciet zijn over de werkverdeling in je initiële prompt levert dramatisch betere resultaten op dan de teamleider dit zelf laten uitzoeken:
Maak een agentteam om een taakbeheer-dashboard te bouwen.
Teamlid 1: Bouw de backend API met Express en PostgreSQL
Teamlid 2: Bouw de React frontend-componenten en state management
Teamlid 3: Verwerk authenticatie, middleware en databasemigraties
Deze ene wijziging — expliciete scopedefinitie — verminderde mijn "agents die elkaars werk overschrijven"-incidenten met ongeveer 80%.
Praktijktest #1: Parallelle Code Review En Herstel
Mijn eerste echte test was bewust eenvoudig. Ik had een Node.js-project met ongeveer vijftien TypeScript-bestanden — een REST API — die een reviewronde en bugfixes nodig had.
Ik zette twee teamleden op:
- Agent A: Bekijk elk bestand, identificeer bugs, typefouten en beveiligingsproblemen. Stuur elke bevinding via het postvak naar Agent B zodra je die ontdekt.
- Agent B: Wacht op bevindingen van Agent A. Herstel elk probleem zodra het binnenkomt. Als een herstel context vereist over de oorspronkelijke ontwerpbedoeling, stuur dan een bericht naar Agent A om te vragen.
Wat er gebeurde was fascinerend. Agent A begon de codebase door te lezen en stuurde binnen dertig seconden zijn eerste bevinding naar Agent B: een ontbrekende null-check op een databasequeryresultaat. Agent B ontving het bericht en begon het te herstellen terwijl Agent A het volgende bestand bleef bekijken.
De communicatie over-en-weer vond real-time plaats. Agent A vond een inconsistent foutresponsformaat in drie route-handlers. In plaats van het alleen te markeren, stuurde Agent A een bericht naar Agent B met een voorgesteld gestandaardiseerd formaat. Agent B reageerde met een vraag of de frontend het huidige formaat verwachtte. Agent A controleerde de frontendc code en bevestigde dat de frontend flexibel genoeg was.
Die uitwisseling — vraag, onderzoek, antwoord, implementatie — gebeurde tussen twee AI-agents zonder dat ik iets aanraakte. De volledige review-en-herstelcyclus die me normaal twintig minuten kost, was klaar in ongeveer acht minuten.
Praktijktest #2: Bugonderzoek Vanuit Meerdere Invalshoeken
Een React-applicatie die ik had gebouwd had een intermitterend state-bug. Gebruikers meldden dat formuliergegevens soms gereset werden na indiening. Ik had al veertig minuten geprobeerd het te reproduceren en te diagnosticeren voordat ik besloot het agentteam erop los te laten.
Mijn opzet: drie teamleden, elk vanuit een andere invalshoek onderzochten.
- Agent A: Analyseer het state management van het formuliercomponent, met name de
useEffect-hooks en hun afhankelijkheden. - Agent B: Volg de gegevensstroom van formulierindiening via de API-aanroep terug naar de state-update.
- Agent C: Controleer op race conditions in de async-operaties.
Binnen twee minuten — en ik wil dat benadrukken, twee minuten — convergerden alle drie agents op dezelfde oorzaak. Een stale closure in een useEffect-hook. Het effect legde een verouderde referentie vast naar de formulierstaat bij mount, en wanneer de indieningscallback vuurde, las het verouderde waarden onder specifieke timingomstandigheden.
Agent A vond het vanuit de React-kant. Agent C vond het vanuit de race condition-invalshoek. Agent B vond indirect bewijs door een indiening te volgen die succesvol was op de server maar verouderde gegevens toonde in de responshandler. Ze stuurden alle bevindingen naar de teamleider, die een uniforme diagnose presenteerde met een oplossing.
Praktijktest #3: Een Volledige App Bouwen Vanuit Één Prompt
Dit was de ambitieuze. Ik wilde zien of een agentteam een gedetailleerde prompt kon nemen en een werkende, meerpaginatoepassing kon produceren.
De prompt beschreef een projectbeheertool met vier pagina's: een dashboard, een projectlijstweergave, een gedetailleerde projectpagina met taakborden, en een instellingenpagina. Tech stack: Next.js 14 met App Router, Tailwind CSS en een SQLite-database via Drizzle ORM.
De teamleider analyseerde de prompt en nam een beslissing die ik niet verwachtte — het spawnte zes teamleden in plaats van de vier die ik zou hebben aangemaakt:
- Agent 1: Onderzoeksfase. Verifieer Next.js 14 App Router-patronen, controleer Drizzle ORM-syntaxis.
- Agent 2: Omgevingsinstallatie. Initialiseer het Next.js-project, configureer Tailwind, zet het databaseschema op.
- Agents 3-6: Bouw elk één pagina (dashboard, projectlijst, projectdetail, instellingen).
De onderzoeks- en installatieagents draaiden eerst. Agents 3-6 wachtten — gemarkeerd als geblokkeerd in de gedeelde takenlijst — totdat de basis klaar was.
Het totale proces verbruikte ongeveer 170.000 tokens. Dat is significant — ruwweg $8-12 afhankelijk van je prijsniveau. De uiteindelijke output was niet perfect, maar de app draaide. Alle vier pagina's werkten. De navigatie was consistent.
Best Practices Die Er Echt Toe Doen
Definieer de scope van agents expliciet
Dit is de allerbelangrijkste practice. Specificeer bestanden of functionele grenzen voor elke agent in je prompt. "Agent 1 bezit alles in /src/api/. Agent 2 bezit alles in /src/components/." Wanneer agents hun territorium kennen, dalen conflicten tot bijna nul.
Wijs écht onafhankelijke taken toe
De sweet spot zijn taken die grotendeels onafhankelijk zijn maar baat hebben bij occasionele communicatie. Verschillende API-routes bouwen die een gemeenschappelijk responsformaat delen. Verschillende UI-componenten bouwen die consistente styling nodig hebben.
Beheer het geduld van de teamleider
De teamleider wordt soms ongeduldig. Als een teamlid meer dan een minuut of twee nodig heeft voor een taak, besluit de teamleider soms "te helpen" door het werk zelf te doen. Mijn oplossing: in de initiële prompt geef ik de teamleider expliciet de instructie om te wachten op teamleden en geen taken zelf te implementeren. "Jouw rol is alleen coördinatie."
Grootte taken voor de sweet spot
Mijn vuistregel: elke taak van een teamlid moet twee tot acht minuten gefocust werk kosten. Kort genoeg zodat mislukkingen niet catastrofaal zijn. Lang genoeg zodat parallellisme echte tijdwinst oplevert.
Monitoor en wees bereid te interveniëren
Agentteams zijn experimenteel. Houd je terminal zichtbaar. Bekijk het berichtverkeer. Als een agent drie tot vier minuten niets heeft geproduceerd en geen berichten heeft gestuurd, is die waarschijnlijk vastgelopen.
De Cijfers Die Er Echt Toe Doen
Na ongeveer twee dozijn sessies met agentteams:
Bugonderzoekstijd: Gedaald van gemiddeld vijf tot tien minuten naar twee tot drie minuten.
Code review-cycli: Een review-en-herstelronde op een middelgrote codebase ging van ongeveer vijfentwintig minuten naar ruwweg tien minuten.
Tokenverbruik: Aanzienlijk hoger. Een enkele-agent-sessie voor een taak van gemiddelde complexiteit kan 30.000-50.000 tokens gebruiken. Hetzelfde met een agentteam gebruikt doorgaans 80.000-170.000 tokens.
Is het de moeite waard? Voor tijdkritisch werk waarbij mijn uurtarief de tokenkosten overtreft? Absoluut. Voor exploratief leren of projecten zonder deadlines? Een enkele agent is waarschijnlijk kosteneffectiever.
Wat Ik Aanvankelijk Fout Deed
Mijn grootste fout was agentteams behandelen als een snellere versie van sub-agents. Ze zijn niet hetzelfde. Sub-agents zijn tools. Agentteams zijn... een team. Met sub-agents geef je precieze instructies en verwacht je precieze output. Met agentteams stel je doelen en grenzen in en laat je het team de uitvoeringsdetails uitzoeken.
Ik onderschatte ook het belang van de initiële prompt. Met één agent kun je halverwege de sessie bijsturen. Met een agentteam sturen zes agents tegelijk in licht verkeerde richtingen als de initiële prompt slecht is afgebakend. Besteed twee extra minuten aan het opstellen van je prompt. Dat betaalt zich tienvoudig terug.
Waar Dit Naartoe Gaat
Agentteams zijn de eerste AI-codingtool die ik heb gebruikt die overeenkomt met hoe echte engineeringteams werken. Een tech lead die coördineert maar niet implementeert. Specialisten die specifieke domeinen bezitten. Communicatiekanalen voor overkoepelende kwesties. Gedeeld zicht op projectvoortgang.
De engineers die het meeste voordeel hebben zijn degenen die nu hun teambeheerskills opbouwen, terwijl de functie nog experimenteel is. Stel de omgevingsvlag in. Start twee teamleden. Kijk hoe ze met elkaar communiceren. Dat is het moment waarop het klikt.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur schalen? Ik help je graag.
- Fiverr (aangepaste builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
