Week 7: Vier agents schrijven je boek, en je vraagt je af wiens stem het is

Claude Code heeft een nieuwe experimentele feature: Agent Teams. In plaats van een enkele AI-sessie die alles doet, kun je nu meerdere Claude Code instanties als team laten samenwerken. Een team lead die het werk coordineert, teammates die elk hun eigen specialisatie hebben, een gedeelde takenlijst, en een messaging systeem waarmee ze onderling communiceren.

Dat wilde ik uitproberen. Niet alleen voor code, maar ook voor iets compleet anders: een boek schrijven. Het hoofdstuk had ik al - ik wilde zien hoe een team van agents het zou aanpakken. En met het nieuwe Opus 4.6 model dat net uit is, leek dit het perfecte moment om de combinatie te testen.

Hoe Agent Teams werken

Het concept is simpel maar krachtig. Je vertelt Claude Code dat je een team wilt, beschrijft de taak en de rollen. Claude maakt het team aan, spint de teammates op, en coordineert het werk.

Onder de motorkap draait elke teammate als een volledig onafhankelijke Claude Code sessie met een eigen context window. Anders dan subagents - die binnen een enkele sessie draaien en alleen kunnen rapporteren aan de hoofdsessie - kunnen teammates met elkaar communiceren. Ze delen een takenlijst, claimen taken, en sturen berichten heen en weer. De team lead houdt het overzicht en stuurt bij waar nodig.

Wat het interessant maakt is de parallellisatie. Taken zonder onderlinge afhankelijkheden kunnen tegelijk worden uitgevoerd. Als teammate A en teammate B elk een ander aspect onderzoeken, hoeven ze niet op elkaar te wachten. Pas wanneer resultaten samengevoegd moeten worden, komt de sequentie terug. Dependencies bepalen je architectuur - net als bij software.

Je kunt als gebruiker ook direct met individuele teammates communiceren, zonder via de lead te gaan. En je kunt de lead in “delegate mode” zetten, zodat die zich puur richt op coordinatie en niet zelf aan de slag gaat.

Het experiment: een hoofdstuk schrijven

Zondag zette ik vier agents aan het werk op een hoofdstuk van mijn boek. Een researcher die bronnen verzamelde, een structuur-analist die de opbouw bepaalde, een schrijver die de tekst produceerde, en een taalreviewer die het geheel polijstte. Het hoofdstuk had ik eerder al zelf geschreven - dit was een bewuste test om te zien hoe de agents het zouden doen.

Het resultaat: 4500 woorden, 25+ wetenschappelijke bronnen, naadloos aansluitend op de vorige hoofdstukken.

En toen zat ik met een vreemd gevoel. Want het las goed. Misschien beter dan mijn eigen versie.

De kracht zat in de specialisatie. De researcher ging breed en diep tegelijk. De structuur-analist bouwde voort op de psychologische concepten uit eerdere hoofdstukken. De schrijver combineerde Special Forces principes met Sun Tzu strategieen en praktijkervaringen. En de taalreviewer ving dingen op die ik zelf nooit had gezien: “satisficen” is geen Nederlands woord, “hardwired” werd “diep verankerd”.

De parallelle aanpak was precies zoals Agent Teams bedoeld zijn. Researcher en structuur-analist konden tegelijk aan de slag - geen onderlinge afhankelijkheid. Pas daarna, sequentieel, de schrijver en taalreviewer. Die workflow-keuze bleek bepalend voor de kwaliteit.

Maar mijn bijsturing was onmisbaar. “Anti-sabotage technieken nog NIET toepassen op de 8 kernpunten” - dat soort scope-beslissingen kan een agent niet zelf nemen. De team lead coordineert, maar de mens bepaalt de richting.

Het experiment: een bug oplossen

Eerder in de week gebruikte ik dezelfde aanpak voor iets heel anders. De OWASP Agentic Auditor had een bug waarbij Azure OpenAI een leeg dashboard genereerde. De oorzaak was subtiel: response.content werd behandeld als string, terwijl Azure het als list teruggeeft.

Vier gespecialiseerde agents - een parser-investigator, een data-flow-tracer, een error-checker en een synthesizer - analyseerden parallel het probleem. De root cause was een silent failure: json.loads() faalde stilletjes en niemand merkte het.

Silent failures zijn gevaarlijk. Ze produceren geen errors, geen crashes, geen rode vlaggen. Ze produceren lege dashboards. En je merkt het pas als iemand klaagt dat er geen data te zien is.

De fix was elegant: een utility module extract_text_from_content() die content correct parst ongeacht het type. Maar het debuggen met een team was opvallend effectief. Meerdere hypotheses tegelijk testen, verschillende perspectieven op hetzelfde probleem - precies het scenario waarvoor Agent Teams ontworpen zijn.

Dezelfde les kwam terug bij een SRT-bug in de podcast pipeline. Sequentienummers in ondertitelbestanden kregen “None” als waarde. Niet omdat de parser faalde, maar omdat de AI enhancement prompt verkeerde voorbeelden bevatte. De oplossing was dubbel: de prompt corrigeren (preventief) en een renumber_srt_entries() functie toevoegen als vangnet.

Versies, voices en de details die ertoe doen

Aisha - de voice AI-assistent voor de podcast - kreeg een upgrade naar ElevenLabs v3. Klinkt simpel: verander het model, klaar. Maar de model naam bleek anders dan verwacht (eleven_v3 in plaats van eleven_multilingual_v3), de voice ID moest mee veranderen, en de hele configuratie was hardcoded in de broncode.

De refactoring ging dieper dan gepland. Van hardcoded waarden naar environment variables. Van een enkele parameter naar een complete configuratie-module. Zeven nieuwe unit tests om te borgen dat alles werkt.

Het patroon herhaalt zich: wat begint als “even snel aanpassen” wordt een oefening in software architectuur. Hardcoded waarden zijn technische schuld die je betaalt op het moment dat je wilt veranderen. En je wilt altijd veranderen.

Daarnaast speelde er een versie-mismatch die me meer frustreerde dan het hoorde. pyproject.toml zei v0.4.0, de app toonde v0.3.2. Python cache-management, oude imports, uvicorn die de verkeerde versie laadt. Methodisch elimineren was de enige weg: logs analyseren, stap voor stap mogelijkheden uitsluiten. Niet gokken, maar bewijzen.

De routine die zichzelf draait

De dagelijkse automatisering die vorige week vorm kreeg, draaide deze week voor het eerst “in productie”. Stats ophalen, dashboard deployen, LinkedIn drafts maken, Bluesky posts publiceren. Het systeem deed wat het moest doen.

Maar ook hier: de ruff linter op de CI-server (v0.15.0) gaf andere resultaten dan lokaal (v0.14.9). Een multiline lambda die lokaal door de check kwam, faalde remote. Kleine versieverschillen in tools, grote impact op je pipeline.

Wat het met mij deed

Twee experimenten met Agent Teams. Twee totaal verschillende ervaringen.

Bij het debuggen voelde het puur instrumenteel. Sneller root causes vinden, meer perspectieven op hetzelfde probleem, parallelle analyse. Geen emotionele lading. Gewoon effectief. De technologie deed wat het moest doen, en ik was blij met het resultaat.

Bij het boek was het anders. Ik las het hoofdstuk en dacht: dit is goed. De structuur klopt, de bronnen zijn relevant, de taal is helder. Maar het voelde niet alsof ik het had geschreven. Het voelde alsof ik het had geregisseerd.

Is dat erg? Ik weet het niet. Een regisseur maakt ook films die zijn naam dragen. Maar een regisseur kiest de acteurs, bepaalt de scenes, zegt wanneer het goed is. Dat deed ik ook. “Niet teveel jargon.” “Engelse termen die we in het Nederlands gebruiken mogen blijven.” “Satisficen is geen woord.” Die feedback vormde het resultaat net zoveel als de agents zelf.

Toch kriebelt het. De taalreviewer ving fouten die ik niet had gezien. De researcher vond bronnen die ik niet kende. De structuur-analist zag verbanden die ik had gemist. Het resultaat is objectief beter dan wat ik alleen had geproduceerd. En dat is tegelijk het mooie en het ongemakkelijke eraan.

Het verschil zit in eigenaarschap. Code is gereedschap. Een boek is identiteit. En dat maakt de vraag “wie heeft dit geschreven?” zwaarder dan “wie heeft deze bug gevonden?”

Het patroon

Opus 4.6 gecombineerd met Agent Teams is een krachtige combinatie. Het model is capabeler dan ooit, en de team-architectuur vermenigvuldigt die capaciteit. Specialisatie plus parallelisatie levert meer op dan een generalist alleen kan - of het nu gaat om boeken schrijven, bugs oplossen, of workflows automatiseren.

Maar de waarde zit niet in de agents. Die zit in de orchestratie. Welke agent doet wat? Wat kan parallel, wat moet sequentieel? Waar stuur je bij, waar laat je los? De kwaliteit van de output is direct gerelateerd aan de kwaliteit van je aanwijzingen.

Dat is de les van week 7: de tools worden capabeler, maar de regisseur wordt belangrijker. Niet minder.