Claude Code Agent Teams: Installatie, Tips en Praktijkvoorbeelden

Claude Code Agent Teams: Installatie, Tips en Praktijkvoorbeelden

Ik had een tokenbudget van $47 opgebrand in negentien minuten. Vier agents, allemaal draaiend op Opus 4.6, allemaal werkend aan dezelfde Next.js-codebase, allemaal tegelijkertijd layout.tsx aan het bewerken.

De orchestrator had het conflict niet gesignaleerd. De front-end agent overschreef de auth-wrapper van de back-end agent. De QA-agent testte een versie van het bestand die niet meer bestond. En de design-agent -- degene die ik had opgestart om "de UI op te poetsen" -- introduceerde een Tailwind-class die het responsive grid brak waar de front-end agent acht minuten aan had gebouwd.

Negentien minuten. Zevenenveertig dollar. Een codebase die slechter was dan toen ik begon.

Dat was februari 2026. Ik had net voor het eerst Claude Code agent teams ingeschakeld, en ik maakte elke fout waar de documentatie voor waarschuwt -- plus een paar die niet vermeld worden. Sindsdien heb ik agent teams ingezet op meer dan dertig echte projecten, van SaaS-dashboards tot API-migraties tot een contentpipeline die nu de blog aandrijft die je nu leest. De feature ging van "dure ramp" naar het krachtigste gereedschap in mijn ontwikkelworkflow.

Dit is de gids die ik had willen hebben toen ik begon. Niet de marketingversie. Niet de quickstart van drie alinea's. Het volledige plaatje -- installatie, configuratie, meer dan 30 hard bevochten tips, en de zes use cases waarin agent teams werkelijk beter presteren dan alles wat ik eerder heb geprobeerd.

Wat Agent Teams Eigenlijk Zijn (en Waarom Sub-Agents Niet Genoeg Zijn)

Voordat je aan welke configuratie dan ook begint, heb je een mentaal model nodig dat preciezer is dan "meerdere agents die samenwerken." Het verschil tussen sub-agents en agent teams is het verschil tussen freelancers inhuren en een team bouwen -- en die twee verwarren kost je echt geld.

Sub-agents zijn onafhankelijke Claude Code-instanties die door je hoofdsessie worden opgestart. Elk krijgt zijn eigen contextvenster. Elk voert zijn taak uit en rapporteert terug aan de parent. Het cruciale detail: sub-agents kunnen niet met elkaar praten. Ze rapporteren aan de orchestrator, punt. Als Agent A ontdekt dat het databaseschema een nieuwe kolom nodig heeft, weet Agent B dat pas als je die informatie handmatig doorgeeft.

Agent teams voegen een communicatielaag toe bovenop dit model. Teamgenoten kunnen berichten rechtstreeks naar elkaar sturen. De front-end agent kan de back-end agent vragen "welk formaat retourneert het /users-endpoint?" en krijgt een antwoord zonder via de orchestrator te hoeven gaan. Eén agent fungeert als teamleider -- coördinerend, delegerend, synthetiserend -- terwijl teamgenoten onafhankelijk werken maar verbonden blijven via berichtuitwisseling.

Hier is de analogie die het voor mij liet klikken: sub-agents zijn e-mail. Je stuurt instructies, ze sturen resultaten terug. Agent teams zijn Slack. Iedereen zit in hetzelfde kanaal, berichten stromen in realtime, en de projectleider houdt alles op koers.

De implicaties zijn praktisch en direct. Sub-agents werken perfect voor taken die daadwerkelijk onafhankelijk zijn -- linting draaien, documentatie genereren, tests scaffolden. Geen coördinatie nodig, geen context gedeeld, geen berichten uitgewisseld. Snel en goedkoop.

Agent teams schitteren wanneer het werk onderling afhankelijk is. Wanneer de front-end het API-contract moet kennen voordat fetch-calls worden gebouwd. Wanneer de QA-agent de daadwerkelijke componentstructuur nodig heeft om zinvolle tests te schrijven. Wanneer een databaseschemawijziging door het begrip van elke agent moet sijpelen.

Hierna loop ik het exacte installatieproces door, maar dit onderscheid moet elke beslissing die je vanaf nu neemt beïnvloeden. Als je taken geen coördinatie nodig hebben, zijn agent teams een dure manier om iets te doen wat sub-agents voor een fractie van de kosten aankunnen.

De Complete Installatie: Van Nul tot Draaiend Team

Agent teams staan nog steeds als experimenteel gemarkeerd in Claude Code per maart 2026. Dat betekent dat je moet opt-innen, en het gedrag van de feature kan veranderen tussen releases. Dit is de exacte volgorde die ik volg bij een schone installatie.

Stap 1: Schakel de Experimentele Vlag In

Open je Claude Code-instellingenbestand. Op macOS staat het in ~/.claude/settings.json. Voeg de experimentele agent teams-vlag toe:

{
  "experimental": {
    "agentTeams": true
  }
}

Je kunt ook de omgevingsvariabele CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 instellen als je liever het instellingenbestand niet aanraakt. Ik gebruik het instellingenbestand omdat het persistent is over terminalsessies heen zonder mijn shellprofiel te vervuilen.

Stap 2: Kies Je Weergavemodus

Deze beslissing heeft een groter effect op je workflow dan je zou verwachten. Agent teams ondersteunen twee weergavemodi:

Tmux split-pane modus geeft elke teamgenoot zijn eigen terminalpaneel. Je ziet alle agents tegelijkertijd werken, naast elkaar. Je kunt in elk paneel klikken en direct met die specifieke agent communiceren. Dit is mijn voorkeursinstellling voor complexe projecten -- de visuele feedback is onschatbaar.

Vereisten: tmux geïnstalleerd (brew install tmux op macOS), en je moet Claude Code starten vanuit een tmux-sessie. Begin met tmux new -s dev en start Claude Code vervolgens binnen die sessie.

In-process modus draait alles binnen één terminalvenster. Uitvoer van teamgenoten verschijnt inline, en je communiceert met agents via de leider. Minder visuele overhead, werkt overal, maar lastiger om bij te houden wat elke agent in realtime doet.

Configureer dit in je instellingen:

{
  "teammateMode": "tmux"
}

Opties zijn "tmux", "in-process", of "auto" (die standaard tmux kiest als het een tmux-sessie detecteert, anders in-process).

Een valkuil die mij parten speelde: split-pane modus werkt niet in de geïntegreerde terminal van VS Code, Windows Terminal of Ghostty. Als je een van die gebruikt, blijf dan bij in-process of schakel over naar een zelfstandige terminal. Ik gebruik iTerm2, dat ook split panes ondersteunt via zijn Python API -- installeer de it2 CLI en schakel de Python API in via de iTerm2-instellingen.

Stap 3: Definieer Teamrollen in Natuurlijke Taal

Dit is waar agent teams afwijken van traditionele orchestratieframeworks. Je schrijft geen configuratiebestanden voor elke agent. Je beschrijft je team aan de leidende agent in gewoon Nederlands (of Engels).

Hier is een echte prompt die ik gebruikte voor een recent SaaS-project:

I need a team of 4 agents for this project:

1. Lead (you) - Architecture decisions, task delegation, integration review
2. Frontend specialist - React, TypeScript, Tailwind, component architecture
3. Backend specialist - Node.js, Express, PostgreSQL, API design
4. QA specialist - Testing, validation, integration checks

Rules:
- Frontend and backend must agree on API contracts before building
- QA writes tests only after receiving the actual implementation
- Nobody touches files outside their domain without lead approval

De leidende agent start teamgenoten op basis van je beschrijving. Elke teamgenoot krijgt zijn eigen contextvenster (ruwweg 200K tokens per Opus 4.6) en zijn toegewezen specialisatie.

Stap 4: Wijs Modellen Strategisch Toe

Dit is de grootste kostenhendel die je hebt. Niet elke agent heeft Opus 4.6 nodig. Mijn standaard modeltoewijzing:

Een team van vier agents die allemaal op Opus draaien kost ruwweg 4x zoveel als een team met gemengde modellen. Het kwaliteitsverschil voor uitvoeringstaken -- React-componenten schrijven, CRUD-endpoints bouwen, tests scaffolden -- is verwaarloosbaar tussen Opus en Sonnet. Bewaar Opus voor het denkwerk dat het daadwerkelijk vereist.

Stap 5: Plan Voordat Je Uitvoert

Dit is niet onderhandelbaar. Voordat het team ook maar één regel code schrijft, gebruik je de planmodus om het werk in kaart te brengen. Planmodus is goedkoop -- het is één agent die de aanpak doordenkt. Uitvoeringsmodus met een volledig team is duur -- het zijn vier agents die parallel tokens verbruiken.

Mijn workflow: activeer planmodus met de leidende agent, krijg een complete taakverdeling en architectuurplan, bekijk het, pas het aan, en schakel dan pas over naar uitvoering met het volledige team. Dit creëert een checkpoint voordat je echte tokens inzet.

Zie het zo: planmodus is de architecturale blauwdruk. Uitvoering met het agent team is de bouwploeg. Je zou geen bouwploeg naar een locatie sturen zonder blauwdrukken. Zelfde principe, ander medium.

30+ Tips Die Me Duizenden aan Tokens Hebben Bespaard

Ik verzamel deze sinds februari. Sommige komen voort uit mijn eigen dure fouten. Andere uit patronen die me opvielen over tientallen projecten heen. Ik heb ze per categorie gegroepeerd, want een platte lijst van 30 items is onmogelijk om naar te handelen.

Teamsamenstelling

1. Begin met 3 agents, niet 5. De coördinatie-overhead tussen agents schaalt niet-lineair. Drie agents kunnen efficiënt coördineren. Vijf agents besteden een aanzienlijk percentage van hun tokens alleen al aan onderlinge communicatie. Ik begin elk project met drie en voeg pas een vierde toe als de werklast dat duidelijk vereist.

2. Elke agent heeft een duidelijke domeingrens nodig. "Front-end agent" is duidelijk. "Helper agent" is dat niet. Als je het domein van een agent niet in één zin kunt beschrijven, is de rol niet goed genoeg gedefinieerd en zal de agent het terrein van andere agents betreden.

3. De leidende agent moet je duurste model zijn. De leider neemt architectuurbeslissingen, lost conflicten tussen teamgenoten op en behoudt het holistische beeld van het project. Goedkoop denken hier veroorzaakt dure fouten overal elders.

4. Stem modelcapaciteit af op taakcomplexiteit. Het schrijven van unit tests vereist geen Opus-niveau redenering. Het ontwerpen van een databaseschema met complexe relaties wel. Wijs modellen toe op basis van de cognitieve eisen van de rol, niet met een pauschal "alles krijgt het beste model."

5. Maak geen team aan voor sequentieel werk. Als Taak B niet kan starten voordat Taak A klaar is, heb je geen twee agents nodig -- je hebt één agent nodig die twee dingen doet. Agent teams renderen wanneer taken parallel kunnen draaien.

Taakplanning

6. Beperk taken tot 5-6 per agent. Dit is volgens mij de sweet spot. Minder dan 3 en je onderbent de agent. Meer dan 7 en de agent verliest het overzicht over zijn eigen voortgang, begint werk te herhalen of vergeet eerdere beslissingen.

7. Schrijf taakbeschrijvingen alsof je een nieuwe aannemer briefeert. Vermeld wat er gebouwd moet worden, welke beperkingen gelden, welke bestanden aangeraakt mogen worden en welke bestanden vermeden moeten worden. Vage taken produceren vage resultaten -- en die resultaten kosten tokens om te repareren.

8. Definieer succescriteria voor elke taak. "Bouw het auth-systeem" is vaag. "Bouw JWT-gebaseerde auth met refresh tokens, die een 401 retourneert voor verlopen tokens en rolgebaseerde toegang ondersteunt voor admin/user/viewer-rollen" vertelt de agent precies wanneer hij klaar is.

9. Plan de integratiepunten voordat je het werk opsplitst. De leidende agent moet een gedeeld contract produceren -- API-schema's, databasemodellen, type-definities, eventformaten -- voordat een teamgenoot begint met bouwen. Dit elimineert het merendeel van de integratieproblemen.

10. Laad het denkwerk vooraan, het bouwwerk achteraan. Besteed 20% van je sessie aan planning en 80% aan uitvoering. De meeste mensen keren deze verhouding om en betalen ervoor in herwerk.

Communicatie en Context

11. Context delen is beperkt tot berichtenuitwisseling. Agents delen geen geheugen of contextvensters. Als Agent A iets ontdekt dat Agent B moet weten, moet die informatie expliciet als bericht worden verzonden. Niets gaat automatisch.

12. Voorzie teamgenoten vooraf van cruciale context. Wanneer je teamrollen definieert, neem dan de belangrijkste architectuurbeslissingen, tech stack en beperkingen op in de initiële prompt. Elke token besteed aan contextseding bespaart tien tokens aan verward agentgedrag later.

13. Stel expliciete communicatieprotocollen in. Laat agents niet vrij met elkaar berichten. Definieer overdrachtspunten: "Front-end agent stuurt API-verwachtingen naar back-end agent voordat fetch-calls worden geschreven." "Back-end agent deelt het definitieve endpoint-contract met QA voordat tests worden geschreven." Structuur voorkomt ruis.

14. Gebruik de leidende agent als router, niet als knelpunt. De leider moet delegeren en reviewen, niet elk bericht tussen teamgenoten doorsturen. Directe agent-naar-agent-berichtenuitwisseling bestaat niet voor niets -- als alle communicatie via de leider loopt, heb je het sub-agent model nagebouwd maar dan met meer overhead.

15. Houd berichten tussen agents beknopt. Een agent die zijn volledige code-output naar een andere agent stuurt, verspilt tokens aan beide kanten. Berichten moeten beslissingen, contracten en interfacedefinities bevatten -- geen volledige implementaties.

Bestands- en Conflictbeheer

16. Laat nooit twee agents tegelijkertijd hetzelfde bestand bewerken. Dit is de fout die me $47 kostte in negentien minuten. Bestandsconflicten in agent teams zijn stil -- er is geen merge conflict-dialoog. De ene agent overschrijft simpelweg het werk van de andere. Wijs bestandseigenaarschap expliciet toe.

17. Maak een bestandseigenaarschapskaart. Voordat de uitvoering begint, moet de leidende agent een duidelijke mapping produceren: "Front-end agent is eigenaar van alles in /src/components en /src/hooks. Back-end agent is eigenaar van /src/api en /src/db. QA is eigenaar van /tests." Grijze gebieden veroorzaken botsingen.

18. Gebruik een gedeelde types- of contractenmap. Ik maak een /src/shared- of /src/contracts-map aan waar zowel de front-end als de back-end agent uit leest, maar die alleen de leidende agent beschrijft. Dit voorkomt contractdrift.

19. Als een agent het bestand van een andere agent moet wijzigen, routeer dan via de leider. De leider beoordeelt de wijziging, bevestigt dat het niet conflicteert, en maakt de wijziging zelf of geeft de aanvragende agent expliciet toestemming om door te gaan. Dit voegt een paar seconden latency toe, maar voorkomt minuten debuggen.

Kostenbeheer

20. Monitor tokengebruik actief, niet passief. Wacht niet tot de sessie afgelopen is om je rekening te bekijken. Claude Code toont tokenverbruik in realtime. Als een agent sneller tokens verbrandt dan verwacht, is er iets mis -- waarschijnlijk zit hij in een lus of genereert hij buitensporig veel output.

21. Beëindig inactieve agents onmiddellijk. Een agent die klaar is met zijn taken maar nog steeds draait, verbruikt nog steeds middelen. De orchestrator handelt opruiming af, maar ik heb agents minutenlang inactief zien staan voordat ze werden beëindigd. Handmatige afsluiting is sneller en goedkoper.

22. Gebruik sub-agents voor onafhankelijke taken, teams voor onderling afhankelijke. Ik kan dit niet genoeg benadrukken. Vier coördinerende agents inzetten voor vier onafhankelijke taken is als een vergadering plannen die vier e-mails had kunnen zijn. Gebruik sub-agents voor geïsoleerd werk. Bewaar agent teams voor werk dat daadwerkelijk coördinatie vereist.

23. Bundel gerelateerde taken. In plaats van voor elke kleine taak een nieuwe agent op te starten, groepeer je gerelateerde taken onder één agent. Een agent die "bouw alle drie de API-endpoints voor gebruikersbeheer" afhandelt, is efficiënter dan drie agents die elk één endpoint bouwen.

24. Maak een kostenraming voordat je begint. Snelle rekensom: een team van 3 agents dat 30 minuten draait op Opus 4.6 verbruikt ruwweg 200K-300K tokens. Tegen de huidige prijzen is dat $15-25. Met een team met gemengde modellen (één Opus, twee Sonnet) kost dezelfde sessie $6-10. Ken je cijfers voordat je begint.

Monitoring en Bijsturing

25. Check elke 10-15 minuten in. Agent teams zijn niet instellen-en-vergeten. Ik bekijk de voortgang op regelmatige intervallen, vang drift vroeg op en pas taaktoewijzingen aan als de ene agent geblokkeerd is terwijl een andere niets te doen heeft.

26. Je kunt direct met elke teamgenoot communiceren. In tmux split-pane modus klik je in het paneel van een agent en geef je directe instructies. Je bent niet beperkt tot communicatie via de leider. Wanneer ik merk dat een specifieke agent de verkeerde kant opgaat, grijp ik direct in in plaats van de correctie via de orchestrator door te sturen.

27. Gebruik hooks voor levenscyclusgebeurtenissen. Claude Code ondersteunt hooks die afgaan wanneer teamgenoten inactief worden, taken voltooien of fouten tegenkomen. Ik heb deze gekoppeld aan Slack-notificaties zodat ik een ping krijg wanneer een agent klaar is of vastloopt -- geen noodzaak om constant de terminal in de gaten te houden.

28. Let op oneindige lussen. Af en toe raken twee agents in een pingpongpatroon -- Agent A stelt Agent B een vraag, Agent B antwoordt met een tegenvraag, en ze blijven heen en weer gaan. Als je tokenverbruik ziet pieken zonder zichtbare voortgang, grijp dan onmiddellijk in.

Levenscyclus en Opruiming

29. Agents stoppen automatisch als hun takenwachtrij leeg is. De orchestrator beheert het afsluiten, maar de timing is niet altijd onmiddellijk. Als je klaar bent met de sessie, vertel de leidende agent dan expliciet om af te ronden.

30. Eén team per sessie. Een leidende agent kan slechts één team tegelijk beheren. Als je een andere teamsamenstelling nodig hebt voor een ander project, start dan een nieuwe sessie.

31. Teamgenoten kunnen geen eigen teams opzetten. De hiërarchie is plat: één leider, meerdere teamgenoten. Geen subteams, geen recursieve orchestratie. Als je project dat niveau van nesting nodig heeft, ben je waarschijnlijk beter af met meerdere onafhankelijke sessies.

32. Ruim agentprocessen op na crashes. Als een sessie halverwege een team crasht, kunnen verweesde agentprocessen blijven hangen. Controleer op achtergebleven processen en beëindig ze handmatig. Dit voorkomt zowel verspilling van middelen als mogelijke conflicten wanneer je een nieuwe sessie start.

33. Documenteer wat werkte. Na elke teamsessie besteed ik twee minuten aan het noteren welke modeltoewijzingen, teamgroottes en communicatiepatronen het beste werkten voor dat projecttype. Deze bibliotheek van templates stelt me nu in staat om geoptimaliseerde teams in minder dan drie minuten op te zetten.

Zes Use Cases Waarin Agent Teams Solo Agents Verpletteren

Theorie is prima. Wat echt telt, is weten wanneer je dit gereedschap moet inzetten. Na meer dan dertig projecten rechtvaardigen deze zes scenario's consequent de coördinatie-overhead.

1. Full-Stack Applicatieontwikkeling

Dit is de canonieke use case, en hij levert daadwerkelijk. Drie agents -- architectuurleider, front-end specialist, back-end specialist -- parallel werkend aan een gedeelde codebase. De leider produceert eerst het API-contract, beide implementatie-agents bouwen tegelijkertijd tegen dat contract, en integratieproblemen komen aan het licht via agent-naar-agent-berichtenuitwisseling in plaats van achteraf debuggen.

Bij een recent project -- een multi-tenant dashboard met rolgebaseerde toegang en realtime WebSocket-updates -- leverde het agent team in 35 minuten wat een solo agent bijna 90 minuten zou hebben gekost. Niet omdat de agents sneller typten, maar omdat de front-end agent componenten bouwde terwijl de back-end agent endpoints bouwde. Echte parallelle uitvoering op onderling afhankelijk werk.

De sleutel: het contract-first patroon dat ik beschreef in tip #9 is hier verplicht. Zonder een gedeeld API-contract bouwen de agents op aannames die onmiddellijk uiteenlopen.

2. Code Review met Gespecialiseerde Lenzen

Deze use case verraste me met hoe goed hij werkt. Wijs drie agents toe om dezelfde PR te reviewen, elk met een andere focus: beveiligingskwetsbaarheden, prestatieknelpunten en testdekkingslacunes. Elke agent bekijkt de code door zijn gespecialiseerde lens en produceert een gericht rapport. De leidende agent synthetiseert de drie rapporten tot één review.

Het resultaat is grondiger dan welke single-pass review dan ook, en de gespecialiseerde focus zorgt ervoor dat elke agent dingen opvangt die een generalist zou missen. Een op beveiliging gerichte agent signaleerde een SQL-injectievector in een geparametriseerde query die er op het eerste gezicht correct uitzag -- de parameter-escaping kon niet omgaan met array-invoer. Een op prestatie gerichte agent ving een N+1 query op die verscholen zat achter een ORM-abstractie. Geen van beide bevindingen zou aan het licht zijn gekomen bij een standaard review.

De kosten voor een code review met drie agents liggen rond de $3-5 aan tokens. Voor kritieke PR's is dat een koopje.

3. Debuggen met Concurrerende Hypotheses

Wanneer een bug meerdere mogelijke oorzaken heeft, is de traditionele aanpak sequentieel: onderzoek hypothese A, als het dat niet is, probeer hypothese B. Agent teams laten je alle hypotheses tegelijkertijd onderzoeken.

Ik had een productieprobleem waarbij API-responstijden elke paar uur van 200ms naar 3 seconden sprongen. Drie mogelijke oorzaken: uitputting van de database connection pool, een geheugenlek in een achtergrondworker, of een upstream service die throttlet. Ik wees elke hypothese toe aan een andere agent en liet ze parallel onderzoeken. Twintig minuten later vond Agent C de upstream throttling -- een rate limit op een geocoding API die niemand had gedocumenteerd. De andere twee agents vonden geen bewijs voor hun hypotheses, wat even waardevol was omdat het twee dagen potentieel zinloos zoeken elimineerde.

4. Schrijf- en Redactieworkflows

Deze sluit direct aan op de contentpipeline die ik gebruik voor deze blog. Drie agents met verschillende rollen: onderzoeker (verzamelt bronnen, datapunten, actuele informatie), schrijver (produceert het concept volgens huisstijl en structuur), en redacteur (reviewt op kwaliteit, nauwkeurigheid, consistentie en SEO).

De onderzoeker is als eerste klaar en geeft zijn bevindingen door aan de schrijver. De schrijver produceert het concept en draagt het over aan de redacteur. De redacteur reviewt en stuurt revisienota's terug. Deze sequentiële-met-communicatie-flow produceert merkbaar betere output dan een enkele agent die tegelijkertijd probeert te onderzoeken, schrijven en zelf-redigeren -- omdat elke agent zich op één cognitieve taak concentreert zonder context te wisselen.

5. Parallel Onderzoek en Verkenning

Wanneer je meerdere tools, benaderingen of architecturen moet evalueren voordat je een beslissing neemt, laten agent teams je alle paden tegelijkertijd verkennen. Ik gebruikte dit bij het evalueren van drie verschillende state management-benaderingen voor een React-project -- één agent testte Zustand, één testte Jotai, één testte de native React Context API. Elke agent bouwde een klein proof-of-concept, documenteerde de afwegingen en rapporteerde terug aan de leider.

De cruciale regel voor onderzoekstaken: houd de agents read-only tijdens de verkenningsfase. Laat ze code lezen, benchmarks draaien en wegwerpprototypes schrijven -- maar laat ze de hoofdcodebase niet wijzigen totdat de leider de bevindingen heeft beoordeeld en een richting heeft gekozen. Anders krijg je drie verschillende benaderingen half-geïmplementeerd in je productiecode.

6. Cross-Platform Feature Pariteit

Als je dezelfde feature op meerdere platformen uitrolt -- iOS en Android, web en mobiel, of zelfs verschillende microservices die gesynchroniseerd gedrag nodig hebben -- behouden agent teams pariteit doordat elke platformagent zijn implementatiedetails deelt met de anderen. Wanneer de Android-agent een datumopmaakfunctie implementeert, stuurt hij de iOS-agent een bericht met de exacte format string zodat beide platformen identieke output produceren.

Ik heb dit pas twee keer gebruikt, maar beide keren werden er afwijkingen opgemerkt die gebruikerszichtbare bugs zouden zijn geworden. De coördinatie-overhead is hoog voor dit patroon, dus ik raad het alleen aan voor features waar platforminconsistentie een serieus probleem zou zijn -- betaalstromen, dataserialisatie, alles waar "licht afwijkend gedrag op iOS vs Android" een supportticket betekent.

De Workflowfasen: Hoe een Sessie Werkelijk Verloopt

Voor wie het complete plaatje wil, hier is hoe een typische agent teamsessie verloopt van begin tot eind. Ik gebruik een echt voorbeeld -- het bouwen van een interne tool voor het bijhouden van de contentpipelinestatus.

Fase 1 -- Initialisatie. Ik open een tmux-sessie, start Claude Code en controleer of de experimentele agents-vlag actief is. Ik beschrijf het project in detail aan de leidende agent: de tech stack (Next.js 15, Prisma, PostgreSQL), de vereisten (dashboard dat contentstatus, auteurstoewijzingen en publicatiedatums toont), en de beperkingen (moet integreren met het bestaande auth-systeem, mag het gedeelde databaseschema niet wijzigen).

Fase 2 -- Teamcreatie. Ik vertel de leidende agent welk team ik nodig heb. In dit geval: een front-end agent voor de dashboard-UI, een back-end agent voor de API-laag en databasequery's, en een QA-agent. De leider start drie teamgenoten op, die elk in hun eigen tmux-paneel verschijnen. Ik kan alle vier de agents tegelijkertijd zien.

Fase 3 -- Taakplanning. Voordat iemand code schrijft, produceert de leidende agent een taakplan. Het beschrijft elk op te leveren onderdeel, wijst taken toe aan specifieke agents, definieert het API-contract tussen front-end en back-end, en stelt de integratietestcriteria vast. Ik beoordeel dit plan, pas twee taaktoewijzingen aan die niet logisch waren, en keur het goed.

Fase 4 -- Parallelle Uitvoering. De agents gaan aan de slag. Front-end begint met het bouwen van de dashboardcomponenten. Back-end creëert het Prisma-schema en de API-routes. Ik kan de voortgang van beide agents in realtime volgen via de tmux-panelen. Wanneer de front-end agent verduidelijking nodig heeft over de responsevorm van het /content-endpoint, stuurt hij de back-end agent direct een bericht.

Fase 5 -- Monitoring en Bijsturing. Na ongeveer twaalf minuten merk ik dat de front-end agent een complex filtercomponent bouwt dat niet in de specificatie stond. Ik klik in zijn paneel en stuur bij: "Sla de geavanceerde filters voorlopig over. Focus op het statusbord en de auteursweergave." De agent past zich onmiddellijk aan.

Fase 6 -- Integratie en QA. Zodra beide implementatie-agents aangeven dat ze klaar zijn, activeert de QA-agent. Hij leest de front-end componenten en back-end endpoints, schrijft integratietests en voert ze uit. Twee mislukkingen: een datumopmaakafwijking en een ontbrekende error boundary. De QA-agent rapporteert deze aan de betreffende agents, die ze in minder dan twee minuten oplossen.

Fase 7 -- Samenvatting en Opruiming. De leidende agent stelt een samenvatting samen: wat er is gebouwd, welke tests slagen, wat er nog openstaat. Ik beoordeel de output, bevestig dat alles werkt en sluit de sessie af. Totale tijd: 28 minuten. Totale tokenkosten met de gemengde-model opzet: ruwweg $8.

De hele reeks voelde minder als "een tool gebruiken" en meer als het aansturen van een klein ontwikkelteam. Wat, in een betekenisvolle zin, precies is wat het is.

De Eerlijke Afwegingen Waar Niemand Over Praat

Ik zou je een slechte dienst bewijzen als ik agent teams als universeel superieur zou afschilderen. Dat zijn ze niet. Dit is wat ik heb geleerd over hun werkelijke beperkingen na maanden dagelijks gebruik.

Kosten schalen lineair, maar waarde niet. Drie agents kosten drie keer zoveel als één. Maar ze leveren niet altijd drie keer de waarde. Voor projecten met matige complexiteit -- de meeste CRUD-apps, de meeste single-page tools, de meeste scripts -- is een solo agent sneller, goedkoper en produceert output die makkelijker te debuggen is omdat één brein het heeft geschreven.

Berichtenuitwisseling is geen gratis context delen. Agents kunnen berichten naar elkaar sturen, maar die berichten verbruiken tokens aan zowel de verzendende als de ontvangende kant. Zware communicatie tussen agents kan meer kosten dan het daadwerkelijke programmeren. Ik heb sessies gezien waarin 30% van het totale tokenverbruik inter-agent berichten was.

De orchestrator is een single point of failure. Als de leidende agent in de war raakt over de projectstatus -- en dat gebeurt -- drijft het hele team af. Het contextvenster van de leider is eindig, en het bijhouden van de status van vijf teamgenoten over tientallen taken kan zelfs Opus 4.6 overweldigen. Daarom beperk ik teams tot 3-4 agents en taken tot 5-6 per agent.

Teamoutput debuggen is lastiger dan solo-output debuggen. Wanneer iets kapot is in de output van een solo agent, weet je wie het heeft geschreven. Wanneer iets kapot is in de output van een team, moet je achterhalen welke agent de problematische code heeft geproduceerd, welke context hij had toen hij die beslissing nam, en of het bericht van een andere agent de keuze heeft beïnvloed. De impact van een fout is groter.

De feature is nog steeds experimenteel. Sessiehervatting is onbetrouwbaar. Het afsluiten van teamgenoten verloopt niet altijd schoon. Tmux-paneelindexering kan breken als je configuratie niet-standaard basisindices gebruikt. Dit zijn ruwe randjes, en ze zijn het tolereren waard voor complexe projecten -- maar ze betekenen dat agent teams nog geen productieklaar gereedschap zijn. Het is een power feature voor mensen die bereid zijn de wrijving te beheren.

Dit is mijn eerlijke standpunt na drie maanden: agent teams zijn de juiste keuze voor misschien 15-20% van de projecten waar ik aan werk. Maar voor die 15-20% zijn ze dramatisch beter dan het alternatief. De vaardigheid is weten welke 15-20%.

Als je liever hebt dat iemand dit soort multi-agent workflow voor je project bouwt en configureert, neem ik custom AI-automatiseringsprojecten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Hoe Ik Zou Beginnen Als Ik Dit Vandaag Zou Opzetten

Als ik terug kon gaan naar februari en mezelf een vijfstappenplan kon overhandigen, is dit wat ik zou geven.

Eerste sessie: solo agent, alleen planmodus. Raak agent teams niet aan. Bouw je projectplan met één enkele Claude Code-instantie. Krijg de architectuur goed, definieer de API-contracten, breng de bestandsstructuur in kaart. Dit kost bijna niets en produceert de blauwdruk die je team zal uitvoeren.

Tweede sessie: twee agents, één kleine taak. Start een leider en één teamgenoot op. Geef ze een afgebakend, laagrisico onderdeel van het project -- een enkele feature met duidelijke grenzen. Kijk hoe de communicatie verloopt. Leer de tmux-interface kennen. Word vertrouwd met het ritme.

Derde sessie: drie agents, echt werk. Nu weet je genoeg om effectief te zijn. Leider op Opus, twee teamgenoten op Sonnet, duidelijke domeingrenzen, gedeelde contracten, 5-6 taken per agent. Dit is je productie-opzet voor 90% van de teamwaardige projecten.

Elke sessie daarna: verfijn je templates. Documenteer welke modeltoewijzingen, teamgroottes en communicatiepatronen werken voor elk projecttype. Na tien sessies heb je een bibliotheek van teamtemplates die het opzetten bijna instant maakt.

Het enige wat ik zou veranderen: Ik zou beginnen met het lezen van de officiële Anthropic-documentatie over agent teams op code.claude.com/docs/en/agent-teams in plaats van te leren door vallen en opstaan. De documentatie is oprecht goed -- hij bestond alleen nog niet toen ik begon te experimenteren.

De grootste verschuiving in mijn denken over deze drie maanden gaat niet over de technologie. Het gaat over de rol. Wanneer ik agent teams gebruik, stop ik met een ontwikkelaar te zijn die AI gebruikt en word ik een technisch leider die AI-ontwikkelaars aanstuurt. De vaardigheden die ertoe doen veranderen: helder requirements schrijven, taakdecompositie, voortgangsmonitoring, integratieplanning. Dezelfde vaardigheden die een goede engineering manager maken, maken een goede agent team-operator.

Je terminal is geen teksteditor meer. Het is een commandocentrum. En de agents wachten op orders.

Veelgestelde Vragen

Hoe schakel ik Claude Code agent teams in?

Voeg "agentTeams": true toe aan het "experimental"-gedeelte van ~/.claude/settings.json, of stel de omgevingsvariabele CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in. Je hebt een Claude Pro- of Max-abonnement nodig met toegang tot Opus 4.6 voor de rol van leidende agent.

Hoeveel agents moet ik gebruiken in een Claude Code-team?

Begin met 3 teamgenoten voor de meeste projecten -- één leider, twee specialisten. Drie agents balanceren parallelle doorvoer tegen coördinatie-overhead. Teams van 5 of meer besteden een onevenredig groot deel van de tokens aan inter-agent berichtenuitwisseling. Zie de tips over Teamsamenstelling hierboven voor een uitgebreidere uiteenzetting.

Kosten Claude Code agent teams meer dan sub-agents?

Ja. Een team van 3 agents verbruikt ruwweg 3-4x de tokens van een enkele sessie die hetzelfde werk doet. Je kunt kosten verlagen door goedkopere modellen (Sonnet 4.5 of Haiku) toe te wijzen aan uitvoeringsgerichte teamgenoten terwijl je Opus op de leider houdt. Agent teams zijn alleen kosteneffectief wanneer de complexiteit van het project daadwerkelijk realtime coördinatie vereist.

Kunnen Claude Code-teamgenoten hetzelfde bestand bewerken?

Dat kunnen ze, maar dat moeten ze absoluut niet doen. Agent teams hebben geen merge conflict-detectie -- de ene agent overschrijft stilletjes de wijzigingen van de andere. Wijs expliciet bestandseigenaarschap toe aan elke agent voordat de uitvoering begint, en routeer alle cross-domain bestandswijzigingen via de leidende agent.

Wat is het verschil tussen agent teams en sub-agents in Claude Code?

Sub-agents zijn geïsoleerde werkers die resultaten teruggeven aan de bovenliggende sessie -- geen onderlinge communicatie. Agent teams voegen directe berichtenuitwisseling toe tussen teamgenoten, wat realtime coördinatie op onderling afhankelijke taken mogelijk maakt. Gebruik sub-agents voor onafhankelijk parallel werk, agent teams voor samenwerkend werk dat gedeelde context vereist.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io