Claude Code Agent Teams: Het Draaiboek Waar Ik Weken Over Deed

Claude Code Agent Teams: Het Draaiboek Waar Ik Weken Over Deed

De QA-agent vond elf bugs. Elf. Bij de eerste controle. Ik had net twee andere agents bekeken — een front-end developer en een back-end developer — die vier minuten besteedden aan het bouwen van een landingspagina voor een fictieve AI-startup genaamd Neuroflow. Tekst, animaties, kleurenschema's, responsieve lay-out, API-endpoints. Alles draaide parallel, elke agent werkte in zijn eigen Claude Code-sessie terwijl ik keek hoe de terminal opdeelde in kleurgecodeerde panelen. De front-end agent leverde zijn werk in. De back-end agent leverde zijn werk in. En toen haalde de QA-agent ze allebei onderuit. Ontbrekende hover-states. Een API-endpoint dat data retourneerde in een formaat dat de front-end niet verwachtte. Een kleurcontrastratio die niet voldeed aan WCAG-standaarden. Een animatie die afvuurde voordat de content geladen was, waardoor een flits van ongestileerde tekst verscheen. Dit is het deel dat mij volledig stilzette: ik hoefde niets te doen. De QA-agent meldde zijn bevindingen, tagde de verantwoordelijke agents, en beide developers pakten de fixes onmiddellijk op. Bij de tweede controle keurde QA alles goed. De uiteindelijke landingspagina zag eruit alsof een klein designteam er een week aan had besteed. Dat was het moment waarop ik begreep wat Claude Code agent teams werkelijk zijn. Geen feature. Geen instelling die je aan- of uitzet. Een fundamenteel andere manier van software bouwen met AI — een waarbij de agents niet alleen taken uitvoeren, maar samenwerken, discussiëren en elkaar verantwoordelijk houden. En om bij dat moment te komen waren weken van pijnlijk experimenteren nodig die ik nu ga samenvatten in dit artikel. Want hier is wat niemand je vertelt over agent teams: de feature is eenvoudig in te schakelen. Het zo ver krijgen dat het resultaten oplevert zoals ik zojuist beschreef? Daar falen de meeste mensen. Het verschil tussen een goed georkestreerd agent team en een chaotisch token-vuur komt neer op hoe je prompt, hoe je rollen structureert, en hoe je omgaat met de tientallen dingen die mis kunnen gaan. Ik heb meer tokens verbruikt om dit uit te zoeken dan ik graag zou willen toegeven. Dit is het draaiboek dat ik wenste dat bestond toen ik begon.

Waarom Agent Teams Bestaan (En Waarom Sub Agents Niet Genoeg Zijn)

Als je Claude Code's sub agents hebt gebruikt, ken je het verhaal al: start onafhankelijke agents, laat ze parallel werken, verzamel resultaten. Snel, goedkoop, effectief voor afgebakende taken. Ik gebruik sub agents nog dagelijks voor dingen als "analyseer deze codebase en lijst elk API-endpoint op" of "schrijf unit tests voor deze module." Ze zijn perfect wanneer het werk geïsoleerd is. Het probleem ontstaat op het moment dat werk niet geïsoleerd is. Ik leerde dit op de dure manier terwijl ik een dashboard-applicatie bouwde. Eén sub agent deed de React front-end. Een andere bouwde de Express API. Een derde schreef de database-laag. Alle drie draaiden ze tegelijkertijd — en alle drie namen ze onafhankelijke beslissingen die elkaar tegenspraken. De front-end agent verwachtte gepagineerde responses. De API-agent retourneerde alles in één enkele payload. De database-agent bouwde queries geoptimaliseerd voor een paginatiepatroon waar geen van de andere agents van wist. Drie briljante stukken software die niet met elkaar konden communiceren. Ik besteedde meer tijd aan het aan elkaar knopen dan de agents aan het bouwen. Sub agents zijn parallel maar doof. Ze kunnen elkaar geen vragen stellen. Ze kunnen geen API-contract onderhandelen. Ze kunnen niet zeggen "let op, ik heb het responseformaat voor het /users endpoint gewijzigd." Elk van hen werkt in een verzegeld context window, rapporteert terug aan de hoofdagent, en dat is het. De hoofdagent wordt een bottleneck — elk stuk coördinatie moet erdoorheen. Agent teams lossen dit op met een compleet andere architectuur. Drie componenten maken het mogelijk: De teamleider — je hoofd Claude Code-sessie. Die begrijpt het volledige plaatje, breekt de missie op, wijst domeinen toe en coördineert de integratie. Zie het als de tech lead die niet alle code schrijft maar ervoor zorgt dat iedereen hetzelfde product bouwt. Teamgenoten — aparte Claude Code-instanties, elk met hun eigen volledige context window. Ze draaien parallel en zijn eigenaar van specifieke domeinen. De front-end agent denkt alleen aan front-end zaken. De back-end agent focust volledig op API-logica. Geen contextvervuiling tussen hen. Direct messaging — en dit is het cruciale verschil. Teamgenoten kunnen met elkaar communiceren zonder alles via de teamleider te routeren. De front-end agent kan de back-end agent direct vragen: "Welk formaat gebruikt de /users response?" De back-end agent antwoordt. Het werk gaat verder. Geen bottleneck. Toen ik dit voor het eerst zag werken, was de vergelijking die in me opkwam niet technisch — maar organisatorisch. Sub agents zijn als het e-mailen van drie freelancers in drie verschillende landen. Agent teams zijn als het plaatsen van die freelancers in een gezamenlijk Slack-kanaal. Hetzelfde talent, radicaal ander coördinatievermogen. Maar meer coördinatie betekent ook meer complexiteit, meer tokens en meer manieren om het te verprutsen. De setup is enorm belangrijk — en de meeste gidsen die ik heb gelezen slaan de delen over die daadwerkelijk succes of falen bepalen.

Agent Teams Opzetten: De Configuratie Die Werkelijk Werkt

Agent teams zijn experimenteel per maart 2026 en standaard uitgeschakeld. Anthropic heeft dit uitgebracht als een onderzoekspreview met Claude Code v2.1.32, wat je twee dingen vertelt: het is krachtig genoeg om uit te brengen, en ruw genoeg dat ze willen dat je weet waar je aan begint. Stap 1: Schakel de feature in. Open de settings.local.json van je project (of je globale Claude Code-instellingenbestand) en voeg dit toe:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Herstart Claude Code. Dat is het voor de technische setup. De feature flag geeft Claude toegang tot teamcoördinatie-tools — teamgenoten aanmaken, taken toewijzen, inter-agent berichten versturen en een gedeelde takenlijst beheren. Stap 2: Installeer tmux (sterk aanbevolen). Je hebt tmux niet strikt nodig, maar agent teams draaien zonder tmux is als rijden zonder dashboard. Tmux laat je de terminalsessie van elke agent tegelijkertijd zien — kleurgecodeerd per rol, real-time bijgewerkt. Op macOS:

brew install tmux

Wanneer agent teams actief zijn en tmux geïnstalleerd is, splitst Claude Code automatisch je terminal in panelen voor elke teamgenoot. Je kunt de front-end agent JSX zien schrijven in het ene paneel terwijl de back-end agent Express routes opzet in het andere. Het is oprecht fascinerend en praktisch nuttig — je kunt coördinatiefouten opmerken terwijl ze gebeuren in plaats van ze te ontdekken in het eindresultaat. Stap 3: Train je Claude Code-project. Dit is de stap die de meeste tutorials overslaan, en het is de stap die voor mij het grootste verschil maakte. Voordat je je eerste agent team draait, importeer de agent teams-documentatie in je projectcontext. Ik haalde de kernconcepten uit Anthropic's agent teams docs naar het CLAUDE.md-bestand van mijn project — specifiek de secties over bestandseigendomsregels, communicatieprotocollen en taakafhankelijkheidsbeheer. Waarom is dit belangrijk? Wanneer Claude teamgenoten spawnt, begint elk van hen met een verse context. Ze kennen niet automatisch de best practices voor agent team-coördinatie. Maar als die practices in je CLAUDE.md staan, leest elke teamgenoot ze bij initialisatie. Het verschil in coördinatiekwaliteit is onmiddellijk en dramatisch. Dit is de sectie die ik heb toegevoegd aan mijn CLAUDE.md:

## Agent Team Rules
- Each teammate owns specific files. Never modify files owned by another agent.
- Always communicate API contracts before implementation begins.
- QA agent must receive final output from all other agents before running checks.
- Save progress to temporary files after each major milestone.

Vier regels. Ze voorkomen ongeveer 80% van de coördinatiefouten die ik tegenkwam in mijn eerste twee weken. Stap 4: Keur veelgebruikte commando's vooraf goed. Agent-teamgenoten erven rechten van de hoofdsessie. Standaard pauzeren ze en vragen ze toestemming elke keer dat ze een shell-commando willen uitvoeren, een bestand willen schrijven of code willen uitvoeren. Met drie agents die tegelijkertijd draaien, besteed je je hele sessie aan het klikken op "Goedkeuren" in plaats van ze te bekijken. Keur in je projectinstellingen vooraf de commando's goed die je agents nodig hebben. Bestandslezingen, schrijfbewerkingen, npm-commando's, testrunners — wat je project ook vereist. De specifieke commando's hangen af van je stack, maar het principe is universeel: verwijder de toestemmingsbottleneck voordat je begint, anders besteden je "parallelle" agents de helft van hun tijd aan wachten op jou.

Het Prompt-Draaiboek: Hoe Je Agents Vertelt Wat Ze Moeten Bouwen

Hier gaan de meeste mensen de fout in. Ze schakelen agent teams in, typen "bouw me een to-do app," en vragen zich af waarom de output gefragmenteerd is. De promptstrategie voor agent teams is fundamenteel anders dan het prompten van een solo agent, en het verschil tussen een middelmatige prompt en een uitstekende prompt toont zich in tokenkosten, outputkwaliteit en coördinatie-overhead. Ik heb de afgelopen weken tientallen promptstructuren getest. Dit is het patroon dat consistent de beste resultaten oplevert. De anatomie van een effectieve agent team-prompt:

Create a team of [number] agents using [model]:
1. [Role Name] — responsible for [specific domain].
   Owns files in: [directory or file pattern].
   Deliverables: [exact outputs expected].
2. [Role Name] — responsible for [specific domain].
   Owns files in: [directory or file pattern].
   Deliverables: [exact outputs expected].
3. [Role Name] — responsible for [specific domain].
   Owns files in: [directory or file pattern].
   Deliverables: [exact outputs expected].
Communication rules:
- [Agent A] must share [specific artifact] with [Agent B] before [specific action].
- [Agent C] reviews all deliverables before the team reports completion.
Final deliverables: [list everything the team should produce].
Goal: [one sentence describing the end state].

Laat me uitleggen waarom elk element ertoe doet. Expliciete roltoewijzing voorkomt overlap. Wanneer je zegt "front-end developer verantwoordelijk voor alle UI-componenten, styling en client-side interacties," weet de agent precies wat bij hem hoort en — net zo belangrijk — wat niet. Zonder duidelijke grenzen heb ik twee agents allebei zien besluiten dat zij formuliervalidatie moesten afhandelen, wat conflicterende implementaties in verschillende bestanden opleverde. Bestandseigendom voorkomt overschrijfconflicten. Dit kostte me uren voordat ik erachter kwam. Als twee agents allebei denken dat ze app.js in eigendom hebben, overschrijft de een het werk van de ander. Elke agent moet weten welke bestanden van hem zijn. "Front-end agent bezit alle bestanden in /src/components/ en /src/styles/." "Back-end agent bezit alle bestanden in /src/api/ en /src/models/." Geen ambiguïteit. Geen conflicten. Expliciete communicatieregels voorkomen het dove-freelancer-probleem. De meest effectieve zin die ik ooit in een agent team-prompt heb gezet is deze: "Back-end agent moet het API-endpoint contract delen met de front-end agent voordat een van beiden begint met implementatie." Die ene zin elimineert de categorie bugs waarbij agents bouwen op basis van incompatibele aannames. Zonder deze regel beginnen ze onmiddellijk met coderen — parallel, op volle snelheid, richting verschillende bestemmingen. Deliverables creëren verantwoordelijkheid. "Lever een werkende applicatie" is vaag. "Lever een werkende app, een QA-testrapport dat alle kritieke gebruikersflows dekt, en een README die de API-endpoints documenteert" is specifiek. Wanneer agents weten dat ze worden beoordeeld op specifieke outputs, verdeelt de teamleider het werk anders — en de QA-agent heeft duidelijke criteria voor zijn beoordeling. Hier is een echte prompt die ik gebruikte voor het Neuroflow landingspagina-project:

Create a team of 3 using Sonnet:
1. Front-End Developer — responsible for HTML structure, CSS styling,
   animations, and responsive design. Owns all .html and .css files.
   Deliverables: Complete, responsive landing page with hero section,
   features grid, pricing table, and footer.
2. Back-End Developer — responsible for JavaScript functionality,
   form handling, and any API mock endpoints. Owns all .js files.
   Deliverables: Working contact form, smooth scroll navigation,
   and dynamic pricing toggle.
3. QA Agent — responsible for testing all interactive elements,
   checking cross-browser compatibility, and verifying responsive
   breakpoints. Owns the /tests directory.
   Deliverables: Test report listing all issues found, severity ratings,
   and verification that fixes resolve each issue.
Communication rules:
- Front-End and Back-End must agree on element IDs and class names
  before implementation begins.
- QA reviews all work after initial build, sends issues back to
  responsible agents, and re-verifies after fixes.
Goal: A polished, production-quality landing page for Neuroflow,
an AI startup, that passes QA review with zero critical issues.

Die prompt kostte me drie iteraties om goed te krijgen. De eerste versie specificeerde geen bestandseigendom — twee agents bewerkten hetzelfde HTML-bestand en overschreven elkaars werk. De tweede versie bevatte niet de communicatieregel over element-ID's — de JavaScript-agent bouwde event handlers die classes targetten die niet bestonden in de HTML. De derde versie, hierboven, leverde het elf-bugs-dan-nul-bugs resultaat op dat ik aan het begin beschreef. Drie tot vijf agents is de sweet spot. Ik heb geëxperimenteerd met grotere teams — zeven agents bij één ambitieus project — en de coördinatie-overhead werd verplettend. Agents besteedden meer tijd aan het uitwisselen van berichten dan aan het schrijven van code. De tokenrekening was astronomisch. Voor de meeste projecten dekt een front-end agent, een back-end agent en een QA-agent alles. Voeg een vierde toe voor infrastructuur of DevOps als het project dat vereist. Ga alleen boven de vijf als je werkelijk vijf onafhankelijke werkdomeinen hebt die parallelle uitvoering nodig hebben.

Agent Teams vs. Sub Agents: Het Beslissingskader Dat Ik Werkelijk Gebruik

Ik heb beide benaderingen op genoeg projecten toegepast om een helder mentaal model te hebben voor wanneer je welke moet gebruiken. Dit is niet theoretisch — het is geboren uit het zien oplopen van tokenrekeningen wanneer ik verkeerd koos. Gebruik sub agents wanneer:

• De taak gericht en afgebakend is. "Analyseer dit bestand." "Schrijf tests voor deze functie." "Genereer documentatie voor deze API."
• Taken werkelijk onafhankelijk zijn. Geen gedeelde beslissingen, geen API-contracten om te onderhandelen, geen bestanden die meerdere agents mogelijk aanraken.
• Snelheid en kosten belangrijker zijn dan coördinatie. Sub agents zijn aanzienlijk goedkoper omdat ze de communicatie-overhead volledig overslaan.
• Je een snel resultaat nodig hebt dat terug wordt geleverd aan je hoofdsessie. Sub agents zijn fire-and-forget — lanceer, krijg resultaat, ga verder. Gebruik agent teams wanneer:
• Het project meerdere gespecialiseerde domeinen heeft die moeten samenwerken. Een React front-end, een Node.js API en een PostgreSQL-schema zijn niet onafhankelijk — beslissingen in het ene beïnvloeden de andere.
• Kwaliteit iteratieve feedback vereist. Het QA-agent-patroon dat ik beschreef — waarbij één agent beoordeelt en werk terugstuurt voor fixes — werkt alleen met agent teams. Sub agents kunnen geen retour-kwaliteitslussen doen.
• Je parallelle uitvoering MET coördinatie nodig hebt. Sub agents geven je parallelle uitvoering. Agent teams geven je parallelle uitvoering plus communicatie. Het "plus communicatie" kost meer maar voorkomt de integratienachtmerries die uren handmatig opruimwerk kosten.
• Het project complex genoeg is om de overhead te rechtvaardigen. Mijn ruwe drempel: als het project een solo agent meer dan 15 minuten zou kosten, beginnen agent teams zinvol te worden. Daaronder betaal je coördinatiebelasting voor een probleem dat het niet nodig heeft. Gebruik nooit agent teams voor:
• Eenvoudige of sequentiële taken. Als het ene moet gebeuren voor het andere, helpt parallellisme niet — het hindert.
• Taken die een uniforme gespreksgeschiedenis vereisen. Elke teamgenoot heeft zijn eigen context. Er is geen gedeeld geheugen van eerdere gesprekken.
• Projecten met veel gedeelde bestanden. Als elke agent index.html moet bewerken, ga je sowieso een slechte ervaring hebben, ongeacht hoe zorgvuldig je eigendom toewijst.
• Verkenning en planning. Ik maakte deze fout vroeg — agent teams gebruiken om een projectarchitectuur te "onderzoeken en plannen." De agents besteedden hun hele budget aan het bespreken van mogelijkheden in plaats van iets te bouwen. Gebruik een solo agent voor planning en breng dan het team in voor uitvoering. Het kostenverschil is reëel en aanzienlijk. Een solo agent verbruikt misschien 45.000 tokens voor een taakbeheer-app. Dezelfde app gebouwd door een agent team kan 150.000-200.000 tokens bereiken — drie tot vier keer meer — omdat inter-agent communicatie niet gratis is. Elk bericht tussen teamgenoten verbruikt tokens aan beide kanten. De QA review-en-fix cyclus alleen al kan het totale verbruik verdubbelen. Voor mijn werk werkt de berekening als volgt: agent teams produceren hogere kwaliteit output bij complexe projecten, maar de tokenkosten zijn 3-5x hoger. Ik grijp alleen naar agent teams wanneer het kwaliteitsverschil genoeg uitmaakt om de kosten te rechtvaardigen — klantprojecten, productieapplicaties, alles waar integratiebugs meer zouden kosten om handmatig te fixen dan de extra tokens kosten om te voorkomen.

De Fouten Die Mij Duizenden Tokens Kostten

Ik wil eerlijk zijn over de mislukkingen omdat die me meer leerden dan de successen. Hier zijn de fouten die ik maakte zodat jij ze kunt overslaan. Fout 1: Geen bestandseigendom toewijzen. Mijn eerste drie agent team-sessies leverden code op die er prima uitzag in de terminal van elke agent en volledig stuk was wanneer gecombineerd. Twee agents zouden allebei een utils.js-bestand aanmaken. Eén agent zou package.json wijzigen terwijl een andere er midden in het lezen van was. De teamleider probeerde alles te integreren en vond conflicterende wijzigingen verspreid over het project. De fix was beschamend eenvoudig: vertel elke agent precies welke bestanden en mappen van hem zijn. "Je mag alles lezen, maar je schrijft alleen naar bestanden in jouw map." Ik heb waarschijnlijk 300.000 tokens verloren bij het leren van deze les over meerdere mislukte sessies. Fout 2: Agents vrij laten communiceren zonder structuur. Onbeperkt inter-agent messaging klinkt geweldig in theorie. In de praktijk zullen drie agents met vrije communicatie een alarmerend grote hoeveelheid tijd besteden aan praten in plaats van bouwen. Ik zag een back-end agent en een front-end agent een uitwisseling van zeven berichten hebben over de beste manier om datumopmaak te behandelen voordat een van beiden ook maar één regel code had geschreven. Nu stel ik expliciete communicatiecheckpoints in: "Deel het API-contract vóór implementatie. Meld voltooiing aan QA na implementatie. Stuur elkaar geen berichten tijdens implementatie tenzij je geblokkeerd bent." Dit verminderde het tokenverbruik met ongeveer 40% zonder de outputkwaliteit te verlagen. Fout 3: Het verkeerde model voor de verkeerde rol gebruiken. Elke agent op Opus 4.6 draaien voelt veilig — het is het sterkste model, dus alles zou beter moeten werken, toch? In de praktijk zijn de kosten verbluffend en is de kwaliteitsverbetering voor uitvoeringstaken marginaal. Mijn huidige modeltoewijzing:

• Teamleider: Opus 4.6 — het neemt architectuurbeslissingen en coördineert complexe afhankelijkheden. De premium prijs waard.
• Developer agents (front-end, back-end): Sonnet — snel, capabel en grofweg 5x goedkoper per token dan Opus. Voor het schrijven van code binnen goed gedefinieerde grenzen presteert Sonnet nagenoeg identiek.
• QA-agent: Sonnet of zelfs Haiku voor eenvoudigere projecten — het volgt testpatronen, het bedenkt geen architecturen. Het goedkoopste model dat betrouwbaar testlogica kan uitvoeren. Deze gelaagde aanpak verminderde mijn agent team-kosten met ongeveer 60% vergeleken met overal Opus draaien. Fout 4: Rechten niet vooraf goedkeuren. Met drie agents die parallel draaien, elk goedkeuring nodig voor bestandsbewerkingen en shell-commando's, werd ik de bottleneck. Agents zaten 30-60 seconden stil te wachten tot ik op "Goedkeuren" klikte in elk paneel. Vermenigvuldig dat met tientallen bewerkingen per agent, en een project dat vijf minuten zou moeten duren strekt zich uit tot twintig — niet omdat de agents langzaam zijn, maar omdat ik niet snel genoeg kan klikken. Keur alles wat je agents nodig hebben vooraf goed in je project- of lokale instellingen. Het productiviteitsverschil is enorm. Fout 5: Teams draaien zonder QA-agent. Mijn eerste agent teams bestonden uit twee developers en geen QA. De output was snel maar vol met integratieproblemen — niet-matchende ID's, kapotte event handlers, CSS die conflicteerde tussen componenten. Ik deed zelf QA, wat het doel van het hebben van een team tenietdeed. Het toevoegen van een toegewijde QA-agent veranderde het spel. Het vangt integratieproblemen op die mij 10-15 minuten zouden kosten om handmatig te vinden, en de review-fix-verificatie-lus gebeurt zonder mijn betrokkenheid. De QA-agent kost misschien 20.000 extra tokens per sessie. De tijd die het me bespaart is tien keer zoveel waard. Als je liever hebt dat iemand deze agent team-configuraties helemaal opzet — geoptimaliseerde prompts, modeltoewijzingen, QA-workflows, de hele infrastructuur — dan neem ik dat soort opdrachten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Geavanceerde Patronen: Plangoedkeuring, Tmux-Monitoring en Contextpersistentie

Zodra je de basis werkend hebt, tillen drie geavanceerde functies je agent team-workflow van goed naar werkelijk krachtig. Plangoedkeuringsmodus Standaard gaan agent-teamgenoten gewoon... van start. Ze ontvangen hun opdracht en beginnen onmiddellijk met uitvoeren. Plangoedkeuringsmodus voegt een checkpoint toe: elke agent genereert een plan en wacht op goedkeuring voordat er code wordt geschreven. De goedkeurder kan jij zijn, de teamleider, of een aangewezen beoordelaaragent. Ik gebruik dit selectief. Voor projecten waar ik de architectuur goed ken, laat ik agents vrij uitvoeren — de snelheid is belangrijker dan de controle. Voor onbekend terrein of klantprojecten waar fouten duur zijn, geeft plangoedkeuring mij een beoordelingspoort zonder het hele team te vertragen tot sequentiële uitvoering. Elke agent dient zijn plan parallel in. Ik beoordeel alle plannen tegelijkertijd. Dan voeren ze allemaal parallel uit. De totale overhead is meestal minder dan twee minuten, en het voorkomt het soort architecturele divergentie dat een complete herbouw vereist. Tmux-Monitoring Ik noemde tmux eerder voor terminalsplitsing, maar de monitoringworkflow verdient meer detail. Wanneer agent teams draaien met tmux, krijgt elke agent een eigen paneel met een kleurgecodeerde header die zijn rol toont. Je kunt:

• Alle agents tegelijkertijd zien werken
• In het paneel van een agent klikken om een direct bericht te sturen
• De berichtenstroom tussen agents in realtime observeren
• Blokkerende problemen opmerken voordat ze escaleren De directe berichtmogelijkheid is bijzonder waardevol. Als ik zie dat de front-end agent een pad inslaat waarvan ik weet dat het niet werkt, kan ik in zijn paneel springen en bijsturen zonder de andere agents te beïnvloeden. "Hé, gebruik CSS Grid voor deze lay-out in plaats van Flexbox — de geneste componenten hebben tweedimensionale uitlijning nodig." De agent past aan, en de back-end agent werkt ongestoord verder. Dit soort chirurgische interventie is niet mogelijk met sub agents. Je zou de sub agent moeten annuleren, de prompt herschrijven en opnieuw lanceren — waarbij al het reeds gedane werk verloren gaat. Contextpersistentie via Tijdelijke Bestanden Agent teams hebben een kwetsbaarheid die mij twee keer heeft gebeten: als een agent crasht of de sessie wegvalt, is al het werk dat niet naar schijf is geschreven verdwenen. Het context window van de agent verdampt, en de teamleider heeft geen kopie van werk-in-uitvoering. Mijn oplossing: instrueer agents om voortgang op te slaan in tijdelijke bestanden na elke grote mijlpaal. "Na het voltooien van het header-component, sla je voortgang op in /tmp/frontend-checkpoint-1.md met een samenvatting van wat klaar is en wat het volgende is." Als een agent midden in een sessie sterft, leest de vervangende agent het checkpointbestand en gaat verder waar de vorige was gebleven in plaats van helemaal opnieuw te beginnen. Dit voegt misschien 5% toe aan je tokenverbruik en heeft me gered van twee complete teamherstarts. De eerste herstart, voordat ik checkpoints had geïmplementeerd, kostte me ongeveer 180.000 tokens aan gedupliceerd werk.

Het Mentale Model Dat Alles Op Zijn Plek Laat Vallen

Na weken van experimenteren heb ik een manier van denken over agent teams gevonden die voorspelt wanneer ze goed werken en wanneer ze falen. Het komt uit real-world teammanagement, niet uit AI-theorie. Agent teams volgen dezelfde regels als menselijke engineeringteams: De wet van Brooks geldt. Meer agents aan een project toevoegen verhoogt de communicatie-overhead kwadratisch. Drie agents hebben drie communicatiekanalen. Vijf agents hebben er tien. Zeven agents hebben er eenentwintig. De coördinatiekosten schalen niet lineair — ze exploderen. Houd teams klein. Drie tot vijf agents. Niet meer. De wet van Conway geldt. De structuur van je agent team wordt weerspiegeld in de structuur van de code die ze produceren. Als je een front-end agent en een back-end agent hebt, krijg je een duidelijk gescheiden front-end en back-end. Als je één agent hebt die "UI en API" samen afhandelt, krijg je sterk gekoppelde code. Ontwerp je teamstructuur zodat deze overeenkomt met de architectuur die je wilt. De mythische man-maand geldt. Twee agents produceren niet twee keer zo snel als één agent bij elke taak. Bij sommige taken — sequentieel, sterk gekoppeld, gedeelde context vereisend — zijn twee agents langzamer dan één vanwege coördinatie-overhead. Agent teams schitteren wanneer werk werkelijk parallelliseerbaar is met duidelijke domeingrenzen. De praktische implicatie: schets het project als een afhankelijkheidsgrafiek voordat je een agent team spawnt. Als je drie of meer onafhankelijke werkstromen hebt die uiteindelijk moeten integreren, zijn agent teams zinvol. Als het werk fundamenteel sequentieel is of alles van alles afhankelijk is, gebruik dan een solo agent. Ik ben mezelf een eenvoudige vraag gaan stellen voor elk project: "Zou ik dit aan drie afzonderlijke freelancers in drie afzonderlijke kamers kunnen uitleggen en een samenhangend resultaat krijgen?" Zo ja, agent teams. Zo nee, solo agent of sub agents met zorgvuldige integratie.

Waar Ik Nu Aan Werk — En Wat Er Komt

Op dit moment gebruik ik agent teams voor bijna elk project met meer dan twee integratiepunten. De workflow is gestabiliseerd tot een patroon: ik plan met een solo Opus-sessie, stel bestandseigendom en communicatieregels in, en spawn dan een team van 3-4 Sonnet-agents om uit te voeren terwijl een QA-agent de output bewaakt. De resultaten spreken door het proces, niet door de hype. Mijn landingspagina's komen schoner terug omdat de QA-agent dingen opvangt die ik om 2 uur 's nachts zou missen. Mijn full-stack builds integreren bij de eerste poging omdat agents API-contracten onderhandelen voordat ze code schrijven. Mijn debugsessies zijn sneller omdat ik drie agents tegelijkertijd drie verschillende hypotheses kan laten testen in plaats van ze sequentieel te testen. De feature is niet perfect. Sessiestabiliteit kan wankel zijn — ik heb agents gehad die midden in een taak disconnect raakten bij lange sessies. De tokenkosten zijn oprecht hoog voor complexe projecten. En de benodigde promptprecisie betekent dat er een leercurve is die steiler is dan Anthropic's documentatie suggereert. Maar hier is wat mij ervan overtuigde dat dit de toekomst is van AI-ondersteunde ontwikkeling, niet slechts een feature: het patroon van samenwerking zelf. Kijken hoe een QA-agent bugs vindt, ze naar de verantwoordelijke developer stuurt, fixes ontvangt en de correcties verifieert — allemaal zonder mijn betrokkenheid — dat is niet slechts automatisering. Dat is een team. Een team dat toevallig uit AI bestaat, maar desondanks een team, met dezelfde dynamiek van communicatie, verantwoordelijkheid en iteratieve kwaliteitsverbetering die menselijke engineeringteams effectief maken. De tooling zal goedkoper en stabieler worden. De modellen zullen sneller en slimmer worden. Maar het patroon — gespecialiseerde agents die samenwerken door gestructureerde communicatie aan gedeelde doelen — dat patroon is permanent. Het nu leren betekent dat je een vaardigheid opbouwt die zich vermenigvuldigt met elke verbetering die Anthropic uitbrengt. Als je nog steeds alles door een solo agent draait en je afvraagt waarom complexe projecten aanvoelen als het duwen van een rotsblok bergopwaarts, probeer dit: neem je volgende project met meerdere componenten, definieer drie rollen met duidelijk bestandseigendom, voeg een QA-agent toe, en schrijf één communicatieregel. Slechts één. "Stem het API-contract af voordat je begint met coderen." En kijk dan wat er gebeurt.

Veelgestelde Vragen

Hoe schakel ik Claude Code agent teams in?

Voeg "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" toe aan het env-object in het settings.local.json-bestand van je project en herstart Claude Code. Je hebt Claude Code v2.1.32 of later nodig, beschikbaar op Pro ($20/maand) of Max ($100-$200/maand) abonnementen.

Hoeveel agents moet ik gebruiken in een team?

Drie tot vijf agents is de sweet spot voor de meeste projecten. Boven de vijf groeit de inter-agent communicatie-overhead kwadratisch en lopen de tokenkosten op. Een typisch effectief team bevat een front-end agent, back-end agent en QA-agent. Voor een diepere blik op modelselectie per rol, zie mijn Claude agent teams gids.

Wat is het verschil tussen agent teams en sub agents?

Sub agents draaien onafhankelijk, voltooien een taak en retourneren resultaten aan de hoofdagent — ze kunnen niet met elkaar communiceren. Agent teams hebben een gedeelde takenlijst, directe inter-agent messaging en een teamleider die parallel werk coördineert met iteratieve feedbacklussen. Sub agents zijn goedkoper en sneller; agent teams produceren hogere kwaliteit output bij complexe, multi-domein projecten.

Kosten agent teams meer tokens dan een solo agent?

Ja, aanzienlijk. Een taak die 45.000 tokens kost met een solo agent kost doorgaans 150.000-200.000 tokens met een agent team door inter-agent communicatie-overhead. Verlaag kosten door Sonnet of Haiku te gebruiken voor uitvoeringsagents en Opus alleen te reserveren voor de teamleider.

Kunnen agent-teamgenoten mijn projectbestanden en tools benaderen?

Alle teamgenoten erven rechten van de hoofdsessie, inclusief bestandssysteemtoegang, commando-uitvoering, MCP-servers en skills. Je kunt geen verschillende rechtenniveaus aan verschillende teamgenoten toekennen — ze delen allemaal dezelfde toegangsconfiguratie.

Laten We Samenwerken

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

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