De Map Is de Agent

Laatst bijgewerkt 18 september 2026

TL;DR: Een agent is geen framework maar een map: een model plus genoeg opgebouwde context om specialist te zijn. Kieran Klaassen draait er 44 van, met een simpele dispatch-laag ertussen — de verfijning zit in de mappen, niet in de orchestratie.

Kieran Klaassen (general manager van Cora, Every's e-mailproduct) probeerde drie maanden lang agent-swarms werkend te krijgen: agents die elkaar aansturen, een lead-agent met een pool van workers, steeds andere orchestratie-frameworks. Het maakte hem niet sneller. Als tien agents tegelijk klaar waren, had hij tien resultaten om te beoordelen zonder genoeg context om te weten welke hij kon vertrouwen. "AI-agents hebben geen snelheidslimiet, maar de persoon die ze aanstuurt wel."

Wat wél werkte had hij al: een map.

Wat een map tot agent maakt

Een agent is niet een Rube Goldberg-machine van bewegende delen, maar een model met genoeg context zodat je niet elke sessie alles opnieuw hoeft uit te leggen. Een projectmap met een CLAUDE.md/AGENTS.md, wat skill-definities en maandenlang opgebouwde context maakt van een generiek model een specialist.

Kieran's ~/cora/-map bevat vier lagen:

Hij geeft elke nieuwe agent een leesvolgorde mee: eerst CLAUDE.md, dan het architectuurdocument, dan het systeemrapport, dan de prompt, dan de component-creator.

Zelfde model, andere map, andere agent

~/cora-agent/ draait op hetzelfde model maar is een compleet andere agent: geen applicatiecode (zodat hij niet per ongeluk productie kan wijzigen), wél skills om AppSignal te bevragen, logs te tailen, een Postgres read-replica te doorzoeken, Intercom-tickets te lezen en GitHub-deploys aan incidenten te koppelen.

Richt Opus op ~/cora/ en het is een Rails-engineer. Richt hem op ~/cora-agent/ en het is een ops-engineer. Alleen de map verandert.

Dit is ook precies wat Claude Skills zijn: mensen zetten al markdown-instructiebestanden in projectmappen vóór iemand het "skills" noemde.

De dispatch-laag

Bij vijf agents ben jij zelf de dispatch-laag — terminaltab openen, naar de map navigeren, sessie starten. Bij tien raak je het overzicht kwijt. Bij 44 is het onhoudbaar.

Kieran's oplossing is opvallend laag-technologisch: een Ruby-daemon die een map in de gaten houdt voor spawn-verzoeken. Een lead-agent breekt een taak op in subtaken en schrijft elke subtaak als bestand weg; de daemon pikt die bestanden op en start workers in de juiste map. Workers rapporteren terug door bestanden te schrijven. De daemon checkt elke 60 seconden de status. Geen custom netwerk, geen agent-to-agent-protocol.

Twee slash-commando's doen het meeste werk:

• /hey — de ochtendbriefing. Per project: wat is af, wat is gefaald, wat is geblokkeerd, welke high-priority issues zijn nieuw.
• /orchestrate — de kickoff. Bijv. /orchestrate "Fix GitHub issue #1765". Lead-agent splitst op, workers starten in de juiste mappen en erven daar de volledige context. Er verschijnt een pull request.

Elke agent krijgt een tmux-pane om live mee te kijken; een dashboard toont een agent tree met status per agent (werkend, wachtend, klaar, fout). Resultaten komen asynchroon binnen als PR's en issue-comments, zodat Kieran ze verwerkt wanneer hém dat uitkomt — niet wanneer de agent klaar is.

Onderbouwing: Anthropic's eigen multi-agent-onderzoek vond dat een Opus-lead met Sonnet-subagents een enkele Opus-agent met 90% versloeg op onderzoekstaken, maar dat multi-agent-systemen 15× meer tokens verbruiken en dat codeertaken minder parallelliseerbare stappen hebben dan onderzoek.

Kieran's setup in de praktijk: Tuin en Erf

In de eerste Show Us Your Folders-sessie bij Every (een terugkerende serie waarin één iemand zijn AI-werkplek opent) liet Kieran de concrete indeling zien — vier onderdelen, met Nederlandse namen:

• Tuin — zijn persoonlijke AI-werkplek: doelen, taken, meeting-notities, ideeën, projecten en persoonlijke dossiers, elk in een eigen map.
• Erf — de coördinator: start agent-sessies en stuurt elke taak naar de map met de relevante bestanden en instructies.
• Een dashboard — de interface: plannen, to-do's, geplande taken, actieve agents en hun sessies.
• Een Mac mini — de machine waar de agents draaien. Omdat die aan blijft staan, werken ze door als Kieran zijn laptop dichtklapt.

Claude Code, Codex, Cursor en zijn eigen tooling gebruiken allemaal dezelfde mappen, dus hij kan van tool wisselen zonder zijn context te verhuizen.

Vier dingen om over te nemen:

1. Eén map per klus. Hebben twee klussen ander bronmateriaal, andere historie of andere regels, dan horen ze in verschillende mappen.
2. Scheid context van dispatch. Tuin bewaart het materiaal, Erf wijst het werk toe. Zo kun je de toewijzing veranderen zonder het materiaal te herordenen.
3. Orden geheugen op tijdschaal. Dagelijkse, wekelijkse, maandelijkse en jaarlijkse geheugenbestanden, met bijpassende planroutines — een dagplan en een maandreview hebben niet dezelfde hoeveelheid historie nodig.
4. Pas het aan je eigen werkwijze aan. Kieran's indeling bouwt voort op een planningspraktijk die hij al ~15 jaar volgt. Iemands systeem klakkeloos overnemen werkt slechter dan er één bouwen dat past bij hoe je al werkt.

Wat er stukgaat op schaal

• De encoding-bug. Wekenlang crashten agents willekeurig. De oorzaak: em-dashes en krulletjes-aanhalingstekens uit geplakte prompts, tegen een daemon die op US-ASCII draaide. "Oprecht dom, en schokkend moeilijk te vinden."
• Context drift. Met tientallen agents draaien sommige verouderde versies van een taak of dupliceren ze werk dat al af is. Kieran heeft hier geen automatische oplossing voor: handmatig snoeien en accepteren dat er tokens verloren gaan.
• Agent stalls. Een agent blijft hangen op "werkend" — te veel API-calls te snel, of wachtend op input. Je merkt het pas als je kijkt, en bij 44 agents kijk je niet altijd.

Je kunt niet vibe-orchestreren

De belangrijkste les: zoals je niet kunt vibe-coden zonder plan en niet kunt vibe-fixen in productie, kun je geen map aan de dispatch-laag geven en hopen dat het goedkomt.

De volgorde: bouw het, gebruik het, vertrouw het, dán orchestreer je het. Kieran zet eerst de map op, bouwt de agent, legt de flows vast (de compound-engineering-loop) en gebruikt ze zelf tot ze voorspelbaar zijn. Pas als hij een flow vertrouwt, draagt hij hem over en stopt hij met meekijken. Sla je die stap over, dan open je pull requests voor werk dat al af is en krijg je dubbele issues.

Werkwijze: laat een agent je eigen werkplek auditen

Every's redactie beschrijft een concrete zelftoepassing: laat een agent je mappenstructuur in kaart brengen en die kaart vervolgens door ce-doc-review halen. De review-vragen: coherentie (zijn de instructiebestanden het eens over prioriteit?), haalbaarheid (kan een agent de laadvolgorde volgen?), product (ondersteunt de opzet het beoogde gebruik?), scope (heeft één bestand te veel beleidsrollen?) en adversarial (waar creëert automatische capture nieuwe faalmodi?).

Bij de auteur leverde dat op: 25 top-level mappen, meer dan duizend ruwe sessiebestanden en drie versies van hetzelfde project over twee machines. De remedie: dubbele roots samenvoegen, runtime-kopieën als wegwerpbaar behandelen, en menselijke review verplicht stellen voordat gevangen context gedeelde richtlijn wordt.

Werkvolgorde:

1. Laat de agent één werkplek in kaart brengen voordat er iets verandert: wat bezit elke map, welke bestanden zijn gezaghebbend, wat is slechts een geïnstalleerde of geëxporteerde kopie.
2. Draai /ce-doc-review op die kaart — laat het dubbele plekken, tegenstrijdige instructies, verouderde indexen en nooit-geconsolideerd materiaal markeren.
3. Beoordeel de bevindingen zelf. Keur alleen wijzigingen goed die een echt faalmodus oplossen, en laat de agent niets verplaatsen, hernoemen of verwijderen vóór jouw akkoord.

Open vragen

• Hoe voorkom je context drift zonder handmatig snoeien? Kieran heeft er expliciet geen oplossing voor; dit is het openstaande probleem van de aanpak.
• Waar ligt de grens waarboven een dispatch-laag loont? Onder de vijf mappen is handmatig starten waarschijnlijk goedkoper dan de daemon bouwen en onderhouden.
• Maakt Anthropic's Managed Agents (gehoste sandboxing, state management, tool-executie) een eigen dispatch-laag overbodig, of blijft dat een laag die je zelf wilt bezitten?
• Hoe verhoudt het map-als-agent-patroon zich tot het tegengestelde advies in Claude Cowork Minimale Setup, waar bestanden en mappen juist als contextvervuiling worden gezien?

Verwante concepten

• Agentic OS — het bredere systeem van context, geheugen en skills; "de map is de agent" is de meest uitgeklede formulering ervan
• Agent-native Architectuur — Every's principes (o.a. Improvement over time via geaccumuleerde context) waarvan dit de dagelijkse praktijk is
• Compound Engineering — de loop waarmee de context in de map wordt opgebouwd; Kieran's voorwaarde vóór orchestratie
• Dynamic Workflows — de complexere orchestratie-route; hier bewust vervangen door een bestandsgebaseerde daemon
• Subagents — de in-sessie variant; hier zijn de "subagents" losse mappen met eigen context
• Geheugen en Context — de geheugenlagen; hier geordend op tijdschaal (dag/week/maand/jaar)
• Claude Cowork Minimale Setup — het tegengestelde standpunt over mappen als contextvervuiling

Bronnen

• Show Us Your Folders — Katie Parrott, 16-09-2026
• The Folder Is the Agent — Kieran Klaassen, 04-09-2026