Ik Bouwde Mijn AI-Besturingssysteem Met Claude Code

Ik Bouwde Mijn AI-Besturingssysteem Met Claude Code

Negen jaar lang heb ik elke productiviteitsstack op de markt geprobeerd. Notion. ClickUp. Obsidian bovenop Notion. Sunsama gekoppeld aan Calendar. Een abonnement op zeven SaaS-diensten die allemaal beloofden de "single source of truth" te zijn en dat geen van alle ooit waren. De eerlijke waarheid is dat geen van die tools daadwerkelijk met me meedacht — ze sloegen alleen op wat ik al had bedacht.

Dat veranderde drie maanden geleden toen ik mijn hele workflow herbouwde in één enkele tool: Claude Code. Niet als codeerassistent. Als besturingssysteem. Een echt besturingssysteem — met skills, routines, geplande cloud-agents, een markdown kenniswiki en live dashboards die on-demand data ophalen uit ClickUp, Stripe, QuickBooks, Fireflies en Slack.

Dit is de volledige blauwdruk. De frameworks die ik gebruikte (de Three M's en de Four C's), de zeven databuckets waarmee ik begon, de exacte repostructuur, de skills die ik als eerste lanceerde, en het auditscoringssysteem dat ik elke zondagochtend op mezelf toepas om te zien of het AI-besturingssysteem dat Claude Code zou moeten zijn zich ook echt zo gedraagt.

Als je ChatGPT plus Zapier plus zeven dashboards aan het lijmen bent geweest en je je afvraagt waarom je je nog steeds druk voelt — dit is wat ik in plaats daarvan zou bouwen, met wat ik nu weet.

Waarom Productiviteitsstacks Me in 2026 Teleurstelden

Dit is wat niemand me vertelde toen ik mijn vierde Notion-template kocht. Het knelpunt in 2026 is niet informatieopslag. Het is informatie-ophaling op het moment van beslissing. Wanneer een klant om 16:47 mailt met de vraag waarom deliverable drie twee dagen te laat is, hoef ik niet mijn "second brain" te openen. Ik heb een antwoord nodig in negen seconden.

Traditionele productiviteitstools delen allemaal dezelfde fatale fout — ze gaan ervan uit dat ik de motor ben. De tool slaat op. Ik denk. Ik kruisrefereer. Ik synthetiseer. Ik schrijf de e-mail. De Notion-pagina stelt het antwoord niet op. De ClickUp-taak rekent niet af tegen de Stripe-factuur. Het Fireflies-transcript haalt niet de ene beslissing naar boven uit een gesprek van 47 minuten die deze week echt belangrijk is.

Toen de eerste bruikbare agent-runtimes verschenen — Anthropic bracht de Claude Agent SDK eind 2025 uit, opende vervolgens skills als eersteklas primitief, en bracht daarna cloud-gehoste routines uit op 14 april 2026 — stortten de kosten van het bouwen van je eigen systeem in. Wat vroeger een stack van $40K aan Zapier-plus-Make-plus-drie-engineers kostte, past nu in een enkele repo van markdown-bestanden.

Dus verwijderde ik de helft van mijn SaaS-stack en begon opnieuw. Het resultaat is wat ik een AIOS noem: een AI-besturingssysteem dat naast me meedenkt, niet achter me.

Wat een AIOS Werkelijk Is (En Niet Is)

Een besturingssysteem heeft drie taken. Beheer middelen. Bemiddel tussen jou en je hardware. Voer programma's uit namens jou wanneer je dat vraagt.

Een AI-besturingssysteem doet hetzelfde — maar de middelen die het beheert zijn cognitief. Je contexten. Je beslissingen. Je relaties. Je projecten. De hardware waartussen het bemiddelt is je brein plus de tientallen SaaS-API's waarop je bedrijf draait. De programma's die het uitvoert zijn skills, routines en geplande taken die draaien of je nu aan je bureau zit of slaapt.

Dat is het deel dat mensen missen. Een AIOS is geen chatbot met geheugen. Het is geen Notion-vervanging. Het is een runtime die je context vasthoudt, je verbindingen beheert, je mogelijkheden als benoemde skills beschikbaar stelt, en ze uitvoert op een cadans die jij instelt.

Vier eigenschappen scheiden een echt AIOS van een fancy prompt-template:

1. Het houdt je context vast over sessies heen. Niet opnieuw uitleggen wie je bent.
2. Het verbindt met live data. Het haalt uit je echte tools, niet uit verouderde exports.
3. Het stelt mogelijkheden beschikbaar als benoemde, herbruikbare skills. Geen eenmalige prompts.
4. Het voert uit op eigen cadans. Sommige skills trigger je; sommige draaien zelfstandig om 6 uur 's ochtends.

Als een systeem dat je bouwt niet alle vier doet, heb je een chatbot. Nuttig — maar geen OS.

Het goede nieuws: Claude Code geeft je de runtime al gratis. Het werk zit in de architectuur die je erbinnen bouwt. Wat me brengt bij de twee frameworks die alles voor mij organiseerden.

De Three M's: Mindset, Method, Machine

Vóór elke code, elke mapstructuur, elke skill — drie lagen. Sla ze over en de bouw stort in week twee in. Ik heb dit op de harde manier geleerd nadat mijn eerste poging veranderde in 31 ongeorganiseerde markdown-bestanden waar zelfs Claude niet doorheen kon navigeren.

Mindset

De mindsetverandering is klein maar draagkrachtig: de AI is geen automaat. Het is een mentor.

Een automaat neemt een munt en geeft een snack. Je vraagt, je krijgt. Een mentor neemt de vraag, stelt er drie terug, laat je je redenering verdedigen, en vertelt je soms dat de vraag zelf verkeerd is. Dat is de relatie die je wilt met je AIOS. Je wilt geen systeem dat altijd ja zegt. Je wilt er een dat zegt "voordat we dit voorstel opstellen, weet je zeker dat prijstier B past bij het stadium van deze klant? Hun laatste factuur was €2.400."

Dit klinkt filosofisch. Het is diep praktisch. Elke skill die je schrijft defaultt naar "voer het verzoek uit" of naar "ondervraag het verzoek eerst." Een mentorsysteem is gebouwd op de tweede modus.

Method

Method is het draaiboek voor hoe jij en de AIOS samenwerken. Die van mij heeft vier regels:

• Plan vóór uitvoering. Elke niet-triviale skill retourneert eerst een plan. Ik keur het plan goed, dan voert het uit.
• Citeer de bron. Elke claim die het maakt is gekoppeld aan een bestand, een transcript of een API-response. Geen vibes.
• Werk de wiki bij. Elke zinvolle beslissing wordt een markdown-bestand dat toekomstige sessies kunnen lezen.
• Audit op cadans. Wekelijkse Four C's score (meer daarover hieronder). Het getal liegt niet.

Deze regels staan in de root CLAUDE.md van mijn AIOS-repo. Elke Claude Code-sessie leest ze automatisch.

Machine

De machine is de daadwerkelijke stack — de IDE, de repo, de skills, de connectors, het cron-schema. We bouwen de machine zo meteen. Het punt van de Three M's is dat Mindset en Method eerst komen. Als je meteen naar Machine gaat, bouw je een snellere automaat. Wat precies is wat ik de eerste keer deed.

De Four C's: De Echte Architectuur

Waar de Three M's gaan over hoe je denkt, gaan de Four C's over wat je bouwt. Context. Connections. Capabilities. Cadence. In die exacte volgorde. Ze hebben een sequentiële afhankelijkheid — je kunt niet vooruit springen.

Context (de basis)

Context is alles wat het systeem over jou weet. Je bedrijf, je klanten, je doelen, je toon, je beslissingen, je beperkingen. Zonder context behandelt de AIOS elke prompt als een eerste date.

Context leeft in markdown. Altijd markdown. Karpathy had gelijk toen hij zei dat het LLM-vriendelijke formaat platte tekst in een map is die je beheert — er is een 70x token-efficiëntiewinst ten opzichte van RAG en vectordatabases voor persoonlijke kennisschaal, en het is makkelijker te debuggen omdat je de bestanden zelf kunt lezen.

Connections

Zodra het systeem weet wie je bent, moet het de wereld bereiken. Connections zijn je API's en integraties — ClickUp, Google Workspace, Fireflies, Slack, Stripe, QuickBooks. Zonder connections is de AIOS een slim notitieboek. Met connections kan het je live agenda lezen, gisteren's omzet ophalen, vanmorgens transcripten scannen en handelen.

Capabilities

Capabilities zijn skills — benoemde, herbruikbare competenties die het systeem kan uitvoeren. "Stel een dagplan op." "Audit mijn Four C's score." "Genereer de contentkalender van volgende week uit mijn YouTube-reacties." Elk is een map met een SKILL.md-bestand. Anthropic's progressive disclosure patroon betekent dat honderden skills in je repo kunnen zitten en alleen de relevante in de context wordt geladen voor een gegeven taak.

Cadence

Cadence is wanneer dingen draaien. Sommige skills trigger je ("/daily-plan"). Sommige draaien op een cron ("elke maandag 6:00 uur, audit vorige week"). Sommige leven in de cloud en reageren op GitHub-events. Cadence is wat een slimme assistent verandert in een besturingssysteem dat werkt terwijl je slaapt.

De sequentiële afhankelijkheid is wat de meeste mensen verkeerd doen. Je kunt geen nuttige Cadence doen zonder Capabilities. Je kunt geen nuttige Capabilities bouwen zonder Connections. Je kunt Connections niet intelligent gebruiken zonder Context. Dus bouwen we ze in volgorde. Eén tegelijk. Niet overslaan.

Dit is ook waar de audit binnenkomt — maar ik bewaar het scorerubriek voor het einde, nadat we het ding daadwerkelijk hebben gebouwd.

Stap 1: De Plandata — Zeven Tier-Eén Buckets

Vóór elke map, elke code, elke skill — zat ik neer en maakte een lijst van elk type informatie dat mijn werk raakt. Vervolgens vouwde ik het meedogenloos samen tot zeven buckets. Zeven, want dat is ruwweg de limiet voordat het systeem als een doolhof begint te voelen. Die van jou kunnen er zes of acht zijn. De oefening doet er meer toe dan het nummer.

Mijn zeven tier-eén buckets:

1. Revenue — Stripe-betalingen, QuickBooks-grootboek, MRR, debiteuren-veroudering
2. Customer — klantenlijst, status, laatst contact, levenslange waarde, huidige deliverables
3. Calendar — Google Calendar-feed, deze week, volgende twee weken, terugkerende blokken
4. Communication — Gmail-threads, Slack-DM's, commentaarnotificaties die het volgen waard zijn
5. Tasks — ClickUp-lijsten per project, vandaag lijst, deze week lijst, geblokkeerde items
6. Meetings — Fireflies-transcripten, geëxtraheerde beslissingen, geëxtraheerde actiepunten
7. Knowledge — de wiki zelf: klanten, producten, beslissingen, referenties, lessen

Elke skill die ik schrijf raakt minstens een van deze buckets. Vaak drie of vier. De bucketlijst werd het contract: als een vraag niet beantwoord kan worden uit een van deze zeven, mag mijn AIOS het niet verzinnen. Het vertelt me of welke bucket ik moet invullen, of het vraagt. Geen hallucinatie want de datavorm is eindig en benoemd.

Dit klinkt saai. Het is de allerbelangrijkste stap. Als je het overslaat, bouw je skills die uit willekeurige plaatsen trekken en je context wordt brij. De buckets dwingen discipline af.

Stap 2: VS Code, Claude Code en de Repostructuur

De machine zelf is beschamend simpel. VS Code als editor. Claude Code (npm install -g @anthropic-ai/claude-code) als runtime. Een enkele Git-repository als het volledige OS.

Hier is de exacte mapstructuur die ik gebruik:

aios/
├── CLAUDE.md                    # root systeemprompt: mindset + method
├── .env                          # API-sleutels (gitignored)
├── .gitignore
├── .cloud/                       # cloud-routineconfiguraties (gesynchroniseerd naar Anthropic cloud)
│   └── routines/
├── context/                      # de zeven buckets, als markdown
│   ├── revenue.md
│   ├── customers.md
│   ├── calendar.md
│   ├── communication.md
│   ├── tasks.md
│   ├── meetings.md
│   └── knowledge/                # de LLM-wiki leeft hier
│       ├── clients/
│       ├── products/
│       ├── people/
│       └── _index.md
├── decisions/                    # één .md per grote beslissing, gedateerd
│   └── 2026-04-19-pricing-tier-update.md
├── references/                   # statische referentie: SOP's, merkgidsen, prompts
│   └── brand-voice-mejba-me.md
├── archives/                     # dingen ouder dan ~90 dagen
└── .claude/
    ├── skills/                   # persoonlijke skills (lokaal)
    │   ├── onboard/
    │   ├── daily-plan/
    │   ├── four-cs-audit/
    │   ├── linkedin-post/
    │   └── youtube-comment-analysis/
    └── agents/                   # subagents

Vijf regels beheersen deze indeling, en ik heb ze allemaal minstens één keer overtreden en er spijt van gehad:

• Root CLAUDE.md is kort. Onder 200 regels. Het wordt bij elke sessie geladen — maak het te groot en je bloedt tokens.
• context/ bestanden zijn de buckets. Eén bestand per bucket, maximaal 800 regels elk, dan splitsen.
• decisions/ is alleen-toevoegen. Bewerk nooit een beslissingsbestand. Nieuwe beslissing, nieuw bestand, gedateerd.
• archives/ bestaat met een reden. Alles ouder dan ~90 dagen dat niet actief wordt gerefereerd gaat daarheen. Het systeem hoeft je gedachten van januari niet elke mei opnieuw te lezen.
• .cloud/ synchroniseert naar Anthropic. Zet daar alleen cloud-routines en de skills die je in cloud-sessies wilt kunnen uitvoeren. Lokale skills blijven in .claude/skills/.

Het .cloud/-onderscheid is belangrijk. Anthropic's cloud routines (research preview geopend op 14 april 2026) hebben alleen toegang tot projectniveau skills die gecommit zijn in de repo. Persoonlijke skills in ~/.claude/skills/ reizen niet mee. Als je wilt dat een routine een skill uitvoert op Anthropic's infrastructuur 's nachts, moet die skill ingecheckt zijn in de repo.

Als je nog nooit een Claude Code-repo hebt opgezet, loopt mijn agent teams setup-gids de basis gedetailleerder door. Vanaf hier ga ik ervan uit dat je claude werkend hebt in een verse map.

Stap 3: De Onboarding-Skill — Het Systeem Leren Wie Je Bent

De eerste skill die ik bouwde doet niets indrukwekkends. Hij interviewt me. Dat is het.

Ik noemde het onboard. Wanneer ik /onboard uitvoer, loopt Claude door ongeveer 40 vragen over de zeven buckets — wat is mijn bedrijfsmodel, wie zijn mijn top vijf klanten, wat is mijn uurtarief, wat is mijn merkstem, hoe ziet een "goede week" eruit, wat streef ik bewust niet na, wat zijn mijn niet-onderhandelbare punten. Elk antwoord gaat in het bijbehorende contextbestand als gestructureerde markdown.

Waarom interviewgestuurd? Omdat als ik ging zitten om customers.md vanaf nul te schrijven, ik drie weken zou uitstellen. Conversatie is wrijvingsloos. De skill verandert mij die losstaat in gestructureerde context die het systeem voor altijd kan gebruiken.

Hier is de verkorte SKILL.md:

---
name: onboard
description: Interview de gebruiker over de zeven AIOS-buckets en vul de context/ map met gestructureerde markdown. Gebruik wanneer de gebruiker /onboard typt of vraagt om hun AIOS voor het eerst op te zetten.
---

# Onboarding Skill

Je interviewt de gebruiker om de context van hun AI-besturingssysteem te vullen.
Werk door de zeven buckets in volgorde: Revenue, Customer, Calendar,
Communication, Tasks, Meetings, Knowledge.

Voor elke bucket:
1. Stel 4-7 specifieke vragen, één tegelijk.
2. Na elk antwoord, herformuleer wat je hoorde in één zin.
3. Wanneer de bucket klaar is, schrijf het markdown-bestand naar context/[bucket].md.
4. Toon de gebruiker het bestand. Vraag of er iets mis is voordat je doorgaat.

Regels:
- Verzin nooit antwoorden. Als de gebruiker het niet weet, schrijf "TBD" met een datum.
- Citeer de bron van elk feit (bijv. "per gebruiker, 2026-04-15").
- Houd elk contextbestand onder 800 regels. Indien langer, splits.

Uitvoerformaat: gestructureerde markdown met H2-secties per onderwerp, opsommingen met feiten.

Dat is het. ~25 regels inclusief frontmatter. De skill laadt alleen wanneer aangeroepen, kost bij sessiestart vrijwel nul tokens, en produceert de basis waar al het andere van afhankelijk is. Na één keer /onboard te draaien, begint elke toekomstige sessie precies wetend wie ik ben en waar ik aan werk.

Dit is ook het meest ondergewaardeerde voordeel van het skills-primitief: je kunt een skill schrijven waarvan de hele taak is om de context te vullen die toekomstige skills zullen lezen. Het systeem bootstrapt zichzelf.

Stap 4: De Connections-Laag — Koppel Je Echte Tools

Hier stagneren de meeste persoonlijke AIOS-bouwprojecten. Mensen stellen zich voor dat ze een aangepaste MCP-server nodig hebben voor elke tool. Dat is niet zo. In 90% van de gevallen is het juiste antwoord een directe API-aanroep vanuit een skill, met credentials in .env.

Ik zal uitleggen waarom ik API-first koos boven MCP, en vervolgens door de daadwerkelijke integraties lopen.

Waarom API > MCP voor persoonlijke schaal

MCP-servers zijn prachtig voor gedistribueerde agentsystemen waar meerdere clients een gedeeld protocol nodig hebben. Voor een persoonlijk AIOS waar je beide kanten beheert, voegen MCP-servers token-overhead toe — het toolschema van elke server wordt in de context geladen of je het nu gebruikt of niet. Een directe curl- of fetch-aanroep binnen een skill kost niets totdat de skill draait.

Vuistregel waar ik op uitkwam: als een tool door meer dan drie skills wordt gebruikt en ik wil dat het vanuit elke sessie toegankelijk is zonder prompting, schrijf een MCP-wrapper. Anders, ruwe API-aanroep vanuit de relevante skill. Voor een solo AIOS betekent dat dat bijna alles als ruwe API blijft.

De daadwerkelijke integraties die ik bedraadde

De .env-discipline

Elke API-sleutel in .env. .env staat in .gitignore. Geen uitzonderingen. Als je ooit een .env naar GitHub hebt gepusht zoals ik in 2022 deed — dan weet je dat GitHub's geheimscanner je binnen minuten vangt, je sleutel wordt ingetrokken, en je een zaterdag besteedt aan het rouleren van credentials. Wees niet de 2022-versie van mij.

Voor Stripe en QuickBooks gebruik ik beperkte/alleen-lezen sleutels voor alles wat de AIOS autonoom doet. Schrijfbewerkingen vereisen een interactieve sessie waar ik de actie goedkeur. Dit is geen paranoia — het is hetzelfde principe als een junior engineer geen prod-schrijftoegang geven op dag één.

Dedicated AIOS-accounts

Dit is het deel dat me het langst kostte om uit te vinden. Voor Slack, Fireflies en (waar mogelijk) Google Workspace maakte ik een dedicated serviceaccount dat alleen door de AIOS wordt gebruikt. Waarom? Omdat zodra je je AIOS laat posten op Slack als jij, elke Slack-notificatie terugverwijst via je auditlog als acties die jij hebt ondernomen. Dat is een puinhoop voor verantwoording en een ergere puinhoop als je ooit moet debuggen of jij het bericht hebt gestuurd of je AIOS.

Het dedicated account heet "Mejba (AIOS)" en heeft een duidelijk andere avatar. Wanneer het in een kanaal post, weet iedereen dat het de AIOS is. Wanneer ik post, ben ik het. Compliance-teams en toekomst-jij bedanken huidige-jij beiden.

Voor meer diepgang over het beveiligen van agentcredentials en webhooks, behandelt mijn veilige AI-agent onboarding-gids het dreigingsmodel in detail.

Stap 5: Capabilities — De Skills Die Echt Hun Plaats Verdienen

Dit is de sectie die me het langst kostte in de daadwerkelijke bouw, en de sectie waar de meeste mensen me over vragen. Skills zijn waar de AIOS stopt met theoretisch zijn en begint met uren besparen. Ik laat de structuur zien en loop dan door vijf echte skills die ik heb gelanceerd.

SKILL.md anatomie

Volgens Anthropic's officiële skills-documentatie is elke skill een map met minimaal een SKILL.md-bestand dat bevat:

---
name: kebab-case-naam
description: Triggerbeschrijving in één zin. Claude leest dit om te beslissen wanneer de skill te gebruiken.
allowed-tools: Read, Write, Bash, WebSearch  # optioneel
---

# Skill Naam

[Instructies die Claude volgt wanneer deze skill laadt]

## Wanneer gebruiken
## Wat te doen
## Uitvoerformaat
## Beperkingen

Houd SKILL.md onder 500 regels per Anthropic's aanbeveling. Meer nodig? Voeg REFERENCE.md, EXAMPLES.md of uitvoerbare scripts toe in dezelfde map. Claude laadt de extra bestanden alleen wanneer het ze daadwerkelijk nodig heeft — dat is het progressive disclosure patroon en het is de reden dat je honderden skills kunt draaien zonder tokens te verbranden.

Skill 1: /daily-plan

De skill die als eerste zijn waarde bewees. Elke ochtend om 6:30 (cron-getriggerd) produceert hij een eenpagina dagplan dat:

• context/calendar.md leest en de live Google Calendar-feed voor vandaag
• context/tasks.md leest en de top 8 ClickUp-taken ophaalt gewogen op deadline + prioriteit
• Gisteren's Fireflies-transcripten scant op vastgelegde actiepunten
• Kruisverwijst met decisions/ op alles waar ik zei dat ik deze week op terug zou komen
• Een 3-blokkenplan opstelt: deep work-blok, communicatieblok, admin-blok
• Het output naar daily/2026-04-19.md en me om 7:00 een samenvatting stuurt via Slack

Tijdsbesparing per dag: ~20 minuten "waar moet ik eerst mee beginnen" overhead, met meetbaar betere prioriteitskeuzes omdat het systeem daadwerkelijk weet wat ik heb toegezegd in de klantgesprek van afgelopen dinsdag.

Skill 2: /linkedin-post

Ik schrijf bijna dagelijks een LinkedIn-post. De eerste versie van deze skill produceerde generieke brij. De huidige versie leest:

• context/knowledge/brand-voice-mejba-me.md (mijn stemregels)
• De laatste 30 dagen aan LinkedIn-posts die ik daadwerkelijk heb gepubliceerd (opgehaald via export)
• Het daily/[datum].md plan van vandaag, plus het meest recente beslissingsbestand
• Optionele URL die de gebruiker doorgeeft

Het retourneert drie concepten in drie verschillende invalshoeken — tegendraads, verhaal, tactisch — en tagt op welk eerder bericht elk concept het meest lijkt qua stijl. Ik kies er een, bewerk, publiceer. ~12 minuten voor een af bericht versus de 35 die het eerder kostte.

Skill 3: /youtube-comment-analysis

Ik krijg een paar honderd YouTube-reacties per week over video's. De meeste zijn ruis. Sommige zijn goud voor contentideeën. Deze skill haalt de reacties van de afgelopen 7 dagen op via de YouTube Data API, clustert ze in thema's, brengt de drie threads met de meeste engagement naar boven, en stelt contenthoeken voor voor elk. Draait zondagavond. Het video-idee van dinsdag wordt meestal uit deze output gekozen.

Skill 4: /slide-deck

Voor klantvoorstellen. Leest het klantenbestand in context/knowledge/clients/[slug].md, de dealscope uit context/customers.md en een slidetemplate in references/. Output een gestructureerde outline als markdown, genereert vervolgens Marp-slides. Bracht een 90-minuten deckworkflow terug naar 25.

Skill 5: /four-cs-audit

Dit is de skill die de AIOS zelf auditeert. We graven er zo meteen in want het is degene die het hele systeem in een feedbackloop verandert. Voorlopig: het scoort Context, Connections, Capabilities en Cadence elk op 25 punten en schrijft het resultaat naar audits/[datum].md.

Skill 6: /level-up

Tweelingbroer van de audit. Leest het laatste auditbestand, identificeert de laagst scorende dimensie, en stelt de drie acties met de hoogste hefboomwerking voor om die score te verbeteren vóór de audit van volgende week. Zo vertelt het systeem me wat ik als volgende moet bouwen.

Ik heb nu ~22 skills in totaal. De lijst groeit met 1-3 per week. Sommige sterven snel omdat ze hun waarde niet bewijzen. Dat is prima. Een skill is een markdown-bestand van 30 regels — de kosten om er een te schrijven zijn zo laag dat "verwijderen en herschrijven" wint van "zorgvuldig plannen."

Stap 6: Cadence — Routines, Cron en de Cloud

Skills kun je triggeren. Routines draaien zichzelf. Dit is wat een AIOS van behulpzaam naar autonoom promoveert.

Lokaal vs cloud routines

Twee smaken van geplande uitvoering bestaan sinds mei 2026:

• Lokale geplande taken — je laptop draait ze via cron of een launchd-job die claude headless aanroept. Werken prima als je laptop aan staat. Niet als hij dat niet is.
• Cloud routines — gehost door Anthropic, research preview geopend 14 april 2026. Draaien op Anthropic's infrastructuur, blijven werken wanneer je laptop dicht is, geconfigureerd op claude.ai/code/routines of via /schedule.

Volgens Anthropic's eigen routines-documentatie is elke routine een opgeslagen Claude Code-configuratie — een prompt, een of meer repo's en een set connectors. Triggers kunnen gepland zijn (cron of natuurlijke taal zoals "elke maandag 6 uur"), API (HTTP POST met bearer token), of GitHub-events (PR's, releases). Planlimieten per de preview: Pro 5/dag, Max 15/dag, Team en Enterprise 25/dag.

Mijn huidige cadans

De 3-dagenlimiet voor loops verdient een opmerking. Langlopende taken die eindeloos loopen verbranden tokenbudget sneller dan je verwacht. Ik beperk elke loop-skill tot maximaal 3 dagen, met een harde exit-conditie. Voor echt langetermijnwerk, plan een verse routine — laat niet één sessie een week draaien.

Planning in natuurlijke taal

Het /schedule-commando accepteert natuurlijke taal. "Draai /four-cs-audit elke zondag om 7 uur en DM me het resultaat op Slack." Dat mapt achter de schermen naar een cron-expressie. Je hoeft de cron-syntax niet meer te onthouden. (Hoewel het kennen van 0 7 * * 0 geen kwaad kan.)

Monitoring en debugging

Elke routine schrijft een run-log naar .cloud/runs/[datum]/[routine-naam].md (of het cloud-equivalent zichtbaar in claude.ai/code/routines). Ik bekijk mislukte runs één keer per week. De meest voorkomende faalwijze is veruit API-ratelimits — Stripe is de grootste boosdoener. De fix is bijna altijd "voeg een 200ms vertraging toe tussen aanroepen" of "batch het verzoek."

Als een routine drie keer achter elkaar faalt, krijg ik een ping in Slack. Stille falen is erger dan luid falen.

Voor meer over het automatiseren van terugkerend werk specifiek met Claude Code's planningslaag, toont mijn walkthrough over SEO-checks via routines hetzelfde patroon toegepast op een enkel domein.

De LLM Kenniswiki — Mijn Second Brain in Karpathy-Stijl

Dit is het deel van mijn AIOS dat me het meest verraste. Ik verwachtte dat de skills en routines de winst zouden zijn. Wat daadwerkelijk veranderde hoe ik denk is de wiki.

Eind 2025 publiceerde Andrej Karpathy de LLM Wiki-gist — een patroon waarbij je in plaats van notities in een vectordatabase te proppen, platte markdown-bestanden in een map onderhoudt en de LLM ze direct laat lezen. VentureBeat schreef over de aanpak kort daarna. De gebenchmarkte claim, herhaald over implementaties, is ruwweg 70x meer token-efficiënt dan RAG voor persoonlijke schaal kennisbanken die in het contextvenster van een model passen.

Ik host mijn wiki onder context/knowledge/ en bekijk het via Obsidian voor de grafweergave. Claude Code leest dezelfde bestanden direct via het bestandssysteem.

Wat er in de wiki gaat

• Klanten — één bestand per klant, met alle relevante feiten, geschiedenis, beslissingen, communicatienormen
• Producten — elk product/dienst die ik verkoop, met positionering, prijstiers, veelvoorkomende bezwaren
• Mensen — verwijzingen, leveranciers, samenwerkingspartners, met relatiecontext
• Lessen — dingen die ik op de harde manier heb geleerd, geschreven zodat toekomst-ik de fout niet herhaalt
• Beslissingen — elke niet-triviale beslissing, gedateerd, met bewaard redeneerproces

Waarom markdown beter is dan een vector-DB op deze schaal

Drie redenen die ertoe doen in dagelijks gebruik:

1. Je kunt het lezen. Wanneer iets er verkeerd uitziet, cat je het bestand. Met een vector-DB bevraag je embeddings.
2. De LLM kan het schoon herschrijven. Karpathy's hele inzicht was dat LLM's nu goed genoeg zijn om een wiki te onderhouden, niet alleen te bevragen. Die van mij reorganiseert wekelijks zijn eigen bestanden.
3. Het laadt exacte tekst in de context. Geen embedding-gelijkenishandwaving. Het model ziet het bestand en redeneert erover.

Voor diepere dekking van dit specifieke patroon, zie Obsidian + Claude Code als persistent geheugen en de super-skills aanpak die Karpathy's wiki combineert met Claude Code's skill-primitieven.

De wiki kostte me ongeveer drie weekenden om te vullen. Het is nu het meest gerefereerde deel van mijn AIOS en het deel dat ik als laatste zou opgeven.

Artefacten en Dashboards — Real-Time Pulls

Soms wil ik geen chat. Ik wil een dashboard. Skills kunnen Claude-artefacten retourneren — interactieve HTML/JS-panelen die renderen in de chatweergave en on-demand vernieuwen door de onderliggende API-aanroepen opnieuw uit te voeren.

Mijn vijf meest gebruikte dashboards:

• MRR Pulse — Stripe-omzet afgelopen 30/60/90 dagen, churnpercentage, topbijdragende klanten
• AR Aging — openstaande facturen gegroepeerd op 0-30 / 31-60 / 60+ dagen
• Client Health — per actieve klant: dagen sinds laatste contact, huidige deliverablestatus, openstaande ClickUp-blockers
• Calendar Density — volgende 14 dagen, % tijd in vergaderingen vs deep work, kleurgecodeerd
• Decision Backlog — elke "TBD" of "revisit by X" tag uit decisions/ die over de deadline is

Elk is een skill die live data ophaalt en een artefact rendert. Geen SaaS-dashboardtool. Geen externe dienst. Data leeft waar het leeft; het dashboard wordt on-demand gegenereerd. De totale kosten worden gemeten in API-aanroepen, niet in abonnementskosten.

De Dagelijkse en Wekelijkse Loop

Hier is het ritme dat ontstond na ongeveer zes weken. Ik laat het zien want de loop is het systeem. Zonder loop heb je een fancy map met markdown.

Dagelijks

Wekelijks

Het systeem draait of ik betrokken ben of niet. De audits dwingen me om zondagochtend betrokken te zijn. Dat is de hele loop.

De Four C's Audit Scoring — Hoe Ik Weet Dat Het Echt Werkt

Elke zondag om 7 uur draait de /four-cs-audit skill en geeft me een getal op 100. Vijfentwintig punten elk voor Context, Connections, Capabilities, Cadence. Het getal is meedogenloos want dat moet het zijn.

Scorerubriek (vereenvoudigd)

Context (op 25)

• Alle 7 buckets gevuld en bijgewerkt binnen 14 dagen: 15 ptn
• Wiki heeft ≥1 bestand per actieve klant/product: 5 ptn
• Geen "TBD" tags ouder dan 30 dagen: 5 ptn

Connections (op 25)

• Elke integratie getest in de afgelopen 14 dagen: 4 ptn elk (max 20)
• Alle credentials in .env, geen in skills: 5 ptn

Capabilities (op 25)

• ≥10 werkende skills: 5 ptn
• Elke top-5-meest-gebruikte skill draaide succesvol ≥3 keer deze week: 15 ptn
• ≥1 nieuwe skill gelanceerd in de afgelopen 14 dagen: 5 ptn

Cadence (op 25)

• ≥1 dagelijkse routine draaiend: 5 ptn
• ≥1 wekelijkse routine draaiend: 5 ptn
• Audit + level-up draaien automatisch: 10 ptn
• Nul stille fouten (elke fout heeft je gepingd): 5 ptn

Mijn eerste audit (echte cijfers)

Toen ik mijn AIOS de eerste keer scoorde — zes weken na de bouw — landde het op 54,5/100:

• Context: 18/25 — buckets waren gevuld maar de wiki had drie "TBD" klantenbestanden ouder dan een maand
• Connections: 16/25 — Stripe en ClickUp waren solide, QuickBooks OAuth faalde al 9 dagen en ik had het niet gemerkt
• Capabilities: 15,5/25 — 12 skills gebouwd, maar 4 daarvan had ik sinds week één nooit daadwerkelijk gebruikt
• Cadence: 5/25 — Ik had cron-jobs maar nog geen echte cloud-routines, en het stille QuickBooks-falen bewees dat mijn monitoring kapot was

54,5 op 100. Na zes weken werk. Dat getal was het nuttigste stuk feedback dat het systeem me ooit heeft gegeven. Het vertelde me precies waar ik week zeven op moest focussen (fix monitoring, stel cloud-routines in, verwijder de vier dode skills).

Tegen week tien zat ik op 81. De audit is de feedbackloop die het hele ding in de loop der tijd verbetert. Zonder zou ik skills zijn blijven bouwen die niemand — inclusief ik — daadwerkelijk gebruikte.

Mijn Visie — De Lessen Waar Ik Drie Maanden Over Deed

Zes weken erin wilde ik bijna stoppen. Productiviteit werd slechter voordat het beter werd. Ik besteedde 12 uur per week aan de AIOS zelf in plaats van aan klantwerk, en de vroege skills verdienden zichzelf nog niet terug. Dit is de productiviteitsdip en die is echt. Plan ervoor.

De vorm is ruwweg:

• Weken 1-3: Netto negatief. Je bouwt, debugt, vult context, leert de eigenaardigheden van Claude Code.
• Weken 4-7: Break-even. De eerste paar skills beginnen echte tijd te besparen. Het systeem weet genoeg over je om nuttig te zijn.
• Weken 8+: Samengestelde winst. Elke nieuwe skill kost minder tijd om te bouwen omdat je context hergebruikt. Elke routine voegt marge toe aan je week.

Tegen week tien won ik ~14 uur per week aan administratieve overhead terug. Tegen week twaalf, ~19. De dip is de toegangsprijs. Betaal hem bewust, niet per ongeluk.

Drie andere lessen die ik op mijn onderarm zou laten tatoeëren als ik kon:

1. Mik op 30-75% automatisering per taak, niet 100%. Proberen creatief werk volledig te automatiseren levert vlakke output. Proberen besluitvorming volledig te automatiseren levert brosse systemen. De sweet spot is het automatiseren van de afbeulerij-delen van een taak — onderzoek, opstellen, formatteren, statussynchronisatie — en de beoordelingsdelen menselijk houden. Een 50%-geautomatiseerde workflow die consistent draait verslaat een 100%-geautomatiseerde workflow die elke derde week kapot gaat.

2. Behandel de AIOS als een mentor, niet als een automaat. Al gezegd. Zeg het nogmaals. De skills die me het meest leerden waren degenen die terugduwden. /daily-plan is geweldig omdat het soms weigert in te plannen wat ik vroeg en uitlegt waarom ("je hebt je in het gesprek van dinsdag gecommitteerd aan deep work op de Acme-deliverable — het verplaatsen van de vergadering naar dat blok is in tegenspraak met die toezegging"). Een automaat zou gewoon de vergadering hebben verplaatst.

3. De audit verslaat de bouw. Ik schaam me oprecht voor hoeveel ik bouwde voordat ik de auditskill bouwde. De audit is wat de AIOS van een slimme toolkit veranderde in een systeem dat zichzelf verbetert. Als je maar één skill bouwt uit dit hele bericht, bouw de audit.

Er is ook een meta-les die het waard is hardop te zeggen — dit bouwen maakte me niet van de ene op de andere dag productiever. Het maakte me eerlijker. De zondagscore liegt niet. Je kunt jezelf niet wijsmaken dat je een geweldige week had wanneer de audit zegt dat Cadence 5/25 is en drie van je routines stil hebben gefaald.

Dat, meer dan de bespaarde tijd, is waarom ik nooit meer terug zou gaan.

Veelgestelde Vragen

Waar staat AIOS voor?

AIOS staat voor AI Operating System — een persoonlijke runtime gebouwd bovenop Claude Code die je context vasthoudt, verbindt met je live tools, mogelijkheden als benoemde skills beschikbaar stelt, en uitvoert op een cadans die jij instelt. Anders dan een chatbot beheert het cognitieve middelen over sessies heen en kan het autonoom uitvoeren.

Moet ik een ontwikkelaar zijn om een AIOS in Claude Code te bouwen?

Je hebt basiscomfort nodig met de terminal, Git en het bewerken van markdown-bestanden. Je hoeft geen productiecode te schrijven — elke skill is een markdown-bestand met een YAML-header. Als je een WordPress-site hebt gelanceerd of VS Code hebt gebruikt, heb je genoeg achtergrond.

Hoe verschilt dit van Notion AI of ChatGPT met geheugen?

Drie dingen: Claude Code leest je echte bestandssysteem (geen uploadstap), skills draaien als code met API-toegang (niet alleen tekstgeneratie), en routines voeren uit op een schema of je nu aan je laptop zit of niet. ChatGPT-geheugen is een van de vier pijlers (Context). Een AIOS is alle vier.

Hoeveel kost het draaien van een persoonlijk AIOS?

Claude Pro op $20/maand dekt het meeste persoonlijke gebruik inclusief 5 cloud-routines per dag; Max-plannen breiden uit naar 15 routines/dag. API-kosten voor verbonden tools (Stripe, ClickUp, etc.) zijn typisch gratis bij persoonlijk volume. Totale maandelijkse kosten voor mij liggen rond ~$45-80 afhankelijk van routinebelasting.

Hoe lang duurt het om er een te bouwen?

Plan op 30-50 uur over 4-8 weken deeltijds werk om een bruikbare basis te bereiken. Verwacht een productiviteitsdip in weken 1-3, break-even rond week 5-7, en samengestelde winst na week 8. Het volledige stap-voor-stap staat in de bouwsecties hierboven.

Kan ik cloud-routines draaien op een Gratis plan?

Nee — cloud-routines vereisen Pro, Max, Team of Enterprise vanaf mei 2026. Het Gratis plan kan nog steeds lokale skills draaien en cron-gestuurde planning op je eigen machine gebruiken.

Laten We Samenwerken

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

• 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