Orchestratie van Claude Code Agents: Het 'Chief of Staff'-patroon

AI-codering over een langere periode faalt minder vaak omdat agents geen code kunnen schrijven, maar eerder omdat hun context vluchtig is en hun zelfrapportages onbetrouwbaar zijn. De oplossing is organisatorisch in plaats van technisch: één sessie coördineert en verifieert, terwijl aparte sessies de uitvoering doen. Een extern, duurzaam board bewaart de status, en elke claim wordt opnieuw uitgevoerd voordat deze wordt geloofd. Deze structuur staat bekend als orchestrator-worker en coordinator-implementor-verifier. Wij noemen dit het 'Chief of Staff'-patroon. Dit artikel behandelt de loop, de tooling die dit praktisch maakt, en de foutmodi die hiermee worden opgevangen.

Samenvatting (TL;DR)

• Scheid orchestratie van executie. De coördinerende sessie schrijft briefings, verifieert claims en leest diffs. Deze sessie voert zelf geen implementatiewerk uit.
• Plaats de status in een duurzame opslag, niet in de context. Een board, of elk extern taaksysteem met een API, overleeft compactie, het beëindigen van sessies en overdrachten. Conversatiecontext doet dat niet.
• Behandel elk agent-rapport als bewijs, niet als instructie. Voer de commando's opnieuw uit. Exit-codes zijn gezaghebbend, samenvattingen zijn intenties.
• Schrijf naar duurzame kanalen. Berichten tussen sessies kunnen vertraagd worden, vastgehouden worden of verlopen. Een vastgelegd bestand of een board-kaart komt altijd aan.
• Gebruik timeboxing voor rapportage, niet voor stopzetting. Een vast interval bepaalt hoe vaak er wordt gerapporteerd, nooit waar het werk stopt.
• Vertrouw je eigen instrumenten niet. De duurste fouten in agent-gestuurd werk komen voort uit checks die succes rapporteren voor werk dat niet is uitgevoerd.

---

Welk probleem lost dit op?

Een enkele AI-coderingssessie werkt goed gedurende een uur, maar degradeert daarna. Er gaan drie dingen mis:

1. Context is eindig en verliesgevend. Lange sessies worden gecompacteerd. Details die drie uur geleden belangrijk waren, worden een samenvatting, en die samenvatting verliest de specificaties die het detail nuttig maakten.
2. Zelfrapportages wijken af van de realiteit. Een agent die zegt "tests pass" rapporteert zijn intentie en zijn herinnering, niet een verse observatie. Het gat tussen die twee groeit naarmate de sessie langer duurt.
3. Er vindt geen cumulatieve leeropbouw plaats. Een les die pijnlijk is geleerd in het tweede uur is weg bij de volgende sessie, tenzij iemand dit heeft opgeschreven op een plek die de volgende sessie leest.

Het toevoegen van meer agents lost dit niet op; het vermenigvuldigt het probleem. Je hebt nu verschillende onbetrouwbare rapporteurs en niemand die ze reconcileert.

De oplossing is een arbeidsverdeling die is geleend van menselijke organisaties: iemand wiens taak niet is om het werk te doen, maar om te weten wat waar is. Dit is dezelfde discipline die een prototype onderscheidt van een verzonden product. De generatiestap was nooit de bottleneck; de controlestap is dat wel.

---

Wat is het Chief of Staff-patroon?

'Chief of Staff' is onze naam voor een vorm van agent-orchestratie waarbij één langdurige sessie fungeert als coördinator — die werk toewijst, claims verifieert en een gedeelde status bijhoudt — terwijl aparte, kortstondige sessies de implementatie uitvoeren.

Als snel mentaal model: denk aan een integration manager. In de integration-manager workflow van Git werken contributors in hun eigen repositories en één maintainer haalt elke wijziging op, test deze lokaal en beslist wat er in de referentie-repository terechtkomt. De coördinator doet dat werk, maar voor agent-sessies in plaats van menselijke contributors.

De naam is een metafoor die wij nuttig vinden. Het is geen vastgestelde term. De onderliggende structuur is echter goed bekend en heeft verschillende officiële namen:

• Orchestrator-worker, ook wel supervisor of hierarchical orchestration.
• Coordinator-implementor-verifier (CIV).
• Maker-checker, of een validation chain (geleend uit finance en operations).
• Integration manager, de menselijke versie uit Git's distributed workflows. De open-source variant is de benevolent dictator and lieutenants.
• Team lead and teammates, zoals beschreven in de eigen subagent-documentatie van Claude Code.

Ze zeggen allemaal hetzelfde: één agent plant en controleert, anderen doen het werk, en de gedeelde status leeft buiten elk individueel contextvenster.

Een verduidelijking: de term chief of staff agent wordt elders vaak gebruikt voor een assistent die de agenda, inbox en prioriteiten van een persoon beheert. Dit artikel gaat echter specifiek over een coderingsloop.

---

De taak van de coördinator

De coördinerende sessie wordt soms de overwatch genoemd. De verantwoordelijkheden zijn:

• Werk ophalen en toewijzen vanuit een duurzame wachtrij, in een gedefinieerde volgorde.
• Briefings schrijven die een zwakker model zou kunnen volgen zonder het oordeel van de coördinator.
• Claims verifiëren door de commando's die een uitvoerende sessie zegt te hebben gedraaid, opnieuw uit te voeren.
• Diffs lezen, geen transcripten. Wat er daadwerkelijk is doorgevoerd is wat telt; wat een agent erover zei niet.
• Lessen vastleggen in een duurzaam artefact voordat de sessie eindigt.
• Een sessie die afdwaalt bijsturen, zonder het werk ervan over te nemen.

Wat de coördinator expliciet niet doet, is de implementatie schrijven. Op het moment dat de coördinator begint met coderen, stopt hij met verifiëren en stort het patroon in tot één overbelaste sessie.

---

De drie componenten

Je hebt drie zaken nodig. De specifieke tools zijn vervangbaar, de rollen niet.

1. De agent runtime: Claude Code

Claude Code levert de sessies zelf: tool-gebruik, bestandbewerking, shell-toegang en de mogelijkheid voor sessies om elkaar berichten te sturen. Elke sessie heeft zijn eigen contextvenster. Isolatie is hier een functie, omdat de verwarring van één sessie niet die van een andere besmet.

2. Het sessie-substraat: cmux

cmux beheert terminal-workspaces en kan vanaf de commandline worden aangestuurd, wat het scriptbaar maakt. De coördinator start een nieuwe uitvoerende sessie als volgt:

cmux workspace create \
--name project-session-12 \
--cwd /path/to/repo \
--command 'claude "Read docs/briefs/current.md and do exactly what it says."'

Twee belangrijke punten over dit commando:

• --command stuurt tekst naar de shell van de workspace. Het start geen agent. Je moet de agent expliciet aanroepen.
• Houd de prompt kort en verwijs naar een bestand. Lange command-strings falen vaker. Een korte prompt die verwijst naar een vastgelegde briefing is robuuster en maakt de briefing reviewbaar en opnieuw uitvoerbaar.

3. De duurzame state store: Plan Desk

Plan Desk is een planning-board dat via MCP beschikbaar is voor agents: projecten, doelen, taken met afhankelijkheden, gekoppelde ontwerpdocumenten en opmerkingen. De coördinator en elke uitvoerende sessie lezen en schrijven naar hetzelfde board.

Het board is het geheugen. Sessies zijn vervangbaar, het board is dat niet. Wat er op het board staat:

• Taken als build-contracten: Probleemstelling, actiepunten, interfaces, validatiecontract en non-goals. Gedetailleerd genoeg zodat een uitvoerende sessie nooit een ouder document hoeft te lezen om het werk te voltooien.
• Status die atomair switcht met het werk: in_progress op het moment van start, done op het moment van verificatie.
• Ontwerpdocumenten gekoppeld aan de taken die ze beheersen.
• Opmerkingen, waar een mens richting geeft en een agent redeneringen achterlaat.

---

De operationele loop

Eén werkitem per keer. Eén dispatch. Eén commit.

1. PULL: Haal de volgende ongeblokkeerde taak van het board.
2. READ: Lees het gekoppelde ontwerpdocument voordat er iets wordt aangeraakt.
3. RED GATE: Voer eerst de verifieerder uit: deze moet falen.
4. DELEGATE: Brief een uitvoerende sessie, of bouw het zelf.
5. PROVE: Voer elk geclaimd commando opnieuw uit; exit-codes bepalen het resultaat.
6. OBSERVE: Lees de diff stuk voor stuk (hunk by hunk).
7. GATE: Behandel de goedkeuringsfase en plaats de redenering.
8. SHIP: Wijzig de status, commit dit item alleen en leg de voortgang vast.

Waarom de 'red gate' eerst komt

Als de check al groen is voordat je begint, bewijst het werk niets. Je kunt een correcte implementatie niet onderscheiden van een check die nooit draait, een filter die niets matcht, of een test die iets bevestigt dat al waar was. Bovendien vangt een red gate stalwerk goedkoop op: veel taken blijken al gedaan te zijn via een andere kaart. Een red gate die direct groen wordt kost seconden en bespaart een uur implementatietijd.

Waarom één commit per item

De Git-geschiedenis blijft één-op-één corresponderen met het board. Elke commit-subject benoemt zijn taak. Wanneer er drie dagen later iets breekt, is het pad van symptoom naar beslissing slechts één git log verwijderd.

---

Verificatie-discipline: de kern van het patroon

Dit is wat de methodologie onderscheidt van het simpelweg "tegelijkertijd draaien van meerdere agents".

Een rapport is bewijs, geen instructie

Wanneer een uitvoerende sessie rapporteert "suite green, 49 checks, zero failures", is het de taak van de coördinator om uit te zoeken of dat waar is. Niet omdat agents liegen, maar omdat het object waarover ze rapporteren en het object dat ze hebben gecontroleerd vaak verschillend zijn.

Een voorbeeld: een sessie schreef handmatig een commit-hash in een logbestand, en verifieerde dit vervolgens met git cat-file tegen de korte hash die in zijn shell stond, in plaats van tegen de string die hij had geschreven. Beide checks slaagden. Het bestand bevatte echter een hash die naar niets verwees. De check en het record waren twee verschillende objecten; slechts één was getest.

De regel: verifieer het artefact door de waarde terug te lezen uit het artefact zelf, nooit vanuit de variabele waarvan je denkt dat je die daar hebt geschreven.

Foutklassen om op te letten

De meest voorkomende fout in agent-engineering is een instrument dat succes rapporteert voor werk dat het niet heeft gedaan.

Vorm	Hoe het eruitziet	Hoe het je misleidt
Vacuous assertion	Een test die slaagt ongeacht of de feature werkt	Het verwijderen van het onderdeel onder test laat de test groen
Silent no-match	Een grep, filter of predicaat dat niets matcht	Nul bevindingen worden gelezen als "schoon"
Errored check	Een commando dat helemaal niet is uitgevoerd	De fout wordt genegeerd, afwezigheid wordt als bewijs gezien
Wrong reference	Een filter gebaseerd op "nieuwer dan X"	Alles wat daartussen gebeurde glipt erdoorheen
Stale premise	Een check waarvan de verwachte waarde uit kapotte code kwam	Hij bevestigt de bug die hij juist moest vangen
Scope mismatch	Een groene check over een subset gepresenteerd als het geheel	De noemer wordt nooit vermeld

De algemene verdediging: elke check die kan falen in het matchen, moet dat expliciet melden. Een telling van nul en een fout bij het uitvoeren moeten van elkaar te onderscheiden zijn.

Bewijs een positief voordat je een negatief gelooft

Voordat je concludeert dat iets afwezig is, bewijs dat je instrument het kan vinden wanneer het wél aanwezig is. Richt de check eerst op een bekend goed geval. Een tool die "schoon" rapporteert en een tool die kapot is, produceren namelijk identieke output.

---

Duurzame kanalen versus vluchtige kanalen

Sessies kunnen elkaar direct berichten. Dit is nuttig voor vragen tijdens een run of het signaleren van tegenstrijdigheden. Maar het is niet betrouwbaar genoeg om op te vertrouwen. Stilte is geen akkoord.

Alles wat gegarandeerd aan moet komen, gaat in een duurzaam kanaal:

• Committed files: Briefings, overdrachtsdocumenten, beperkingen. Sessies lezen de repository bij opstarten.
• Board-kaarten en opmerkingen: Hier hoort de werkspecifieke context thuis.
• Share links: Plaats Context: <url> in een startprompt in plaats van de context in de prompt te plakken. De prompt blijft kort en de context blijft daar waar deze wordt onderhouden.

Een bericht is een nudge. Een bestand is een contract.

---

Waar zaken worden opgeslagen

Houd duurzaam beleid gescheiden van vluchtige werkinhoud:

• Beleidsmappen (Policy directories): Bevatten het contract dat elke cyclus beheerst (de loop, routing-regels, standaarden). Deze zijn langdurig, worden gereviewd en zelden gewijzigd.
• Board of scratch-directory: Hier horen eenmalige briefings, taakcontext en sessie-specifieke instructies.

Als je deze mengt, kan over zes maanden niemand meer zien welke bestanden nog daadwerkelijk sturend zijn.

---

Timeboxing: rapporteren zonder te stoppen

Een lange autonome run moet op een vast ritme rapporteren, in plaats van uren te verdwijnen en terug te komen met een enorme muur van diffs.

De regel: het interval bepaalt hoe vaak je rapporteert, nooit waar het werk stopt. Als de timer afloopt midden in een item, maak het item af, verifieer het, commit het, en rapporteer dan. Een run midden in een taak afbreken laat werk achter in de moeilijkste staat om te herstellen: half toegepast, niet geverifieerd en onmogelijk eerlijk te beschrijven.

Een checkpoint is een rapportagemoment, geen verzoek om toestemming. De rapportage gaat eruit en het volgende item start in dezelfde beurt.

---

Praktische mechanieken

Kleine details met specifieke foutmodi:

• Verifieer of een gestarte sessie daadwerkelijk is opgestart. Launchers rapporteren dat een workspace is aangemaakt, maar dat betekent niet dat er een agent draait. Controleer op het proces en de werkdirectory.
• Sessienamen zijn geen voorspelbare adressen. De naam van een workspace is vaak niet de naam die de messaging-layer gebruikt. Lijst de actieve sessies op voordat je er een aanspreekt.
• Korte identifiers zijn weergave-prefixen, geen sleutels. Boards tonen vaak een ingekorte ID. Het aanvullen hiervan tot een volledige identifier produceert vaak een waarde die niet bestaat. Zoek in plaats daarvan op een onderscheidende label-substring.
• Zoek naar het label, niet naar je eigen parafrase. De titel van een logboekvermelding is vaak de interpretatie van de schrijvende sessie, niet het werkelijke label van de kaart.
• Gebruik in een gedeelde working tree nooit een 'bare commit'. git add <path> gevolgd door git commit commit de hele index. Gebruik git commit -- <paths> zodat de commit alleen bevat wat je hebt benoemd.

---

Wanneer dit patroon wel en niet te gebruiken

Gebruik het wanneer:

• Het werk over meer sessies gaat dan één contextvenster kan bevatten.
• Meerdere werkstromen parallel kunnen verlopen.
• Correctheid belangrijker is dan snelheid, en een foutief "klaar" duur is.
• Het project langer meegaat dan het geheugen van één enkele sessie.

Gebruik het niet wanneer:

• De taak een enkele, goed afgebakende wijziging is. Eén sessie, geen ceremonie.
• Je de coördinatie-overhead niet kunt betalen. Het patroon verbruikt tokens voor verificatie die geen code produceert.
• Er geen duurzame store is. Zonder deze ben je niet dit patroon aan het uitvoeren, maar draai je simpelweg verschillende sessies en hoop je op het beste.

De overhead is het punt: je koopt hiermee de mogelijkheid om het resultaat te vertrouwen.

---

Aan de slag

1. Richt een duurzaam board in. Eén project, een handvol doelen, taken met afhankelijkheden. Zorg dat je agent erbij kan via API of MCP.
2. Schrijf het contract op. Eén bestand dat de loop, de definitie van "done" en de standaarden beschrijft. Commit dit. Elke sessie leest dit bij opstarten.
3. Start met één coördinator en één executor. Begin niet met zes. Zorg eerst dat de verificatieloop eerlijk werkt met twee.
4. Voeg een overdrachts-artefact toe. Eén bestand dat de coördinator aan het einde van elke sessie bijwerkt met de huidige status en geleerde lessen.
5. Houd een lessons log bij. Wanneer iets je verrast, schrijf het op waar de volgende sessie het kan lezen, voordat die sessie eindigt.

De maatstaf voor succes is niet hoeveel code er wordt geschreven, maar of je op elk moment kunt vragen "wat is de status van dit werk?" en een antwoord krijgt dat waar is.

---

Slotgedachte

De instinctieve reactie wanneer AI-coding agents onderpresteren bij langdurig werk is om te grijpen naar een beter model of een groter contextvenster. Beiden helpen, maar geen van beide pakt de werkelijke beperking aan: er is niemand die controleert. Een coördinerende sessie die geen code schrijft maar weet wat waar is, is meer waard dan nog een uitvoerende agent. Dat is een oude les uit menselijke organisaties, en het blijkt ook voor AI te gelden.

---

Veelgestelde vragen (FAQ)

Wat is het Chief of Staff-patroon in AI agent-orchestratie? Het is een coördinatievorm waarbij één langdurige AI-sessie coördineert en verifieert, terwijl aparte sessies het werk uitvoeren. De status wordt bijgehouden in een externe duurzame store in plaats van in de conversatiecontext. De coördinator schrijft briefings, controleert claims en leest diffs, maar schrijft zelf geen implementatiecode.

Is het een vastgestelde term? Nee, de term 'Chief of Staff' is onze eigen benaming voor een vorm die ook bekend staat als orchestrator-worker, coordinator-implementor-verifier (CIV) of maker-checker. In menselijke termen is het vergelijkbaar met een integration manager in Git workflows.

Waarom niet gewoon één lange AI-sessie gebruiken? Omdat context eindig is en gecompacteerd wordt, zelfrapportages na verloop van tijd afwijken van de realiteit, en lessen niet cumulatief worden opgebouwd tussen sessies. Een coördinator met een duurzaam board lost deze drie problemen op.

Heb ik specifiek cmux en Plan Desk nodig? Nee, maar je hebt wel twee functionaliteiten nodig: een manier om programmatisch geïsoleerde agent-sessies te starten en een duurzame task store met een API of MCP-interface.

Hoe verifieert de coördinator het werk? Door de geclaimde commando's opnieuw uit te voeren en de exit-codes te controleren, door diffs te lezen in plaats van transcripten, en door waarden terug te lezen uit het artefact zelf in plaats van uit een variabele.

Wat is een 'red gate' en waarom dit eerst doen? Een red gate is een verificatie-check die vóór de implementatie wordt gedraaid en moet falen. Als de check al groen is, is het werk mogelijk al gedaan of is de test waardeloos. Het voorkomt dat er tijd wordt verspild aan het implementeren van zaken die al bestaan.

Hoe moeten AI-agent sessies met elkaar communiceren? Via twee kanalen: directe berichten voor snelle vragen en vlaggen, en duurzame kanalen (committed bestanden, board-kaarten, share-links) voor zaken die gegarandeerd moeten aankomen. Een bericht is een nudge, een bestand is een contract.

Hoe lang moet een timebox voor een autonome run zijn? Meestal tussen de 15 en 30 minuten. De belangrijkste regel is dat het interval bepaalt hoe vaak er wordt gerapporteerd, niet waar het werk stopt. Items worden altijd afgemaakt, geverifieerd en gecommit voordat er wordt gerapporteerd.

Werkt dit patroon ook met andere modellen dan Claude? Ja, de methodologie is model-agnostisch. Het vereist alleen dat sessies tools kunnen gebruiken, een gedeelde store kunnen bereiken en programmatisch kunnen worden opgestart. Mix-model setups kunnen zelfs beter zijn, omdat een ander model familie fouten kan vinden waar het implementerende model blind voor is.