Claude Code geheugensystemen: de 6 niveaus uitgelegd

Claude Code geheugensystemen: de 6 niveaus uitgelegd

Ik brak afgelopen dinsdag bijna mijn hele contentoperatie door mijn geheugensysteem te upgraden naar een niveau dat ik niet nodig had.

De setup die mijn business runt: 232 gepubliceerde posts op mejba.me, vier merkstemmen, een @aria agent die artikelen van 3.000 woorden in één keer schrijft, en een geheugenlaag die de toon van elk merk moet onthouden, elke cluster, elke verboden zinsnede, elke footer-template. Ongeveer drie maanden lang was die geheugenlaag gewoon twee markdown-bestanden. Toen las ik een thread waarin werd beweerd dat "echte" Claude Code-gebruikers RAG-ondersteunde geheugenpaleizen met vector indexes draaien, en besteedde ik een hele middag aan een poging er een aan te sluiten.

Aan het eind van die middag had ik drie skills kapot, één auto-memory van een project corrupt, en exact nul nieuwe content geproduceerd. Dus rolde ik het hele zaakje terug, opende een leeg document, en dwong mezelf om écht in kaart te brengen hoe Claude Code-geheugen er in 2026 uitziet — elk niveau, wat het kost, voor wie het is. Niet in theorie. Op basis van wat ik daadwerkelijk heb gedraaid, wat ik andere operators heb zien draaien, en wat ik scheef heb zien gaan.

Er zijn zes niveaus. De meeste mensen die Claude Code draaien hoeven nooit boven niveau drie te klimmen. Een paar wel. Het verkeerde niveau kiezen — te simpel of te complex — is wat weekenden verbrandt. Deze post is de kaart die ik wou dat ik had voordat ik begon te klimmen.

Waarom Claude Code-geheugen er überhaupt toe doet in 2026

Als je Claude Code als opgepoetste autocomplete gebruikt, is geheugen irrelevant. Open een tab, typ een prompt, sluit hem, klaar. Het model hoeft niets over je te onthouden omdat er niets te onthouden is.

Maar het moment dat je workflow vorm heeft — terugkerende taken, merkstemmen, code-conventies, beslissingen die je hebt genomen en niet elke maandag opnieuw wilt uitleggen — wordt geheugen de grootste hefboom tussen "Claude is soms behulpzaam" en "Claude is een teamlid." Dat is geen marketingtaal. Dat ben ik, kijkend hoe dezelfde agent gaat van het genereren van generieke SEO-posts naar het in één keer raak nailen van mijn merkstem, gewoon omdat ik hem een gestructureerde geheugenlaag gaf om uit te putten.

Het probleem in 2026 is dat "Claude Code-geheugen" nu verwijst naar minstens zes verschillende architecturen, variërend van één markdown-bestand in je projectroot tot een self-hosted Postgres-database met embeddings gedeeld over Claude, ChatGPT en Cursor. De officiële docs behandelen de eerste goed. De community heeft de andere vijf gebouwd. Bijna niemand legt uit waar elk van hen ophoudt de complexiteit waard te zijn.

Wat de vraag is waar het mij echt om gaat. Want elk niveau boven het niveau dat je nodig hebt is gewoon belasting — engineering belasting, debug belasting, aandacht belasting. Dus laten we ze langslopen.

Niveau 1: basaal native geheugen (claude.md + memory.md)

Dit is waar Claude Code mee komt. Geen plugin. Geen vector database. Geen hooks. Gewoon twee markdown-bestanden die het model bij sessiestart laadt.

claude.md is je instructiebestand op projectniveau. Jij schrijft het. Het bevat de regels, conventies, merkstemmen, verboden zinsneden, bestandspaden — alles wat je wilt dat het model elke keer weet als je een sessie in die directory opent. Volgens de officiële Claude Code docs wordt het bestand automatisch in context geladen en behandeld als gezaghebbende projectrichtlijn.

memory.md (ook wel auto-memory genoemd) is wat Claude over jou schrijft. Als je hem corrigeert ("gebruik geen puntkomma's in deze codebase"), of hij komt erachter wat een buildcommand is, of hij leert een workflow-voorkeur, vraagt hij of dat als geheugen opgeslagen mag worden. Jij bevestigt. Volgende sessie onthoudt hij het.

Samen vormen deze twee bestanden een werkende geheugenlaag die nul dollar kost, volledig op je machine draait, en zo'n 70% afhandelt van wat een single-developer of solo-operator workflow nodig heeft. Mijn hoofd-claude.md voor de ai-agents-team repo is ongeveer 180 regels. Het definieert de vier merkstemmen, het outputformaat, de harde constraints, de directory-layout. Dat is het. Geen vectoren. Geen embeddings. Geen daemons.

De catch — en dit is de catch waar niemand je voor waarschuwt — is context rot. Als claude.md voorbij ongeveer 200 regels groeit, begint het model erover te scannen. Specifieke regels worden genegeerd. Verboden zinsneden sluipen terug in de output. Je begint te denken dat het model kapot is, maar eigenlijk heb je gewoon te veel gepropt in de slot van het contextvenster die de meeste aandacht verdient. Ik heb dit drie keer in mijn eigen setup zien gebeuren. De fix is altijd hetzelfde: splits het bestand op, of verplaats vaste regels naar iets meer gestructureerds.

Voor wie niveau 1 is: Iedereen die net begint met Claude Code. Iedereen wiens hele workflow in één project past. Iedereen die "wat moet deze AI over mij weten?" in minder dan 200 regels kan beantwoorden. Kun je die vraag nog niet beantwoorden, dan heb je geen geheugenprobleem — je hebt een helderheidsprobleem, en infrastructuur toevoegen lost dat niet op.

Waar het breekt: De week dat je je realiseert dat je zeven verschillende claude.md-bestanden onderhoudt over zeven projecten, allemaal dezelfde kernregels herhalend.

Niveau 2: enhanced memory injection (hooks + mappenstructuur)

Hier woonde ik het grootste deel van 2026. Het is ook waar de meeste mensen die ik in deze ruimte respecteer zijn neergestreken.

Het idee is simpel. In plaats van één gigantische claude.md, splits je geheugen in een mappenstructuur — meestal drie buckets:

• general/ — cross-project regels. Stem, ethiek, output-opmaak.
• domain/ — onderwerp-specifiek geheugen. SEO, copywriting, security, design.
• tool/ — tool-specifiek geheugen. Claude Code skills, Figma MCP-gebruik, Webflow-valkuilen.

Dan voeg je een session-start hook toe — een script dat draait op het moment dat Claude Code opspint. De hook leest een index van je geheugenmappen en injecteert alleen het relevante deel in context. SEO nodig? Hook injecteert het SEO-geheugen. Werk je aan een design system? Hij haalt het design-geheugen en slaat de rest over.

Hooks zijn geen natural-language instructies — het zijn scripts die op events vuren. PreToolUse, PostToolUse, SessionStart, UserPromptSubmit. De officiële docs in 2026 zijn duidelijk over dit onderscheid, en het doet ertoe: hooks zijn deterministisch. Ze draaien of het model er nu zin in heeft of niet. Dat is het hele punt.

Wat je krijgt van niveau 2:

1. Geen context rot. Elk geïnjecteerd deel blijft klein en specifiek.
2. Team sharing. Je geheugenmap is gewoon markdown — commit het in git, je teamgenoot cloned het, ze krijgen jouw standaarden.
3. Selectieve recall. Werk je aan een Laravel-project? Het Figma-geheugen laadt niet. Je contextvenster blijft schoon.
4. Versionering. Geheugen is nu een getrackt artefact, geen runtime side effect.

De kosten zijn één middag opzetten. Je schrijft de mappenstructuur, schrijft een klein hookscript (de mijne is 40 regels Bash plus een JSON-config), test het één keer, en daarna draait het gewoon. Ik behandel het bredere hookpatroon in mijn analyse van SEO-checks automatiseren met Claude Code routines — dezelfde architectuur, andere toepassing.

Voor wie niveau 2 is: Iedereen die Claude Code langer dan een maand gebruikt. Iedereen wiens geheugenbestand de 200 regels heeft overschreden. Iedereen die met een team werkt. Iedereen die multi-project workflows draait waarbij de regels overlappen maar niet identiek zijn.

Waar het breekt: Als je geheugenmap een bepaalde grootte bereikt — noem het 50+ bestanden — en de index-hook begint te veel "relevante" delen te injecteren, of erger, mist juist het echt relevante. Op dat punt is keyword-stijl relevantie-scoring niet genoeg. Je hebt semantiek nodig.

Niveau 3: semantische vectorzoektocht met MemSearch

Dit is het niveau dat ik momenteel draai, en het niveau waarop ik aanraad te stoppen tenzij je een specifieke reden hebt om verder te gaan.

MemSearch is een markdown-first geheugensysteem uitgebracht door Zilliz, het team achter Milvus. Hun eigen beschrijving noemt het "een standalone library voor elke AI-agent, geïnspireerd door OpenClaw." De Claude Code-plugin zit bovenop de core CLI, en de architectuur is eerlijk over wat het is: een hybride retrieval-laag over platte markdown-bestanden.

Hier is wat interessant is. MemSearch vervangt je geheugenbestanden niet. Het indexeert ze. Je geheugen leeft nog steeds als mens-leesbare markdown — je kunt het in elke tekstverwerker bewerken, in git versionien, op een vliegtuig zonder internet lezen. De vectorindex is een cache. Volgens de Milvus blogpost over MemSearch "herbouwt" de index "op elk moment vanuit Markdown."

Drie lagen recall:

1. Long-term feiten — duurzame kennis. Merkstem-regels, beleids- en architectuurkeuzes.
2. Daily notes — sessiesamenvattingen met timestamp, sessie-ID, turn-ID. Platte tekst. Volledig mens-leesbaar.
3. Dreaming / promotion — periodieke compactie waarbij korte-termijn notities worden gepromoot tot long-term feiten als ze duurzaam blijken.

Retrieval gebruikt hybride zoektocht — semantische vectoren voor "vind content gerelateerd aan deze query zelfs als de bewoording verschilt," plus BM25 voor "vind content die deze exacte trefwoorden gebruikt," samengevoegd met Reciprocal Rank Fusion (RRF) reranking. Dat laatste deel is wat keyword-zoeken op schaal verslaat. Als mijn geheugen 400 markdown-chunks heeft over vier merken, vindt semantische zoektocht de colorpark.io merkstem-regel zelfs als ik mijn prompt in totaal andere woorden formuleer dan ik in het geheugenbestand gebruikte. Keyword-zoeken mist dat. Semantisch + BM25 + RRF vangt beide.

De retrieval is ook getrapt, wat ik geweldig vind:

• L1 (automatisch): top-3 semantische resultaten met previews, geïnjecteerd op elke prompt. Dekt de meeste use cases.
• L2 (on-demand): complete markdown-secties wanneer volledige context nodig is.
• L3 (deep): ruwe gespreksrecords wanneer je exacte dialoog uit een eerdere sessie nodig hebt.

Voor mij raakt L1 ongeveer 90% van wat ik nodig heb. L2 vuurt als ik iets dichts schrijf en de volledige stemprofielen van een merk nodig heb. L3 heb ik misschien twee keer gebruikt in twee maanden — beide keren om de exacte bewoording van een klantbeslissing te vinden.

De setup is één plugin-installatie plus een vectorstore (Milvus draait lokaal; je kunt hem ook op managed richten). De kosten zijn je tijd om te leren wat elke laag doet. De eerste week voelt overgeëngineerd. De tweede week merk je het niet meer omdat het gewoon werkt.

Voor wie niveau 3 is: Operators met substantieel opgebouwd geheugen — noem het 100+ markdown-bestanden, of een jaar sessiegeschiedenis, of multi-merk workflows zoals de mijne. Solo-founders die een AI-first business runnen. Iedereen wiens niveau 2-setup het juiste deel begint te missen op complexe prompts.

Waar het ophoudt genoeg te zijn: Als je verbatim recall van eerdere gesprekken nodig hebt, geen semantisch-vergelijkbare parafraseringen. Of als je geheugen ergens anders dan op je laptop moet leven.

Dit is ook waar de meeste contentoperators eerlijk gezegd zouden moeten stoppen. Ik testte niveau 4, 5 en 6, en rolde elke keer terug naar niveau 3 — omdat de marginale recall-verbetering de operationele complexiteit niet waard was voor mijn echte werk, namelijk het versturen van artikelen. Als je werk iets anders is, kan de wiskunde anders uitkomen. Laten we kijken wanneer.

Niveau 4: verbatim recall met Memory Palace (RAG)

Hier begint geheugenarchitectuur op echte engineering te lijken, en hier moet je stoppen en jezelf afvragen of je het daadwerkelijk nodig hebt.

Een memory palace — soms Me Palace, MemPalace of memory palace RAG genoemd — is een Retrieval-Augmented Generation systeem dat exacte gesprekstekst opslaat in een symbolisch geïndexeerde structuur. De metafoor is de oude mnemonische techniek: je hebt vleugels, kamers in die vleugels, kasten in die kamers, en lades in die kasten. Elke la bevat een specifiek verbatim chunk. Pointers indexeren alles.

De gepubliceerde cijfers van de betere implementaties zijn echt: ongeveer 42ms retrieval-latency via geïndexeerde pointers, met wat hun auteurs claimen als de hoogst gepubliceerde recall-benchmark in de open-source geheugenruimte. De architectuur is doorgaans SQL plus vector DB — SQL voor de gestructureerde pointer-index, vectoren voor de semantische match. Lokaal. Gratis. Self-hostable.

Waarom zou je dit willen? Omdat semantische zoektocht op niveau 3 parafrasering en samenvattingen teruggeeft. Een memory palace geeft de exacte woorden terug die iemand zei, in de exacte volgorde, met de exacte interpunctie. Voor sommige workflows is dat enorm belangrijk:

• Juridisch of compliance werk — je hebt de verbatim bewoording van een clausule nodig.
• Therapeutische notities of coaching — je moet de eigen formulering van de klant aan hem terugciteren.
• Onderzoeksinterviews — je moet exact citeren wat is gezegd in interview 47, geen samenvatting.
• Langlopende RPG's of fictieprojecten — het personage moet onthouden wat hij echt zei in hoofdstuk 3.

Voor mijn contentworkflow? Ik heb geen verbatim recall nodig. Als ik een artikel schrijf over Claude Code, hoef ik niet te citeren wat ik zes maanden geleden over Claude Code zei — ik heb gewoon de essentie nodig. Dus memory palace zou dure infrastructuur zijn waar ik nooit naar grijp.

Voor wie niveau 4 is: Mensen wiens werk afhangt van exacte bewoording. Juridisch, medisch, onderzoek, bepaalde creatieve schrijfpijplijnen, voice-of-customer analyse waarbij parafrasering de data vernietigt.

Waar het breekt: Als je meer tijd besteedt aan het tunen van de indexhiërarchie dan aan het daadwerkelijk gebruiken van de recall. Memory palaces hebben een echte onderhoudsbelasting — je draait nu een kleine database, en databases hebben aandacht nodig.

Niveau 5: interconnected knowledge base (LLM Wiki)

Dit is het niveau dat de meeste hype krijgt omdat Andrej Karpathy het noemde. Het is ook het niveau dat het vaakst verkeerd wordt toegepast.

Het patroon, oorspronkelijk uit Karpathy's gist over LLM Knowledge Base architectuur, is: in plaats van query-time RAG te doen, laat je een LLM je inkomende bronnen — artikelen, podcasts, transcripten, PDF's — compileren tot een blijvende, doorbladerbare markdown-wiki. De synthese gebeurt één keer bij ingest. Daarna is elke retrieval gewoon een afgeronde pagina lezen. Zoals VentureBeat het samenvatte, fungeert de LLM als een "voltijds research librarian, die markdown-bestanden actief compileert, lint en interlinkt."

Twee mappen:

• raw/ — read-only inputs. Transcripten, artikelen, ruwe notities. Wordt nooit gewijzigd.
• wiki/ — AI-beheerd. Encyclopedie-stijl synthesepagina's met backlinks tussen concepten.

Je kunt het hele ding visualiseren in Obsidian, die de markdown-wiki rendert als een navigeerbare kennisgraaf — vakjes verbonden door lijnen, het soort dat er prachtig uitziet in een screenshot en oprecht nuttig is als je werk research is.

Er bestaan verschillende community-implementaties. De OpenClaw memory-wiki plugin compileert workspace-geheugen tot een wiki-directory met een index-catalogus, module-synthesepagina's en machineleesbare digests. Er is een Karpathy-stijl LLM wiki Agent Skill voor OpenClaw en Codex. Er is obsidian-wiki, een framework voor AI-agents om een Obsidian-wiki te bouwen en onderhouden volgens Karpathy's patroon.

Dit is prachtige architectuur. Het is ook fout voor operationeel projectgeheugen. Hier is waarom.

Een wiki is een statische referentie. Hij is geoptimaliseerd voor "ik wil over X lezen." Maar operationeel projectgeheugen moet "wat was de regel over X?" of "wat besloten we vorige sprint over X?" beantwoorden. Dat is een ander toegangspatroon. Een LLM-wiki proberen te gebruiken als je operationele geheugen is als een encyclopedie gebruiken als je todo-lijst — technisch mogelijk, fundamenteel mismatched.

Waar een LLM-wiki wel goed in is: deep research projecten. Een echte kennisbasis bouwen vanuit bronnen die je over tijd inneemt. Content-organisatie waar je een onderwerp synthetiseert over tientallen inputs en aan het eind een navigeerbaar artefact wilt. Ik heb overwogen er één te bouwen voor het hele mejba.me-archief — 230+ artikelen gesynthetiseerd in een Karpathy-wiki — puur als research-artefact voor mijn eigen toekomstige schrijven. Ik heb de trekker niet overgehaald omdat de upfront synthese-kosten echt zijn en ik nog niet zeker weet of de uitbetaling het al rechtvaardigt.

Voor wie niveau 5 is: Onderzoekers. Knowledge workers die bouwen bovenop grote broncorpora. Schrijvers die diepe onderwerpsynthese doen. Educators die cursusmateriaal bouwen. Mensen die baat hebben bij een Obsidian-graaf van hun eigen denken.

Waar het breekt: Als operationeel projectgeheugen. Gebruik er geen wiki voor. Gebruik niveau 2 of 3.

Niveau 6: cross-tool unified memory (Open Brain / Mem.ai)

Het laatste niveau, en het niveau dat de laptopgrens doorbreekt.

Het uitgangspunt: je geheugen moet niet vastzitten aan één tool. Als je Claude maandag iets vraagt, dan ChatGPT dinsdag een gerelateerde vraag stelt, dan woensdag code in Cursor schrijft — alle drie zouden uit dezelfde geheugenstore moeten putten. Eén brein. Veel gezichten.

Twee hoofdsmaken in 2026:

Hosted (Mem.ai, Mem0, Zep, MemPalace): Productieklare cross-tool memory as a service. Volgens Mem0's pricing dekt de free tier 1.000 herinneringen per maand, betaalde plannen beginnen bij $19/mnd voor 10K herinneringen, en graph memory zit achter een Pro plan van $249/mnd. Hun integratiedekking loopt over 21 frameworks en platforms in Python en TypeScript. Dit is volwassen infrastructuur nu — geen sideproject.

Self-hosted (Open Brain, custom Postgres + pgvector): Dezelfde architectuur, je bezit hem zelf. Postgres (vaak via Supabase, die pgvector out of the box biedt) slaat chunks plus embeddings op. Goedkoper op schaal omdat je infrastructuurkosten betaalt, geen per-memory pricing. Meer controle. Meer setup. Meer dingen die je moet onderhouden.

Beide smaken voegen real-time gedeeld geheugen toe over Claude Desktop, Claude Code, ChatGPT, Cursor, en elke tool met een MCP-server of API-hook. Dat is de magie. Vraag Claude over een projectbeslissing; later, in Cursor, weet de codegeneratie het al.

De catches zijn niet theoretisch:

1. Latency. Een netwerkcall naar een remote geheugenstore voegt 100-500ms toe per retrieval. Op een snelle prompt is dat prima. Op een strakke loop met frequente retrievals is het merkbaar.
2. Externe dependency. Hosted geheugen betekent een vendor vertrouwen met je context. Self-hosted betekent een database babysitten.
3. Sync conflicts. Twee tools die tegelijk naar hetzelfde geheugen schrijven creëert merge-problemen die geen architectuur volledig heeft opgelost.
4. Privacy-oppervlak. Wat in je unified memory leeft is nu bereikbaar vanuit elke tool die je hebt verbonden. Dat is de feature. Het is ook het risico.

Voor wie niveau 6 is: Power users die echt multi-tool workflows draaien. Engineers die meerdere keren per dag tussen Claude, ChatGPT en Cursor context-switchen. Teams waar AI-ondersteund werk constant grenzen tussen tools overschrijdt. Iedereen die een echte "second brain"-pijplijn draait die al verder reikt dan één AI.

Waar het breekt: Voor de meeste solo-operators weegt de latency- en complexiteitsbelasting zwaarder dan het cross-tool gemak. Ik testte zowel Mem0's hosted tier als een Supabase + pgvector setup. Beide werkten. Beide voegden 200-300ms toe aan elke prompt. Beide vroegen aandacht die ik liever aan schrijven besteed.

Hoe je je niveau kiest zonder een weekend te verbranden

Hier is het beslissingsframework dat ik mijn ik-uit-het-verleden zou geven vóór die kapotte dinsdag.

Begin op niveau 1. Verstuur iets. Kijk wat breekt. De twee vragen die ertoe doen: is claude.md voorbij 200 regels, en onderhoud je dezelfde kernregels in meerdere projecten?

Ga naar niveau 2 als het antwoord op een van beide vragen ja is, of als je langer dan een maand op Claude Code zit en je geheugen duidelijk verder is gegroeid dan wat één bestand zou moeten bevatten. Mappenstructuur plus session-start hook. Eén middag.

Ga naar niveau 3 als niveau 2 het juiste geheugendeel begint te missen op complexe prompts, of je geheugen voorbij ~100 markdown-chunks gaat. MemSearch-plugin, hybride retrieval. Eén dag opzetten. Dit is waar de meeste serieuze operators neerstrijken.

Overweeg niveau 4 alleen als je werk afhangt van verbatim bewoording — juridisch, medisch, onderzoek, voice-of-customer. Bouw geen memory palace omdat het cool klinkt.

Overweeg niveau 5 alleen als je deep research synthese doet over veel bronnen en een navigeerbaar artefact wilt. Het is geen operationeel geheugen. Het is een kennisproduct.

Overweeg niveau 6 alleen als je al dagelijks tussen drie of meer AI-tools context-switcht en de geheugenkloof tussen hen je werk actief schaadt. Anders is de latency-belasting het niet waard.

Het patroon: elk niveau boven het niveau dat je nodig hebt is wrijving. Elk niveau onder het niveau dat je nodig hebt is lekkage. De sweet spot is het laagste niveau dat je daadwerkelijke werklast aankan, niet het hoogste niveau waar je peers over opscheppen.

Voor mij — multi-merk content op schaal, met @aria over vier merken, soms gecoördineerd met skill-stacks zoals die ik heb uitgesplitst in mijn Claude Code skills stack post en de top Claude Code skills voor business efficiency — is niveau 3 waar de wiskunde werkt. Verbatim recall verandert mijn output niet. Cross-tool unified memory ook niet, want @aria is een Claude Code-agent die in één tool leeft. Dus blijf ik op niveau 3, bespaar de engineering-belasting, en verstuur meer artikelen.

Als jouw wiskunde anders is, klim. Als hij dat niet is, doe het niet.

Wat ik iemand zou vertellen die vandaag begint

Wat ik onderschatte, vóór de kapotte dinsdag en de herbouw die volgde, is dat geheugen leverage is, maar alleen op het niveau dat overeenkomt met je werk. Niveau 1 is genoeg leverage voor de meeste mensen. Niveau 3 is genoeg leverage voor bijna iedereen anders. De resterende niveaus bestaan voor specifieke vormen van werk, en ze behandelen als aspirational doelen is hoe je middagen verspilt.

Wat me hielp er correct over na te denken, was kijken naar hoe het ecosysteem daadwerkelijk evolueerde. De memsearch repo was geïnspireerd door OpenClaw, dat voortbouwde op community-patronen, dat voortbouwde op de originele Anthropic claude.md primitive. Elk niveau wikkelt het niveau eronder. Niets ervan vervangt de laag eronder — het voegt alleen toe. Dat betekent dat je altijd later kunt klimmen. Je verliest niets door klein te beginnen. Je verliest alleen tijd als je groot begint en het niet past.

Als ik vandaag met Claude Code zou beginnen, met de kennis die ik nu heb, zou ik exact dit doen:

1. Open een project. Schrijf claude.md. Houd het onder 200 regels. Gebruik het een week.
2. Merk op wat er ontbreekt. Voeg het toe. Cap de bestandslengte op het moment dat het 200 dreigt.
3. Na een maand, splits in een geheugenmap met general / domain / tool buckets. Voeg een session-start hook toe.
4. Na drie maanden, als je geheugen duidelijk over keyword-retrieval is heengegroeid, installeer MemSearch.
5. Stop. Heroverweeg alleen als een specifieke workflow het eist.

Dat is het pad. Het is saai. Het werkt. Zo run ik een multi-merk contentoperatie op een geheugenlaag die in één enkele repo past en herbouwt vanuit markdown.

De dinsdag dat ik die stappen probeerde over te slaan kostte me een werkmiddag. De dinsdag erop, met niveau 3 echt op orde, verstuurde @aria vier artikelen in één keer. Dezelfde agent. Hetzelfde model. Andere geheugenarchitectuur, op maat gemaakt voor de echte taak.

Kies het niveau dat je werk vereist. Niet het niveau dat de thread je heeft verteld te draaien.

Veelgestelde vragen

Wat is het verschil tussen claude.md en memory.md in Claude Code?

claude.md is een instructiebestand op projectniveau dat je handmatig schrijft — het bevat regels, conventies en vaste richtlijnen die bij sessiestart worden geladen. memory.md is auto-memory, waar Claude zelf notities opslaat van correcties en voorkeuren over sessies heen. Jij bent de auteur van de ene; Claude onderhoudt de andere. Beide laden samen in context.

Hoe voorkom ik context rot in claude.md?

Houd claude.md onder ongeveer 200 regels, splits het dan in een geheugenmap met general, domain en tool buckets. Gebruik een session-start hook om alleen het relevante deel per sessie in context te injecteren. Lange monolithische geheugenbestanden zorgen ervoor dat het model scant in plaats van leest, wat de oorzaak is van context rot.

Is MemSearch beter dan basaal Claude Code-geheugen?

MemSearch verslaat basaal geheugen zodra je opgebouwde kennis ongeveer 100 markdown-chunks overschrijdt, omdat hybride semantische + BM25 retrieval relevante context vindt die alleen-keyword-loading mist. Voor kleinere setups onder die drempel voegt het complexiteit toe zonder zinvolle verbetering. De meeste operators hebben het in hun eerste drie maanden niet nodig.

Wat is een memory palace in AI-workflows?

Een memory palace is een RAG-systeem dat exacte verbatim gesprekstekst opslaat in een symbolisch geïndexeerde structuur — doorgaans vleugels, kamers, kasten en lades — met SQL plus een vector database voor retrieval. Het is geoptimaliseerd voor recall met exacte bewoording, niet voor parafraseerde betekenis. Nuttig voor juridische, medische of onderzoeksworkflows waar exacte formulering ertoe doet.

Moet ik Mem.ai gebruiken of mijn eigen cross-tool geheugen bouwen?

Gebruik Mem.ai of Mem0 als je productieklare hosted memory wilt en geen infrastructuur wilt onderhouden — pricing begint bij $19/mnd voor 10K herinneringen op Mem0. Bouw je eigen met Supabase plus pgvector als je volledig data-eigenaarschap nodig hebt, voorspelbare kosten op schaal, en comfortabel bent met het onderhouden van een database. De meeste solo-operators hebben geen van beide tiers nodig.

Laten we samenwerken

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

• Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io