OKF Second Brain: Ik Heb Mijn Claude-Setup Omgebouwd en Het Stopte Eindelijk Met Vergeten
Het moment dat ik mijn oude second brain opgaf kwam op een dinsdag, toen ik Claude een bestand genaamd pricing-v2-FINAL.md zag aanmaken zes mappen diep — direct naast de pricing.md die het drie weken eerder had geschreven en blijkbaar vergeten was dat die bestond.
Twee bestanden. Dezelfde kennis. Elkaar tegensprekend. Allebei zelfverzekerd "correct."
Dat is de verrotting die intreedt in elke persoonlijke kennisbank die gebouwd is zoals de mijne: een wildgroei van markdown-notities bij elkaar gehouden door een heroïsch Claude.md-bestand dat het werk deed van een index, een bibliothecaris en een geheugen tegelijk. Het werkt prachtig bij dertig bestanden. Het valt stilletjes uit elkaar bij driehonderd. Mijn agent was niet dom — hij had gewoon geen betrouwbare manier om te weten wat er al bestond voordat hij iets nieuws schreef. Dus leidde hij opnieuw af, vatte opnieuw samen en dupliceerde, sessie na sessie.
Dit is exact het probleem waarvoor Google's Open Knowledge Format gebouwd is, en in één weekend in juni 2026 heb ik mijn hele setup herbouwd als een OKF second brain om uit te vinden of het format het echt oplost of alleen de rommel hernoemt. Ik ga je door de echte conversie leiden — de mapchirurgie, de conversie-skill waarop ik leunde, de ene regel die ik toevoegde aan Claude.md die alles veranderde, wat er brak, en de eerlijke voor-en-na. Als je een markdown-kennisbank hebt die Claude behandelt als een rommella, is dit de weg eruit.
Ik neem aan dat je al ruwweg weet wat OKF is. Zo niet, lees dan eerst mijn eerste blik als bouwer op het Open Knowledge Format — dat behandelt de specificatie vanaf nul. Dit stuk is het deel dat daarna komt: Ik heb al een second brain. Wat nu?
Waarom Mijn Claude Second Brain Tegen een Muur Liep
Laat me de setup beschrijven, want die van jou lijkt er waarschijnlijk op.
Ik had ongeveer een jaar een persoonlijke kennisbank gedraaid — het soort dat ik documenteerde in mijn Claude Code second brain build. Markdown-bestanden, geneste mappen per project en onderwerp, en een dikke Claude.md aan de root die Claude vertelde waar dingen leefden en hoe het zich moest gedragen. Klanthandboeken. Prijslogica. Codefragmenten. Vergadernotities. Duur verworven heuristieken die ik nooit opnieuw wilde leren.
Het systeem had vier faalwijzen, en ze werden erger naarmate het groeide.
Claude kon niet zien of iets al bestond. Zonder een machineleesbare kaart was de enige manier voor de agent om te controleren "heb ik al een notitie over restitutiebeleid?" om bestandsnamen te greppen en mappen te scannen. Dat is traag, token-hongerig en onbetrouwbaar. Dus controleerde het vaak niet — en schreef een duplicaat. Dat pricing-v2-FINAL.md-moment was geen eenmalige gebeurtenis.
Zoeken was een belasting. Elke opvraging betekende dat de agent zich door geneste mappen waaierde, bestanden opende om te zien of ze relevant waren, en context verbrandde op doodlopende wegen. Hoe dieper de mappenboom, hoe zwaarder de belasting.
Niets was overdraagbaar. Mijn second brain was op maat gemaakt voor mijn workflow en mijn Claude.md. Ik kon het niet aan een teamgenoot geven, in een andere agent laden, of een stukje ervan delen zonder dat het geheel zijn betekenis verloor. Het was een privédialect, geen taal.
De Claude.md was op een gevaarlijke manier dragend. Alle structuur leefde in de proza van één bestand. Als dat bestand uit sync raakte met de werkelijke mappen — en dat deed het altijd — navigeerde de agent op een verouderde kaart.
Geen van deze zijn exotische problemen. Het is waar elke ongestandaardiseerde second brain tegenaan loopt voorbij een bepaalde omvang. De structuur die in het begin als vrijheid voelde, werd het ding dat het wurgde. Ik had geprobeerd het te repareren met betere mapdiscipline en een langere Claude.md. Dat is een structureel probleem behandelen met wilskracht. Dat houdt niet stand.
Wat ik eigenlijk nodig had was een standaardvorm — een die de agent kon vertrouwen zonder dat ik elke navigatie begeleidde. Dat is de weddenschap die OKF maakt. Tijd om het te testen.
Hoe een OKF Second Brain er Werkelijk Uitziet
Hier is het herkaderen dat het format voor mij deed klikken: OKF vraagt je niet om tooling toe te voegen. Het vraagt je om het eens te worden over een vorm. En de vorm is bijna beledigend eenvoudig — markdown-conceptbestanden met YAML front matter, gegroepeerd in een bundel, voorafgegaan door een index.md die als kaart dient.
Mijn oude second brain organiseerde op project. Mijn OKF second brain organiseert op concept, met een harde scheiding die Karpathy's LLM Wiki gist me inhamerde: houd ruw bronmateriaal gescheiden van gesynthetiseerde kennis. Ruwe transcripten, gescrapete pagina's en gedumpte notities leven in /raw. De schone, agent-leesbare concepten leven in de wiki zelf. De agent leest /raw, extraheert concepten en schrijft gestructureerde pagina's — hij serveert je nooit de ruwe stapel direct.
De nieuwe structuur ziet er zo uit:
second-brain/
├── index.md # de kaart: elk concept, één regel per stuk
├── log.md # append-only geschiedenis van wijzigingen
├── raw/ # bronmateriaal, onaangeroerd
│ ├── call-2026-06-18.md
│ └── scraped-pricing-research.md
├── clients/
│ ├── index.md # sub-kaart voor deze map
│ ├── onboarding-sequence.md
│ └── escalation-playbook.md
└── business/
├── index.md
├── pricing-logic.md
└── positioning.md
Elk conceptbestand draagt front matter die de agent leest voordat hij de body opent:
---
type: playbook
title: Klant Onboarding Sequentie
description: De exacte stappen die ik doorloop wanneer een nieuwe AI-automatiseringsklant tekent.
tags: [onboarding, proces, klanten]
timestamp: 2026-06-18
---
# Klant Onboarding Sequentie
Wanneer een nieuwe klant tekent, doorloop ik deze stappen in volgorde. Elke stap heeft een
trigger en een definitie van klaar...
Het type-veld is het enige dat OKF v0.1 strikt vereist. Al het andere — title, description, tags, timestamp — is aanbevolen. Maar de description is hier de stille held, en ik laat je zien waarom in de resultaten-sectie. Het is wat een agent laat beslissen of hij een bestand moet openen zonder het te openen.
De index.md is waar een platte map een navigeerbare grafiek wordt:
---
type: index
title: Second Brain — Root Index
---
# Second Brain Index
## clients/
- **onboarding-sequence** — stappen die worden doorlopen wanneer een nieuwe klant tekent
- **escalation-playbook** — hoe om te gaan met een ontevreden klant midden in een project
## business/
- **pricing-logic** — hoe ik AI-automatiseringsopdrachten prijs
- **positioning** — wie ik bedien en wie ik afwijs
Die éénregelige beschrijving per concept is de hele truc. De agent leest de index, ziet dertig beschrijvingen en beslist welke twee bestanden hij echt nodig heeft — en opent dan alleen die. Het is progressieve onthulling, hetzelfde principe dat goed gebouwde Claude-skills efficiënt maakt. De index is de schijnwerper. De concepten zijn waar hij op wijst.
Dit is het structurele verschil tussen een OKF second brain en de stapel die ik eerder had: de kaart is een bestand, geen proza begraven in Claude.md, en het leeft naast het ding dat het beschrijft. Wanneer ik een concept toevoeg, werk ik de lokale index bij. De kaart en het terrein blijven in sync omdat ze buren zijn.
Dat is het doel. Nu de migratie.
Hoe Ik Mijn Second Brain Omzette Naar OKF
Ik nam expres twee doorlopen, omdat ik het format met de hand wilde voelen voordat ik er een tool op losliet. Dit is dezelfde les die ik steeds opnieuw leer: een specificatie lezen leert je bijna niets vergeleken met het slecht converteren van één map.
Doorloop één: de ruggengraat, met de hand. Ik pakte mijn enkele rommeligste map — klantwerk — en herbouwde die handmatig. Ik maakte de index.md aan, en ging toen bestand voor bestand na om het type te bepalen en een éénregelige description voor elk te schrijven. Dit was traag, en de traagheid was het punt. Beslissen of mijn prijsdocument een pricing, een policy of een reference was, dwong me om echt te begrijpen wat elke notitie was. De helft van mijn "dubbele" bestanden bleek hetzelfde concept te zijn, twee keer vanuit verschillende hoeken geschreven. De conversie legde de duplicatie bloot waar ik blind voor was geweest.
Mijn belangrijkste les van doorloop één: schrijf je type-vocabulaire op als een eigen conceptbestand voordat je iets converteert. OKF schrijft bewust je types niet voor, en die vrijheid verandert snel in beslissingsmoeheid en inconsistentie. Ik maakte business/type-vocabulary.md aan met de acht types die ik zou toestaan — playbook, runbook, reference, pricing, case-study, glossary, decision, index — en weigerde er ter plekke een negende bij te verzinnen. Consistente types zijn het verschil tussen een bundel waar een agent goed doorheen navigeert en een waar hij doorheen struikelt.
Doorloop twee: automatisering voor het gros. Driehonderd bestanden met de hand converteren was nooit het plan. Voor de rest leunde ik op de okf-skills Claude Code plugin — een open-source set skills die Claude Code leert om OKF-bundels te schrijven, onderhouden en valideren, aangedreven door de letterlijke specificatie en ondersteund door een conformiteitscontrole. Dat laatste deel is belangrijker dan het klinkt: het betekent dat de output van de agent gecontroleerd wordt tegen de specificatie in plaats van blindelings vertrouwd. Ik keek ook naar Suganthan Mohanadasan's OKF Bundle Generator voor de URL-naar-bundel route, maar voor een lokale markdown-map paste de Claude Code skill-route beter.
Hier is het eerlijke deel: automatisering spijkerde de makkelijke 80% en fumelde met de waardevolle 20%. Pagina-naar-markdown-met-front-matter is een opgelost probleem — de skill voegde type- en description-velden schoon toe aan mijn bestaande notities en markeerde specificatieovertredings. Wat het niet betrouwbaar kon doen was de moeilijke daad: een notitie van 2.000 woorden lezen die stiekem drie afzonderlijke concepten bevatte en deze opsplitsen in drie bestanden. Die decompositie — Suganthan noemt het "semantisch ontbakken" — is het deel dat nog grotendeels bij jou ligt. Een LLM kan het proberen, maar naïef gericht op "splits dit in concepten" produceert het overlappende, tegenstrijdige bestanden. Ik heb elke splitsing met de hand beoordeeld.
De ene regel die alles veranderde. Niets van de structuur doet ertoe als de agent het niet gebruikt. De ontgrendeling was een kleine, expliciete instructie bovenaan Claude.md:
## Knowledge Base Protocol
Dit is een OKF-bundel. Voordat je een vraag beantwoordt of een bestand aanmaakt:
1. Lees EERST `index.md` op het relevante niveau.
2. Gebruik `description`-velden van bestanden om te beslissen wat je opent — open GEEN
bestanden om relevantie te controleren.
3. Controleer voordat je een concept aanmaakt de index op een bestaand concept.
Werk het bij in plaats van te dupliceren.
4. Voeg na elke wijziging een regel toe aan `log.md`.
Dat is het. Vier regels. Het format geeft de agent een betrouwbare kaart; dit vertelt hem om de kaart eerst daadwerkelijk te lezen. Zonder deze instructies behandelde Claude de OKF-bundel als elke andere map en ging terug naar greppen. Met hen veranderde zijn gedrag zichtbaar — wat het hele resultatenverhaal is.
Als je liever hebt dat deze conversie voor je wordt gedaan — het type-vocabulaire ontworpen, de decompositie goed gedaan, het Claude.md-protocol afgestemd — dan is dat precies het soort pipeline dat ik bouw. Je kunt het werk zien op fiverr.com/s/EgxYmWD. Maar oprecht: converteer eerst één map met de hand. Het kost een middag en leert je wat geen tool zal doen.
Wat er Brak Tijdens de Conversie
Een bouwlog zonder de mislukkingen is marketing, geen les. Drie dingen beten me.
De description-velden waren lui, en de agent erfde mijn luiheid. Mijn eerste batch beschrijvingen waren dingen als "notities over prijzen" — nutteloos. Wanneer de hele navigatiestrategie afhangt van de agent die beschrijvingen leest in plaats van bestanden, breekt een vage beschrijving stilletjes het systeem. De agent kan pricing-logic niet onderscheiden van pricing-history als beide "notities over prijzen" zeggen, dus opent hij beide, en je bent terug bij de tokenbelasting waar je van probeerde te ontsnappen. Ik moest elke beschrijving herschrijven om onderscheidend te zijn — wat maakt dit bestand anders dan zijn buren — niet alleen beschrijvend. Dat herschrijven duurde langer dan de structurele conversie.
Overal verouderde links. Wanneer je bestanden splitst en hernoemt, verotten interne verwijzingen. Mijn oude notities verwezen naar elkaar op bestandsnaam, en de helft van die namen veranderde. OKF tolereert gebroken links by design — de specificatie behandelt links als ongetypeerde randen en haalt de schouders op bij dode — wat vergevingsgezind is maar ook betekent dat niets je waarschuwt. Ik moest handmatig greppen naar weesverwijzingen. Een linkcontroleur gaat op mijn ooit-lijst.
Ik atomiseerde aanvankelijk te veel. Dronken van de "één concept per bestand"-regel, verbrijzelde ik een samenhangend onboardinghandboek in elf microbestanden: één per stap. Dat is geen minimalisme, dat is confetti. De agent moest nu een enkel proces reconstrueren uit elf fragmenten, wat erger is dan één goed gestructureerd bestand. Minimalisme in OKF betekent één samenhangend idee per bestand, niet één zin per bestand. Ik combineerde ze terug tot een enkele onboarding-sequence.md met secties met koppen. De grens tussen "atomair" en "versnipperd" is oordeelsvermogen, en ik had het fout voordat ik het goed had.
Geen van deze zijn dealbreakers. Het is de normale wrijving van structuur opleggen aan een jaar organische rommel. Maar als je erin gaat met de verwachting dat een tool ze afhandelt, lever je een bundel die er conform uitziet maar slecht navigeert. De specificatie valideert vorm, niet kwaliteit. Kwaliteit is nog steeds jouw taak.
Dat behandeld, hier is wat ik daadwerkelijk kreeg voor het weekend.
De OKF Second Brain Resultaten: Wat Er Werkelijk Veranderde
Ik wil hier voorzichtig zijn, want dit is precies waar kennisbank-inhoud oneerlijk wordt met verzonnen benchmarks. Ik heb geen gecontroleerd token-telstudie gedraaid met nette foutbalken, dus ik ga je geen nep "73% minder tokens"-getal geven. Wat ik je wel kan geven is wat er veranderde in waarneembaar agentgedrag, en het mechanisme dat het verklaart.
De duplicatie stopte. Dit was de hele reden dat ik begon. Omdat regel 3 van het protocol een indexcontrole afdwingt voor creatie, en omdat de index een echte kaart is die de agent goedkoop kan scannen, vindt Claude nu het bestaande concept en werkt het bij in plaats van ding-v2-FINAL.md te schrijven. In de weken sinds de conversie heb ik geen enkel dubbel concept meer gevangen. Dat alleen al rechtvaardigde het weekend.
De agent opent minder bestanden om te antwoorden. Vroeger betekende het beantwoorden van een vraag dat de agent meerdere bestanden doorskimde om de relevante te vinden. Nu leest hij index.md, kiest het bestand waarvan de description overeenkomt, en opent dat ene. Ik zag het een vraag beantwoorden die slechts één van veertig concepten kon beantwoorden — het las de index, opende precies dat bestand, en raakte de andere negenendertig nooit aan. Het mechanisme is simpel en echt: het parsen van een korte YAML-beschrijving is veel goedkoper dan het lezen van een volledige bestandsbody, dus filteren op beschrijvingen eerst betekent minder verspilde volledige-bestandslezingen. Dat is geen benchmark; het is hoe progressieve onthulling werkt.
Het stopte met het opnieuw afleiden van context. De meest bevredigende verandering is de moeilijkste om te screenshotten. Met een stabiele, navigeerbare kennisbank stopt de agent met het elke sessie opnieuw samenvatten van dezelfde achtergrond omdat hij betrouwbaar de gesynthetiseerde versie kan vinden die hij vorige keer schreef. De /raw vs wiki-scheiding versterkt dit — afgerond denken leeft in de wiki en wordt hergebruikt, in plaats van elke keer opnieuw geëxtraheerd te worden uit ruwe notities.
Het is eindelijk overdraagbaar. Mijn second brain is nu een map van standaard markdown die ik naar een Git-repo zou kunnen pushen, aan een andere agent zou kunnen geven, of een stukje van zou kunnen delen, en het zou nog steeds iets betekenen voor de setup van een vreemde. Dat was eerder niet waar. Het format is de gedeelde taal die een privésysteem leesbaar maakt voor iedereen — mens of agent.
Voor het diepere "waarom verslaat gestandaardiseerde structuur een slimme Claude.md"-argument, heb ik de niveaus van agentgeheugen uiteen gezet in mijn zes niveaus van Claude Code-geheugensystemen — OKF is in essentie een schone, deelbare implementatie van de hogere niveaus.
De eerlijke samenvatting: OKF maakte mijn agent niet slimmer. Het maakte de omgeving van mijn agent leesbaar, en een leesbare omgeving is wat voorkomt dat een capabele agent dom handelt.
Moet Je Jouw Second Brain Omzetten Naar OKF?
Direct antwoord: converteer als je kennisbank groot genoeg is dat de agent het overzicht verliest van wat erin zit — en sla het over als je onder de vijftig bestanden zit en alles nog comfortabel in het hoofd van de agent past.
De conversie heeft echte kosten. Je zult uren besteden aan het schrijven van onderscheidende beschrijvingen, het ontwerpen van een type-vocabulaire en het beoordelen van geautomatiseerde splitsingen. Die kosten betalen zich alleen terug wanneer je basis groot genoeg is dat navigatie het knelpunt is geworden. Bij dertig goed benoemde bestanden is een goede Claude.md oprecht prima en is OKF overkill. De duplicatie-en-zoekbelasting die ik tegenkwam is een schaalprobleem.
Converteer als een van deze waar is: je agent dupliceert kennis die hij al heeft, opvraging voelt traag en token-zwaar, je wilt de basis delen of laden in verschillende tools, of je draait al een Karpathy-stijl levende wiki en wilt dat die een standaard spreekt die andere tools kunnen consumeren. Als je dat levende-wiki-patroon bouwt, past mijn Obsidian + Claude Code second brain walkthrough er natuurlijk bij — Obsidian voor de menselijke grafiekweergave, OKF als de on-disk standaard eronder.
Wacht als je onder de vijftig bestanden zit, als je basis puur persoonlijk is en nooit gedeeld zal worden, of als je in de verleiding komt om te converteren omdat OKF nieuw en glimmend is in plaats van omdat je tegen een echte muur bent gelopen. Nieuw is geen reden. Een muur wel.
Eén ding dat ik niet zou doen: OKF v0.1 als afgerond behandelen. Google noemde het een beginpunt, en dat is het — er is nog geen formeel ontdekkingsprotocol ingebouwd, geen linkvalidatie, geen handhaving van kwaliteit. Erop bouwen is slim. Je hele operatie inzetten op zijn huidige vorm is dat niet. Converteer het deel dat pijn doet, leer de vorm, en laat de specificatie rijpen voordat je all-in gaat.
Veelgestelde Vragen
Wat is een OKF second brain?
Een OKF second brain is een persoonlijke kennisbank gestructureerd volgens Google's Open Knowledge Format — een directory van markdown-conceptbestanden met YAML front matter, voorafgegaan door een index.md-kaart, die zowel jij als een AI-agent zoals Claude kan lezen, navigeren en bijwerken. Het vervangt ad-hoc mappen en een lange Claude.md door een gestandaardiseerde, overdraagbare vorm.
Hoe zet ik een bestaande Claude-kennisbank om naar OKF?
Converteer eerst één map met de hand om het format te leren, definieer een vast type-vocabulaire, gebruik vervolgens een tool zoals de okf-skills Claude Code plugin om front matter aan de rest toe te voegen. De moeilijkste stap — samengebakken notities opsplitsen in schone enkele concepten — heeft nog menselijke beoordeling nodig. Eindig door een index-eerst protocol toe te voegen aan je Claude.md. Zie de conversie-walkthrough hierboven voor de exacte stappen.
Maakt OKF Claude sneller in het doorzoeken van mijn notities?
OKF vermindert verspilde bestandslezingen in plaats van het model zelf sneller te maken. Omdat de agent korte YAML description-velden in de index leest voordat hij een bestand opent, filtert hij naar het relevante concept zonder irrelevante te doorbladeren — wat het tokengebruik bij opvraging verlaagt. De winst schaalt met hoe groot en rommelig je basis was om mee te beginnen.
Heb ik nog een Claude.md-bestand nodig bij een OKF second brain?
Ja, maar zijn taak krimpt. In plaats van al je structuur in proza vast te houden, wordt Claude.md een kort protocol dat de agent vertelt om eerst index.md te lezen, te navigeren op beschrijvingen, te controleren op duplicaten voor het aanmaken, en wijzigingen te loggen. De structuur leeft in de bundel; Claude.md vertelt de agent alleen hoe hij die moet gebruiken.
Is OKF beter dan RAG voor een second brain?
Ze lossen verschillende problemen op. RAG doorzoekt een statische stapel ingesloten fragmenten en herbouwt context bij elke query zonder kennis op te bouwen. Een OKF second brain is een gecureerde, levende set concepten die de agent leest en bijwerkt in de loop der tijd, zodat het accumuleert. Voor evoluerende persoonlijke kennis die je herziet, past de onderhoudbare structuur van OKF doorgaans beter dan pure vector RAG.
De Map Die Stopte Met Vergeten
Ik begon dit hele experiment vanwege twee tegenstrijdige prijsbestanden. Ik eindig er ook mee, want de oplossing is het punt.
Een paar dagen na de conversie vroeg ik Claude om mijn prijslogica bij te werken voor een nieuwe servicetier. Het las de root-index, ging direct naar business/pricing-logic.md, opende dat ene bestand, herzag het en voegde een regel toe aan log.md. Geen nieuw bestand. Geen v2-FINAL. Geen tegenstrijdigheid. Het vond het ding dat het al wist en veranderde het, zoals een persoon met een echt geheugen zou doen.
Dat is de hele belofte van een OKF second brain, en het is kleiner en eerlijker dan de hype rond het format suggereert. OKF gaf mijn agent geen intelligentie. Het gaf hem een kaart die hij kon vertrouwen — en een capabele agent met een betrouwbare kaart stopt met zich te gedragen als een amnestiepatiënt. Het format zal evolueren voorbij v0.1, de tooling zal beter worden, en de verkoopbare-bundel-marktplaats die mensen blijven voorspellen komt misschien wel of misschien niet. Niets daarvan verandert de zet die vandaag voor je beschikbaar is.
Dus hier is het ene ding dat het waard is om te doen voordat deze week eindigt: pak je enkele rommeligste kennismap — degene waar je agent steeds over struikelt — en converteer alleen die ene naar OKF met de hand. Schrijf de index. Schrijf onderscheidende beschrijvingen. Voeg het vierregelige protocol toe aan Claude.md. Stel je agent dan een vraag die slechts één bestand kan beantwoorden, en kijk wat het doet. Als het de kaart leest en precies het juiste bestand opent, begrijp je in dertig seconden wat mij een weekend kostte om te voelen.
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
