Claude Code Agentic OS Framework: Zo bouwde ik mijn eigen systeem

Claude Code Agentic OS Framework: Zo bouwde ik mijn eigen systeem

Ik heb zes maanden lang Claude Code behandeld als een razendsnelle stagiair. Slim, onvermoeibaar, af en toe briljant — en vergeetachtig op precies de momenten die mij de meeste tijd kostten. Elke sessie begon met opnieuw uitleggen van dezelfde merktoon, dezelfde mappenstructuur, dezelfde regels die ik al op drie andere plekken had vastgelegd. Elke vaardigheid die ik opbouwde stond op zichzelf. Elke automatisering die ik opzette werkte perfect tot ik het moest overdragen aan iemand die niet thuis is in een terminal.

Toen ben ik gestopt met het bouwen van losse tools en ben ik begonnen aan een systeem.

Wat ik hier ga uitleggen is het Claude Code agentic OS framework waar ik op uitkwam na drie keer mijn stack volledig af te breken en opnieuw op te bouwen in Q1 2026. Het is geen product. Het is geen plugin. Het is een architecturaal patroon dat van Claude Code geen gewone code-assistent maakt, maar iets dat veel meer lijkt op een persoonlijk besturingssysteem — een OS dat zich zaken herinnert, consistent uitvoert, en overdraagbaar is aan klanten die nog nooit een terminal hebben geopend.

De sleutel tot deze doorbraak was simpel: de meeste Claude Code-opzetten gaan stuk op drie vaste plekken. Geheugen, consistentie en toegankelijkheid. Sluit deze drie gaten, en de tool houdt op een tool te zijn. Het wordt infrastructuur.

De Drie Gaten in Elke Claude Code-Setup

Voordat de architectuur logisch wordt, moet het probleem dat ze oplost specifiek zijn. Want als je Claude Code langer dan een paar weken gebruikt, heb je ze waarschijnlijk alle drie gevoeld zonder ze zo te noemen.

Gat één: geheugen. Claude Code is stateless tussen sessies, tenzij je het een plek geeft om te bewaren wat het leert. CLAUDE.md helpt, maar het is één bestand dat de taak van een archiefkast op zich neemt. Zodra je wilt dat de agent de voorkeuren van een klant, de geschiedenis van een project, of een beslissing van drie weken geleden onthoudt — kun je weer opnieuw alles uitleggen. De meeste mensen horen "geheugen" en denken dan aan een volledige RAG-pijplijn met Pinecone- of Supabase vector-embeddings. Voor 90% van de workflows is dat veel te veel. Je hebt persistentie nodig, geen semantische zoekfunctie over een miljoen documenten.

Gat twee: consistentie. Vraag Claude Code op maandag om een blogpost te schrijven en je krijgt het één. Vraag het op vrijdag op precies dezelfde manier en je krijgt iets anders — andere toon, andere structuur, andere footer. Die variatie is niet de schuld van het model. Het is een prompt engineering-probleem dat eruit ziet als een modelprobleem. Zonder gestructureerde skills die coderen hoe je het werk wilt laten uitvoeren, is elke opdracht een nieuwe gok. Skills en automatiseringen lossen dit op, maar alleen als ze georganiseerd zijn als een echte operatie, en niet lukraak in een platte ~/.claude/skills/-map worden gedumpt.

Gat drie: toegang. Dit is het gat waar niemand over spreekt, omdat technische oprichters het niet voelen. Maar als je ooit geprobeerd hebt Claude Code over te dragen aan een niet-technische collega, een klant, of zelfs je eigen brein om 22:00 uur wanneer je geen zin hebt om claude --continue --session-id foo te typen — dan ken je het gevoel. De terminal is een slotgracht. Voor jou is het een feature. Voor iedereen anders is het een muur.

Het agentic OS-framework is wat je krijgt als je stopt met deze drie gaten los van elkaar oplossen, en ze samen gaat aanpakken.

Wat Een Agentic OS Eigenlijk Is

De term "agentic OS" wordt vaak losjes gebruikt. Dit is wat ik ermee bedoel in deze specifieke context: een architectuur waarbij Claude Code de uitvoeringsmotor is, een persistente geheugenlaag continuïteit biedt, een hiërarchisch vaardighedensysteem zorgt voor consistentie, en een dashboard niet-terminalgebruikers toegang geeft.

Vier lagen. Dat is het hele concept.

┌─────────────────────────────────────────────┐
│  Dashboard / Command Center (Next.js)       │  ← toegang
├─────────────────────────────────────────────┤
│  Skills + Automations (lokaal + remote)     │  ← consistentie
├─────────────────────────────────────────────┤
│  Memory Layer (Obsidian vault, Markdown)    │  ← geheugen
├─────────────────────────────────────────────┤
│  Claude Code (engine)                       │  ← uitvoering
└─────────────────────────────────────────────┘

Deze architectuur werkt omdat elke laag één duidelijke taak heeft, en ze elkaar niet in de weg zitten. Claude Code doet waar het al goed in is: redeneren, code schrijven, en meerstaps taken uitvoeren. Obsidian verzorgt de persistentie omdat het van zichzelf al een besturingssysteem op basis van Markdown-bestanden is—precies het formaat dat Claude Code native leest en schrijft. Skills en automations zetten ad-hoc prompts om in betrouwbare workflows. Het dashboard omhult dit alles in een klikbare interface.

Ik wil hierbij iets markeren dat mij het meest verraste tijdens het bouwen: het dashboard is het onderdeel dat de rekensom voor niet-technische gebruikers verandert, maar het is óók het onderdeel dat mijn eigen werkwijze heeft veranderd. Later meer hierover. Houd dit in gedachten terwijl we verdergaan.

Laag Eén: Geheugen Zonder RAG

Laat ik beginnen met het onderdeel dat mij het meeste herwerk heeft gekost.

Ik heb twee weekenden in februari besteed aan het bouwen van een degelijke RAG-geheugenlaag voor Claude Code. Supabase als vector store, OpenAI-embeddings, een aangepaste MCP-server waarmee Claude semantisch kon zoeken. Het werkte. Maar het was totaal overgeëngineerd voor wat ik werkelijk nodig had: “onthoud wat we vorige week dinsdag besloten hebben.”

Ik heb alles eruit gesloopt en vervangen door een Obsidian vault. De hele laag was in ongeveer 40 minuten opgezet.

Dit is waarom Obsidian specifiek als AI-geheugenlaag voor Claude Code werkt:

• Obsidian vaults zijn gewoon mappen met Markdown-bestanden. Geen proprietair formaat. Geen database. Geen synchronisatielaag waar je op moet letten. Claude Code leest en schrijft Markdown native, wat betekent dat het “geheugensysteem” letterlijk gewoon toegang tot het bestandssysteem is.
• Wiki-achtige links ([[note-name]]) geven je structuur zonder schema. Claude kan door links lopen zoals een mens dat zou doen, en volgt hierdoor draadjes tussen notities.
• Het is gratis, lokaal en draagbaar. Als ik besluit Claude Code in te ruilen voor Codex CLI of wat er volgende maand ook uitkomt, verhuis ik mijn geheugensysteem gewoon mee. Geen vendor lock-in.
• Obsidian zelf maakt de vault visueel aantrekkelijk voor mensen. Als ik terug wil lezen wat de agent heeft geschreven, hoef ik geen databasequery te doen. Ik open Obsidian en lees gewoon mee.

Mijn vault-structuur ziet er ongeveer zo uit:

~/vault/
├── _claude/
│   ├── CLAUDE.md              # globale context, wordt elke sessie geladen
│   ├── session-logs/          # wat er gebeurde per run
│   └── decisions/             # waarom ik bepaalde keuzes maakte
├── clients/
│   └── [client-name]/
│       ├── brief.md
│       ├── brand-voice.md
│       └── delivered/
├── projects/
│   └── [project-name]/
└── knowledge/
    ├── claude-code-patterns.md
    └── skills-registry.md

Het cruciale element is _claude/CLAUDE.md. Dit bestand is het toegangspunt voor Claude Code in de vault — de inhoudsopgave van de agent. Hierin staat waar de client briefs te vinden zijn, waar sessielogs moeten worden weggeschreven, en welke bestanden beslissingen bevatten die nooit betwist mogen worden. Elke sessie leest de agent eerst dit bestand en navigeert daarna naar het relevante deel van de vault.

Voor de meeste lezers die twijfelen tussen “een RAG-systeem bouwen” of “een Obsidian vault opzetten” — begin met de vault. Je kunt altijd later nog RAG toevoegen op het moment dat semantische zoekopdrachten daadwerkelijk belangrijk worden. Ik ben die schaal nog niet tegengekomen, en ik draai deze setup al drie maanden over vier merken en 230+ contentstukken. Als je een uitgebreidere uitleg wilt, heb ik eerder geschreven over Obsidian als persistent geheugen voor Claude Code en waarom een platte knowledge vault meestal beter werkt dan een RAG-pijplijn.

Nog één belangrijke opmerking voordat we doorgaan — de geheugenlaag is niet optioneel in dit framework. Zonder dit heeft de skill-laag geen basis om aan te koppelen. Consistentie vereist immers iets om consistent mee te zijn. Dat leidt ons naar het volgende onderdeel.

Laag Twee: Vaardigheden en Automatiseringen, Gestructureerd als een Organogram

Dit is de laag waar de meeste agentic OS-pogingen vervallen in chaos.

De fout die ik keer op keer zie — en die ik zelf een tijd lang heb gemaakt — is om elke vaardigheid gewoon in één platte map te gooien. ~/.claude/skills/post-writer, ~/.claude/skills/research, ~/.claude/skills/social-scheduler, nog dertig anderen. Vervolgens mag je zes weken later proberen te herinneren welke welke doet.

De oplossing is om te stoppen met het zien van vaardigheden als scripts en ze in plaats daarvan te zien als rollen binnen een team.

Dit is de hiërarchie waar ik op uit ben gekomen:

Functies zijn de brede domeinen van werk. "Contentproductie." "Onderzoek." "Klantbeheer." "Merkmonitoring." Dit zijn geen vaardigheden — het zijn categorieën waartoe een vaardigheid behoort.

Vaardigheden zijn elementaire, herbruikbare taken binnen een functie. Binnen "contentproductie" heb ik bijvoorbeeld blog-post-writer, image-brief-generator, social-distribution-package. Elke vaardigheid doet één ding goed. Elk heeft een eigen SKILL.md bestand waarin staat wanneer Claude het moet gebruiken, welke input vereist is, en wat het resultaat zal zijn.

Subvaardigheden nemen het specialistische werk op zich dat door een bovenliggende vaardigheid wordt gedelegeerd. blog-post-writer heeft subvaardigheden voor de onderzoeksfase, stemafstemming, SEO-structurering en zelfevaluatie. De ouder coördineert; de subvaardigheden voeren uit.

Automatiseringen zijn vaardigheden met triggers. Dezelfde vaardigheid, maar nu draait deze op een tijdschema of start automatisch wanneer er iets gebeurt. Geplande automatiseringen worden aangestuurd door cron. Automatiseringen op aanvraag worden geactiveerd door een druk op de knop in het dashboard of een hook in Claude Code zelf.

Claude Code heeft eerder dit jaar een skill-creator plugin uitgebracht in de officiële marketplace die het meeste van de basis biedt. Door /plugin install skill-creator te draaien binnen Claude Code start je een begeleide workflow: beschrijf de vaardigheid, test hem met echte input, verbeter de prompt, commit naar je skills-map. Het ecosysteem rondom deze plugin is enorm — de community-marktplaatsen op tonsofskills.com en claudemarketplaces.com vermelden in april 2026 duizenden plugins en agents, en de meeste passen moeiteloos in deze hiërarchie als je ze op functie organiseert.

De reden dat deze hiërarchische opzet belangrijk is, is niet alleen esthetisch. De routeringslogica van Claude Code zelf werkt namelijk beter als de vaardigheden geordend zijn. Wanneer de agent moet bepalen welke vaardigheid gebruikt moet worden, vindt die beslissing plaats binnen zijn context window. Een platte map met 60 vaardigheden verspilt tokens aan het uitzoeken van de juiste. Een hiërarchie van vier functies, elk met zes tot acht vaardigheden, elk met benoemde subvaardigheden, laat de agent snel inzoomen.

Wil je meer diepgang over de hiërarchie zelf, dan heb ik die volledig uiteengezet in mijn Claude Code agent teams playbook en de advanced agent skills guide. Beide zijn clusterposts bij dit artikel.

Lokaal vs Remote Automatisering: De Beslissing Die Echt Telt

Zodra skills bestaan, is de volgende vraag waar ze draaien. Hier raken veel projecten verward, want het verschil tussen lokale en remote automatisering draait niet om complexiteit — het draait om wat de skill moet aansturen.

Lokale automatiseringen draaien op je eigen machine. Ze hebben toegang tot je bestandssysteem, je geïnstalleerde CLI’s, je lokale Obsidian-kluis, je git-repositories, je schermopnames, alles wat je daar lokaal hebt staan. Je moet ingelogd zijn. Als je laptop slaapt, slapen zij ook.

Remote automatiseringen draaien in de cloud — meestal via Claude Routines, die Anthropic uitrolde als onderdeel van het $20/maand-abonnement en met de update van april 2026 flink uitbreidde. Ze draaien onafhankelijk van je machine. Geen toegang tot je bestandssysteem, geen lokale CLI’s, maar ook geen afhankelijkheid van jouw online aanwezigheid.

De beslissingsboom die ik gebruik, is letterlijk deze vraag: moet deze skill iets aansturen wat lokaal staat? Zo ja, lokaal. Zo nee, remote. Geen getwijfel.

Concrete voorbeelden:

Kandidaten voor lokale automatisering:

• Diepgaande onderzoeksworkflows die Firecrawl CLI gebruiken voor scraping, Notebook LM voor synthese, en de output wegschrijven naar een Obsidian-notitie. Hiervoor zijn lokale CLI’s en het lokale bestandssysteem nodig — moet dus lokaal.
• Video-naar-blog-pijplijnen waarbij ik een video download, deze lokaal transcribeer, het transcript naar Claude Code stuur en het bericht opsla als content/mejba.me/[slug].md. Bestanden zijn lokaal. Automatisering is lokaal.
• Codebase-refactors waarbij Claude Code daadwerkelijk repositorybestanden op schijf aanpast.
• Screenshot-gebaseerde designreview-skills die een lokaal browservenster vastleggen en dat naar de agent sturen.

Kandidaten voor remote automatisering:

• Dagelijkse websearch + rapport die elke ochtend om 6 uur AI-nieuws opzoekt, een overzicht samenstelt, en dit als Markdown-bestand pusht naar een GitHub-repo. Niets lokaals betrokken. Draait volledig in de cloud. Ik word wakker, doe git pull, lees de samenvatting.
• Geplande merkmonitoring — zoeken naar vermeldingen van het merk van een klant elk uur, logt alles nieuws in een Notion-database. Pure cloudflow.
• Nieuwsbrief schrijven vanuit een RSS-feed elke zondagavond, afgeleverd als concept in Ghost of Beehiiv via API. Geen lokale toestand.
• Lead research en outreach-drafting — elke nacht leads ophalen uit een lijst, elk bedrijf onderzoeken, een gepersonaliseerde outreach-mail opstellen en deze als concept klaarzetten voor menselijke review.

Het onderscheid is zo belangrijk vanwege de kosten en betrouwbaarheid. Remote automatiseringen kosten je niets als ze om 3 uur ’s nachts falen — ze proberen het gewoon opnieuw. Lokale automatiseringen die om 3 uur ’s nachts crashen, zijn een doodlopende taak tot je wakker wordt. Maar lokale automatiseringen kunnen dingen die remote processen fundamenteel niet kunnen, omdat ze ín je werkplek draaien.

Ik verdeel het framework ruwweg 60/40 lokaal-naar-remote, maar dat is afhankelijk van mijn werkzaamheden. Doe jij vooral SaaS-operaties, CRM, e-mail en cloud-native tools, dan slaat jouw verhouding waarschijnlijk veel meer door richting remote. Ik heb elders geschreven over Claude Code’s cloud automation channels en de eerste Claude Routines-build die ik shipte op Opus 4.7 als je dieper wilt duiken in beide kanten.

Laag Vier: Het Dashboard Is Het Hele Punt

Hier wil ik even pauzeren en een bekentenis doen.

Toen ik voor het eerst hoorde "bouw een dashboard bovenop Claude Code", was mijn reactie die van een typische engineer: waarom zou ik een UI zetten op een CLI-tool die ik vloeiend gebruik? De terminal is sneller. Ik kan dingen pipen. Ik kan aliassen maken. Een dashboard klinkt als extra frictie vermomd als toegankelijkheid.

Die reflex was fout. Het bouwen van het dashboard heeft mijn gebruik van Claude Code sterker veranderd dan welk ander onderdeel van het framework dan ook.

Dit heb ik gemist: de terminal is geoptimaliseerd voor het moment waarop je een taak begint. Cold start, volle focus, koffie in de hand — je typt het commando en je bent vertrokken. Maar de terminal is waardeloos in de momenten tussen taken in. Controleren wat de nachtelijke automatiseringen hebben opgeleverd. Monitoren van een langdurige onderzoeksjob. Een skill-invocation overdragen aan een collega die geen code schrijft. Snel kijken wat er gisteren draaide terwijl je zit te lunchen. Voor al die momenten wint een dashboard.

Wat ik gebouwd heb, is een eenvoudige Next.js 15-app die lokaal draait en vijf dingen toont:

1. Skill launcher — elke skill uit mijn hiërarchie verschijnt als knop, gegroepeerd per functie. Klik, vul een kort formulier in (klant, project, parameters), druk op gaan. Het dashboard start Claude Code met de juiste parameters.
2. Aankomende routines — toont alles dat gepland staat in de komende 24 uur. Zo vang ik fouten op vóór ze plaatsvinden, niet erna.
3. Recente activiteit — een feed van wat Claude de laatste 48 uur heeft gedaan, opgehaald uit de session-logs map in mijn Obsidian-vault. Elke entry linkt naar het volledige logbestand.
4. Systeemgebruik — tokenverbruik per skill per dag, per model. Zo detecteer ik automatiseringen die ongemerkt Opus-tokens verbruiken, terwijl Haiku volstaat.
5. Output inbox — alles wat Claude heeft geproduceerd en nog op mijn review wacht. Blogconcepten, onderzoeksrapporten, conceptmails.

Het dashboard telt grofweg 800 regels TypeScript. Het is niet ingewikkeld. Wat transformerend is, is niet de code — het is de operationele verandering. Als alles een knop heeft, delegeer ik anders. Ik delegeer méér. Ik delegeer aan een collega die Claude Code nooit via de terminal had kunnen gebruiken.

En dat laatste sluit het toegangsgat daadwerkelijk. Ik kan een klant op het dashboard wijzen, zeggen "klik hier om een concept van je wekelijkse update te genereren", en ze krijgen waarde uit Claude Code zonder ooit te weten wat Claude Code is. Dat is de verschuiving van "tool" naar "infrastructuur".

Ben je een solo-operator, bouw dan het dashboard eerst voor jezelf voordat je je bekommert om klanten. Je zult verbaasd zijn hoeveel je eigen gedrag verandert zodra de frictie verdwijnt.

Een Praktisch Bouwpad Dat Je Echt Kunt Volgen

Genoeg architectuur. Hier is de volgorde die ik zou aanhouden als ik vandaag opnieuw zou beginnen, afgestemd op iemand die Claude Code al een paar keer per week gebruikt.

Week één: geheugen. Installeer Obsidian (gratis, obsidian.md). Maak een vault aan. Zet de mappenstructuur op zoals hierboven getoond. Schrijf je _claude/CLAUDE.md met vijf secties: wie je bent, aan welke merken/projecten je werkt, waar de bestanden staan, hoe de agent moet schrijven, wat de agent nooit mag doen. Maak het niet te ingewikkeld. Je herschrijft het toch drie keer in de eerste maand. Wijs vervolgens Claude Code naar de vault — ofwel door het te starten vanuit de vault-map, of door het vaultpad te verwijzen in je globale CLAUDE.md. Voer een paar echte taken uit en kijk wat de agent terugschrijft.

Week twee: twee skills. Kies de twee taken die je het vaakst doet. Voor mij waren dat “schrijf een blogpost van een videosamenvatting” en “genereer een social distributiepakket van een artikel.” Installeer de skill-creator plugin via /plugin binnen Claude Code. Gebruik deze om elke skill te laten opzetten. Test elke skill vijf keer op echte input. Itereer de prompt tot de output consistent is. Commit de skills naar je persoonlijke skills-directory.

Twee afgeronde skills zijn genoeg om te weten of het framework werkt in jouw workflow. Bouw niet verder tot deze betrouwbaar zijn.

Week drie: één automatisering. Kies één skill die baat heeft bij draaien op schema of op aanvraag. Als er lokale bestanden nodig zijn, zet het op als een lokale cron job die Claude Code headless aanroept. Als dat niet nodig is, gebruik Claude Routines om het in de cloud te plannen. Eén automatisering. Laat het een week draaien. Stem het schema af. Los edge cases op.

Week vier: dashboard v0. Bouw de meest basale versie. Vijf knoppen die een shell-opdracht naar Claude Code sturen. Geen authenticatie, geen database, draait op localhost:3000. Als je geen frontend-specialist bent, scaffoldd de hele frontend met de frontend-design skill in Claude Code op basis van een beschrijving. Mijn v0 was één React-component. De verfijning volgde later.

Week vijf en verder: breid uit wat bestaansrecht heeft. Voeg een skill toe als er een terugkerend patroon ontstaat. Voeg een automatisering toe als je merkt dat je dezelfde skill steeds handmatig op hetzelfde moment uitvoert. Voeg een dashboard-knop toe als je iets wilt overdragen of ophoudt met telkens dezelfde opdracht typen. Breid niet uit om het uitbreiden. Het framework beloont terughoudendheid — elke skill die je toevoegt kost prompt-context die de agent bij elke besluitvorming moet betalen.

Wil je een gedetailleerdere walkthrough van de agent-teams kant hiervan, bekijk dan mijn Claude Code agent teams setup-guide voor veel meer diepgang over de skill hiërarchie dan ik hier kan behandelen.

Wat De Meeste Build-Gidsen Fout Doen

Ik wil drie zaken aanstippen die ik steeds terugzie in andere agentic OS-verslagen, waarvan ik denk dat ze fout zijn, of op z'n minst incompleet, gebaseerd op drie maanden daadwerkelijk draaien.

"Je hebt RAG nodig." Nee, dat heb je niet. Niet op de schaal waarop de meeste individuele gebruikers of kleine teams werken. Een goed georganiseerde Obsidian-vault met 500 notities helpt je meer dan een vector-database met een miljoen embeddings, want de organisatie zelf is het retrieval-systeem. RAG loont pas als je zoekt in tienduizenden documenten waarvan je de structuur niet kunt voorspellen. Als je de structuur wél kunt voorspellen, verslaat structuur altijd vectoren. Wanneer ik uiteindelijk op een schaal kom waarbij ik semantisch zoeken nodig heb, voeg ik dat toe als een extra laag. Niet eerder.

"Bouw elke skill zelf." Het community-ecosysteem rondom Claude Code in 2026 is enorm en de meeste mensen die gidsen schrijven onderschatten dat. De officiële Anthropic-marktplaats heeft gevalideerde plugins. Op community-marktplaatsen staan er nog duizenden meer. Voordat je een skill zelf schrijft, zoek eerst even. Ik heb drie van mijn eerste handgemaakte skills vervangen door betere community-versies. Het framework draait om jouw hiërarchie en je memory layer — de individuele vaardigheden kunnen overal vandaan komen.

"Het dashboard is voor niet-technische gebruikers." Half waar. Het is voor niet-technische gebruikers én voor jou op elk moment waarop je niet met volledige focus achter je toetsenbord zit. Ik gebruik mijn eigen dashboard vaker dan wie dan ook in mijn team. De visie van "toegankelijkheid voor cliënten" doet zwaar tekort aan wat een goede command-center-UI betekent voor de bouwer zelf.

Waar Dit Framework Faalt

Eerlijkheid gebiedt me de grenzen te benoemen.

Het framework gaat ervan uit dat je een workflow hebt die het coderen waard is. Als je eenmalig experimenteel werk doet — onderzoeksproeven, nieuwe problemen, oprechte creatieve verkenning — dan zal de overhead van skills en automatiseringen je juist vertragen. Voor creatief werk open ik nog steeds gewoon Claude Code, zonder CLAUDE.md, zonder skills, zonder vault, en laat ik het puur draaien. Het agentic OS is bedoeld voor herhaalbaar werk. Zorg dat wat je codeert daadwerkelijk herhaalbaar is voordat je het framework toepast.

Het gaat er ook vanuit dat je het onderhoudt. Skills verouderen. Prompts die waren getuned voor Opus 4.5 moeten misschien worden aangepast voor Opus 4.7. Automatiseringen gaan stuk wanneer externe API's veranderen. Ik besteed ongeveer twee uur per week aan het onderhoud van het framework zelf — vooral het bijwerken van prompts als het modelgedrag verschuift en het weghalen van skills die ik niet meer gebruik. Die onderhoudskosten zijn reëel. Als je het framework opzet en het drie maanden laat liggen, zal er ongetwijfeld verval optreden.

En het gaat ervan uit dat je Claude Code vertrouwt om zelfstandig te handelen. Het dashboard maakt het makkelijker om skills te triggeren zonder erover na te denken. Automatiseringen draaien zonder toezicht. Als je geen review-checkpoints in de skills zelf bouwt, ontdek je vroeg of laat dat de agent iets heeft uitgevoerd wat niet de bedoeling was. De veiligheidsmaatregelen moeten ingebouwd zijn in de skill-definities — zelfevaluatiestappen, output-reviewpoorten, expliciete stopcondities. Een framework dat snel draait zonder controles is een framework waarmee je jezelf op schaal te kijk zet.

De verschuiving die echt telt

Zes maanden geleden bestond mijn gebruik van Claude Code uit een stapel terminaltabbladen en een CLAUDE.md die wekelijks met veertig regels groeide. Het werkte. Maar het stapelde niet op. Elke nieuwe taak vergde opnieuw context laden, elke nieuwe klant werd weer een bestand in een map die ik zelden opende, en elke goede prompt die ik schreef bleef in mijn shellgeschiedenis tot deze weer verdween.

Het agentic OS framework veranderde deze rekensom van compounding. Geheugen in de vault betekent dat wat ik in maart heb geleerd, in april nog steeds bruikbaar is. Skills houden in dat de prompt die ik voor de ene klant optimaliseerde, dezelfde is die ik vervolgens voor de volgende twintig gebruik. Dashboards zorgen ervoor dat werk verschuift van "Mejba moet dit zelf om 22:00 uitvoeren" naar "iedereen in het team kan op deze knop klikken".

Het verschil tussen een krachtig hulpmiddel en bruikbare infrastructuur ligt zelden aan het hulpmiddel zelf. Claude Code kon dit al sinds de eerste releases. Wat ontbrak was de architectuur eromheen. Geheugen. Consistentie. Toegang. Als je deze drie sluit, verandert de rekensom over wat je solo — of met een klein team — kunt uitvoeren fundamenteel.

Als je maar één ding uit deze post opbouwt, bouw dan de Obsidian vault. Die ene stap leverde mij meer op dan de andere drie lagen samen, omdat het het fundament is waar alle andere lagen op rusten. Skills hebben geheugen nodig voor consistentie. Het dashboard moet sessielogs kunnen tonen. Automatiseringen hebben een plek nodig om uitvoer te schrijven, zodat anderen die kunnen lezen.

Je Claude Code werkt vandaag prima. Maar de vraag is of de honderdste keer dat je het gebruikt waardevoller zal zijn dan de eerste keer — of gewoon honderd keer hetzelfde zal zijn.

Veelgestelde Vragen

Wat is een agentic OS-framework voor Claude Code?

Een agentic OS-framework is een architectuur die Claude Code omhult met vier lagen — persistente geheugenopslag, hiërarchische skills, lokale en remote automatiseringen, en een dashboard — zodat de agent context over meerdere sessies onthoudt, taken consistent uitvoert en bruikbaar is voor niet-technische teamleden. Het transformeert Claude Code van een CLI-tool naar operationele infrastructuur. De volledige architecturale uiteenzetting vind je in de sectie "Wat Is Een Agentic OS Echt".

Heb ik een RAG-pijplijn nodig om Claude Code geheugen te geven?

Nee, de meeste workflows hebben geen RAG nodig. Een Obsidian-vault met gestructureerde Markdown-notities, met een _claude/CLAUDE.md als ingangspunt, geeft Claude Code persistente geheugenopslag zonder de complexiteit van vector-embeddings. Claude Code leest Markdown standaard, dus de vault is zowel opslag als retrieval. Voeg pas RAG toe als je semantische zoekopdrachten nodig hebt over tienduizenden ongestructureerde documenten.

Wat is het verschil tussen lokale en remote Claude Code-automatiseringen?

Lokale automatiseringen draaien op je eigen machine en hebben toegang tot het bestandssysteem, lokale CLI’s en Obsidian-vaults — ideaal voor onderzoeks-pijplijnen, codebase-werk en alles met lokale bestanden. Remote automatiseringen draaien in de cloud via Claude Routines en opereren onafhankelijk van je eigen machine — perfect voor geplande webzoektochten, merkmonitoring en cloud-API-workflows. De beslisregel: als een skill iets lokaals moet benaderen, draai hem lokaal.

Hoe verschillen Claude Code-skills van plugins?

Plugins zijn het distributieformaat; skills zijn de inhoud. Een plugin is een map met een plugin.json-manifest die één of meerdere skills (SKILL.md-bestanden) kan bundelen, samen met slashcommands en hooks. Je installeert een plugin via het /plugin-commando binnen Claude Code, waarna de skills automatisch worden toegevoegd. Vanaf april 2026 hosten de officiële Anthropic-marktplaats en community-marktplaatsen zoals tonsofskills.com duizenden plugins en skills.

Kunnen niet-technische gebruikers Claude Code echt bedienen via een dashboard?

Ja, en dat is precies het praktische nut van zo'n dashboard. Een lokaal Next.js-dashboard met aanklikbare skill-knoppen, recente activiteiten en geplande routines maakt het mogelijk voor iedereen om Claude Code-workflows te starten zonder de terminal aan te raken. Het dashboard voert op de achtergrond commando’s uit naar Claude Code — de gebruiker ziet knoppen, klikt, en krijgt output. Zo draag ik skills over aan klanten en teamgenoten die nog nooit een terminal hebben geopend.

Laten We Samenwerken

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

• 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