Wanneer je Claude Code een complexe opdracht geeft, zie je het resultaat. Wat je niet ziet, is alles wat ertussen zit. Een agent die zichzelf opsplitst, zijn geheugen beheert, werk uitvoert dat buiten het gesprek overleeft en zelf beslist wanneer hij klaar is. Dat mechanisme is geen magie. Het is ontwerp.
De hartslag van een agent
Een agent werkt niet lineair. Hij werkt in een cyclus: een actie uitvoeren, het resultaat bekijken, beslissen wat hierna, opnieuw. Die cyclus stopt niet op een vast moment, hij stopt wanneer de agent zelf beslist dat de taak afgerond is. Dat is het fundamentele verschil met een script dat stap voor stap wordt afgewerkt.
In de praktijk betekent dit dat een complexe taak tientallen of zelfs honderden cycli doorloopt voor ze klaar is. Elke cyclus is een beslissingsmoment: wat heb ik net gezien, wat doe ik nu?
Wat me vroeg opviel: bij het bouwen van de website werkte de developer-agent aanvankelijk blind. Hij schreef code, maar zag het resultaat niet. Ik merkte dat de lay-out niet klopte en moest telkens zelf beschrijven wat er misging. Na wat onderzoek en het doorlopen van een tutorial vond ik de oplossing: de Playwright MCP-plugin installeren en de agent expliciet de tools geven om een browser te openen en een screenshot te nemen. Eens die tools beschikbaar waren, veranderde zijn manier van werken. Na elke visuele stap nam hij een screenshot, bekeek het resultaat en besliste op basis van wat hij zag of hij verder kon. Als een ontwerper die een afdruk maakt voor hij een versie goedkeurt.
Dat ene inzicht leerde me iets breder: een agent is zo autonoom als de tools die je hem geeft. Niet meer, niet minder.
Grote taken opsplitsen zonder het overzicht te verliezen
Een complexe opdracht in één keer aan één agent geven werkt niet. Niet omdat het model het niet aankan, maar omdat de hoofdagent al zijn aandacht verliest in de details. Elke bestandslezing, elke API-aanroep, elk tussenresultaat hoopt zich op in zijn werkgeheugen.
De oplossing is subagenten. De hoofdagent breekt de taak op in delen en delegeert elk deel aan een subagent met een eigen, schone context. Die subagent voert zijn deel uit, soms tientallen stappen diep, en geeft enkel het eindresultaat terug. Alle tussenliggende ruis verdwijnt. De hoofdagent houdt overzicht zonder elk detail te hoeven zien.
Bij het bouwen van de Campaign Hub werkte de developer-agent zo. Aparte subagenten voor de databasemigratie, de API-laag en de webhookintegratie. Elk met zijn eigen afgebakende taak. De hoofdagent ontving drie antwoorden, niet driehonderd tussenstappen.
Dit is hoe je ook een goede medewerker instrueert: geef context, definieer het resultaat, vertrouw het proces.
Geheugen dat niet verstopt
Een agent heeft een contextvenster: de hoeveelheid informatie die hij actief kan bevatten. Bij een lange werksessie raakt dat vol. Een codebestand van duizend regels verbruikt al vierduizend tokens. Laat een agent lang genoeg werken en hij begint te vergeten wat hij eerder deed.
Een goed gebouwde agent comprimeert automatisch, in drie lagen. De eerste laag loopt stil na elke stap: oude toolresultaten worden vervangen door een korte samenvatting. De tweede laag treedt in werking wanneer het venster zijn limiet nadert: het volledige gesprek wordt weggeschreven naar schijf en samengevat, waarna die samenvatting de volledige geschiedenis vervangt. De derde laag kan je zelf activeren wanneer je ruimte wil maken.
Niets gaat echt verloren. Alles wordt verplaatst, niet gewist. De agent blijft scherp omdat hij niet meesjouwt wat niet meer relevant is.
Werk dat overleeft buiten het gesprek
Een gesprek eindigt. Een goed taaksysteem niet. Taken worden weggeschreven met hun status en afhankelijkheden: taak B start pas wanneer taak A klaar is, taken C en D lopen parallel. Dat systeem overleeft contextcompressie en sessieafsluitingen. Een volgende sessie bouwt verder waar de vorige stopte.
Bovendien kan een agent trage operaties op de achtergrond uitvoeren terwijl hij al aan de volgende stap werkt. Bij de websitebouw draaide de developer-agent installaties op de achtergrond terwijl hij gelijktijdig configuratiebestanden schreef. Twee dingen tegelijk, zonder dat het ene het andere blokkeerde.
Hoe je dit organiseert in de praktijk
De mechanismen hierboven zijn krachtig. Maar ze werken alleen als de laag eromheen goed georganiseerd is. En daar gaat het bij de meeste implementaties mis.
Na tien weken heb ik mijn systeem opgebouwd in vijf lagen. Elke laag heeft een eigen plek, een eigen formaat en een eigen reden.
CLAUDE.md: de grondwet
Dit is het eerste bestand dat de agent leest in elke sessie. Hier staan geen klantgegevens, geen kennis over mijn methodologie en geen concrete taken. Hier staan gedragsregels: hoe werk ik, welk gereedschap gebruik ik wanneer, hoe los ik conflicten op, wanneer vraag ik bevestiging? CLAUDE.md is kort en gefocust. Alles wat er niet in thuishoort, staat elders. Een agent die een te lange CLAUDE.md krijgt, verliest overzicht. Een agent die een vage CLAUDE.md krijgt, improviseert.
knowledge/: stabiele domeinkennis
Alles wat de agent nodig heeft om goed te werken over langere tijd staat in de knowledge-map. Klantprofielen, merkrichtlijnen, methodologieën, API-referenties, kwaliteitscriteria. Deze kennis verandert niet per gesprek.
Actieve kennisdomeinen zijn elk georganiseerd in drie bestanden. knowledge.md bevat bevestigde feiten en patronen, dingen die zijn getest en kloppen. hypotheses.md bevat observaties die meer data nodig hebben, vermoedens die nog niet bewezen zijn. rules.md bevat regels die standaard worden toegepast, afgeleid uit hypotheses die voldoende bevestigd zijn. Wanneer een hypothese drie keer klopt, verhuist ze naar de regels. Wanneer een regel wordt tegengesproken door nieuwe informatie, gaat ze terug naar de hypotheses. Zo groeit de kennis van het systeem mee met de praktijk.
Die drielaagse structuur is vooral waardevol in domeinen die voortdurend evolueren. AI-strategie is daar het schoolvoorbeeld van. Wat vandaag een bewezen aanpak is, kan over zes maanden achterhaald zijn door een nieuw model, een nieuwe tool of een verschuiving in de markt. Door observaties eerst als hypothese te markeren en pas naar een regel te verplaatsen na voldoende bevestiging, bouw je een kennissysteem dat meegroeit met de praktijk. De agent vertrouwt niet te vroeg op wat nog niet bewezen is, en houdt geen regels vast die de realiteit al hebben ingehaald.
In mijn setup is het de senior-strategist die actief met die drie lagen jongleert. Telkens de markt verschuift, een klantgesprek nieuwe inzichten oplevert of een aanpak wordt bijgestuurd, is het die agent die beoordeelt wat nog geldt, wat hypothese blijft en wat bewezen genoeg is om als regel toe te passen. Zo blijft de Rescope-strategie iteratief, afgestemd op een sector die zichzelf elke paar maanden opnieuw uitvindt.
memory/: wat bewaard blijft over gesprekken heen
Claude Code heeft twee lagen van geheugen. De eerste is ingebouwd en onzichtbaar: een verborgen map buiten je projectfolder die Claude automatisch laadt bij elke sessie. Je ziet die map niet in je editor, maar ze bestaat en werkt stilzwijgend op de achtergrond. Hier bewaart het systeem onder andere je persoonlijke voorkeuren en sessieinstellingen.
De tweede laag heb je zelf gebouwd. In de projectfolder zelf hebben we een memory/-map aangemaakt met een MEMORY.md als index, één bestand dat bij elke sessie automatisch geladen wordt en verwijst naar aparte bestanden per categorie. Voor elke categorie een eigen bestand: genomen beslissingen met de redenering erachter, signalen uit de markt, klantinzichten, open vraagstukken. Die bestanden schrijven we zelf weg, na gesprekken of na afgeronde taken. Beknopt, maximaal dertig regels, kern plus redenering. Niet als archief maar als werkgeheugen.
Het verschil met de ingebouwde laag: deze is zichtbaar, doorzoekbaar en bewust samengesteld. Je weet precies wat er instaat en waarom.
Credentials: lokaal, nooit naar de cloud
Alle wachtwoorden, API-sleutels en tokens staan in één lokaal bestand: .env. De agent weet waar hij dat bestand kan vinden en haalt er de juiste waarden uit wanneer hij een externe dienst moet aanspreken. Dat bestand staat nooit in GitHub. De repository bevat de code en de structuur, maar nooit de sleutels. Een .gitignore-regel zorgt ervoor dat .env automatisch wordt uitgesloten. Wie de code kloont, kan niets met externe systemen doen zonder zijn eigen credentials in te vullen. Zo blijft het systeem deelbaar zonder veiligheidsrisico.
Drie mechanismen die het systeem verbeteren
De meeste systemen groeien maar worden nooit beter. Mijn systeem heeft drie ingebouwde verbetermechanismen.
knowledge/lessons.md is een logboek van fouten en correcties. Wanneer de agent iets fout doet of wanneer ik een aanpak bijstuur, wordt dat met datum en context weggeschreven. Bij het begin van elke sessie leest de agent dit bestand. Niet als straf, maar als geheugen. Dezelfde fout twee keer maken is een teken dat er geen lessons.md is.
knowledge/quality-gates.md bevat per outputtype een concrete checklist. Voor een nieuwsbrief zijn dat zeven criteria, van woordtelling tot responsive HTML. Voor een offerte andere criteria. Voor een blogartikel drie verplichte lezingen. De agent loopt de lijst af voor hij een taak als afgerond markeert en bevestigt aan mij welke punten zijn nagegaan. Zo hoef ik niet zelf te controleren wat ik aan het systeem kan overlaten.
knowledge/daily/ bevat een dagelijkse log per datum. Wat is er gedaan, welke beslissingen zijn genomen, welke punten staan nog open. Maximaal tien tot vijftien regels. Bij meerdere sessies op dezelfde dag wordt er aangevuld, niet overschreven. Zo is er altijd een chronologisch overzicht van wat er is gebeurd, bruikbaar voor continuïteit en voor terugblikken.
De les die alles samenvat
De verwarring tussen deze lagen is het meest voorkomende probleem bij organisaties die AI serieus willen nemen. Alles in één prompt stoppen. Eén document dat tegelijk de grondwet, de domeinkennis en het geheugen moet zijn. En dan verbazen waarom de agent soms dingen weet en soms niet, waarom hij dezelfde fout twee keer maakt, waarom hij na elk gesprek opnieuw ingewerkt moet worden.
Het antwoord is bijna nooit het model. Het is de structuur eromheen.
De kwaliteit van een agent staat of valt met de informatie die hij krijgt, het moment waarop hij die krijgt en de structuur waarin die georganiseerd is. Dat is geen technische uitdaging. Dat is een organisatievraagstuk. En net zoals kennismanagement bij mensen pas werkt als er een structuur achter zit, werkt het bij AI pas als je nadenkt over wat waar hoort en waarom.
Hoe begin je hier zelf aan?
Die vraag stelt bijna iedereen die dit leest. En eerlijk antwoord: niet door meteen een productieomgeving op te zetten.
Begin in een gesloten experiment. Kies één concreet project, één team, één use case, en bouw het volledig uit voor je het breder uitrolt. Niet als proof of concept, maar als echte werkomgeving, waarbij je sandboxes gebruikt, test-omgevingen die los staan van productie, zodat je gecontroleerd kunt werken zonder impact op de rest van de organisatie.
Betrek ook niet alleen IT. De mensen die de bedrijfslogica kennen, die weten hoe een uitzondering eruitziet, die de klanttoon bewaken, die zijn even onmisbaar als de technicus die het systeem bouwt. Een agent is zo goed als de kennis die hij meekrijgt, en die kennis zit bij je mensen, niet in een handleiding.
Een goede instap is Claude Desktop: installeer de app, geef toegang tot een lokale map, en begin klein. Maar ga snel over naar Claude Code in VS Code of een andere editor. Daar zie je per bestand wat de agent aanpast, hoe hij plant, hoe taken worden opgesplitst. Die zichtbaarheid is geen luxe, het is de snelste manier om te begrijpen hoe orchestratie in de praktijk werkt.
Investeer ten slotte eerst in begrip. Acht tot tien uur goede tutorials, voor je één euro uitgeeft aan tooling of implementatie. Niet omdat de technologie ingewikkeld is, maar omdat je het verkeerd inzet als je niet begrijpt hoe het werkt. Een goede start is deze video van Nick Saraev, die het systeem rustig en grondig uitlegt. Dat is geen luxe, dat is de voorwaarde.