Sophonix
Blog
Contact
Veldnotities

BenBrain: persistent geheugen voor elke Claude-sessie

Gepubliceerd 10 mei 2026#AIInfrastructure #ClaudeAI #VectorDatabase #KnowledgeGraph #BuildInPublic

Elke Claude-sessie die ik start — telefoon, laptop, waar dan ook — weet bij het opstarten al wat er gisteren is opgeleverd en wat nog openstaat.

Een maand geleden was dat niet zo.

Een maand geleden begon elk nieuw gesprek blanco. Ik opende een tabblad, stelde een vraag, en Claude ontmoette me als vreemde. De eerste tien minuten gingen op aan het opnieuw uitleggen van het project, de stack, de beslissingen van vorige week, de bug die we om 2 uur 's nachts hadden opgespoord. Tegen de tijd dat het model genoeg context had om nuttig te zijn, was mijn mentale energie voor het echte werk al half opgesoupeerd.

Dit is de cold-start-belasting. Het is de wrijving die van 'AI als denkpartner' een belofte maakt die nooit helemaal ingelost wordt. Elke sessie is een leeg vel: je moet het toneel opnieuw opzetten.

Ik had het genegeerd omdat ik aannam dat het gewoon de aard van het gereedschap was. LLM's hebben geen geheugen tussen sessies; dat is het principe. Dus pas je je aan — zet een lange inleiding vast in je editor, houd een 'projectstatus'-document bij, plak het aan het begin van elk gesprek. En vergeet vervolgens welke versie van dat document de werkelijke huidige staat bevat, en verlies nog eens tien minuten met reconciliëren.

Uiteindelijk werd het goedkoper om het gereedschap te repareren dan de belasting te blijven betalen.

Wat ik heb gebouwd

BenBrain is een persistent geheugenlaag die achter elke Claude-sessie zit. Het zijn twee stores, beide draaiend op mijn bare-metal EU-server, beide achter mijn Tailscale-mesh, en geen van beide praat met iemand anders.

Qdrant — de vector store. Embeddings van alles wat ooit is opgeschreven. Beslissingen, pogingen, fouten, leerpunten. De taak is fuzzy recall: 'wat hebben we besloten over die OOM-crash drie weken geleden?' werkt zelfs als de woorden die ik nu gebruik niet overeenkomen met de woorden die ik toen gebruikte. Cosinus-similariteit over de embedding-ruimte is vergevingsgezind op een manier die tekst zoeken niet is.

Neo4j — de knowledge graph. Dezelfde inhoud, andere invalshoek. Elke beslissing, poging, fout, module, sessie en leermoment is een getypeerd knooppunt met getypeerde relaties naar andere knooppunten. Een Decision heeft een Why, blokkeert een Error, vervangt een andere Decision. Doorloopbaar als een graaf: vanuit elk startpunt kun je vragen 'wat heeft hiertoe geleid?' en de edges terugvolgen.

De vector store handelt 'vind me dingen zoals dit' af. De graaf handelt 'laat me zien hoe dit samenhangt' af. Verschillende vragen, verschillende vormen, dezelfde brongegevens.

Dit is de globale structuur van een entry in de graaf:

{
  "id": "sophonix:decision:notion-as-blog-cms",
  "type": "Decision",
  "title": "Sophonix blog content lives in Notion, not in-repo MDX",
  "body": "Article rich text + media live in Notion page blocks; the build pulls them at next build and mirrors assets to public/blog/ so deploys are self-contained.",
  "severity": "informational",
  "created_at": "2026-05-11T16:42:00Z",
  "relations": {
    "supports": ["sophonix:initiative:linkedin-pipeline"],
    "informed_by": ["sophonix:learning:notion-rich-text-limits"],
    "blocks": []
  }
}

Dat zijn de gegevens. Het interessante deel is de loop die ze vult.

De loop, in vier stappen

  1. Ik druk op /compact wanneer de context van een sessie begint vol te raken. Dit is de enige handmatige stap, en ik kom later terug op waarom het nog steeds handmatig is.
  2. Een hook leest het transcript. Een SessionEnd-hook in Claude Code pakt het volledige gesprek en stuurt het door een gestructureerde extractieprompt naar GPT-4o. De prompt vraagt om getypeerde entries: welke beslissingen zijn genomen, welke pogingen zijn geslaagd of mislukt, wat is er geleerd dat niet direct uit de code blijkt.
  3. Entries worden naar beide stores geschreven. De geëxtraheerde JSON wordt geëmbedded en geïndexeerd in Qdrant. Dezelfde entries worden getypeerde knooppunten in Neo4j met relaties naar de omringende context. Een beslissing verwijst naar de pogingen die ertoe hebben geleid. Een fout verwijst naar de beslissingen die hebben voorkomen dat hij zich herhaalde.
  4. De volgende sessie start met dat geheugen als openingscontext. Een SessionStart-hook bevraagt beide stores — recente entries, plus een similariteitszoekopdracht gekoppeld aan het huidige project en eventuele openstaande todos — en injecteert de resultaten als openingscontext. Tegen de tijd dat ik het eerste bericht typ, weet Claude al waar we gebleven waren.

Één commando van mij. Al het overige regelt zichzelf.

Waarom bare-metal

Dit wordt me constant gevraagd: waarom niet Pinecone, Weaviate, Neo4j Aura? Waarom dit alles draaien op een server die ik zelf draaiende moet houden?

Het kostenargument is bijzaak. Ja, het is goedkoper, maar dat is niet waarom.

Het controleargument is de kern. Deze laag bevat elke beslissing die ik neem: klantpositionering, architectuurkeuzes, security-afwegingen, half-uitgewerkte ideeën over het volgende product. Niets daarvan hoort op een server te staan die ik niet beheer. Niet die van Pinecone. Niet die van Neo4j. Van niemand. De hele reden dat ik persistent geheugen wil, is om mijn denken te externaliseren — en je denken externaliseren naar iemand anders' database is een aantoonbaar slechtere ruil dan het helemaal niet externaliseren.

Tailscale sluit de lus. De server is alleen bereikbaar binnen mijn mesh. Er is geen publieke toegang tot de geheugenlaag. Claude Code op mijn laptop bereikt Qdrant en Neo4j via Tailscale; niets anders doet dat. Nul internetblootstelling op het datapad.

Dit is hetzelfde principe dat door het consultingwerk bij Sophonix loopt: we bouwen voor klanten zoals we voor onszelf bouwen. Als ik een derde partij niet met mijn eigen beslissingslogboek zou vertrouwen, ga ik een klant niet aanraden er een met het hunne te vertrouwen.

Wat nog handmatig is gebouwd

De /compact-stap voer ik zelf uit. Dat is een bewuste keuze.

Het alternatief — continue vastlegging, waarbij de hook elke paar duizend tokens context afgaat — klinkt elegant. Maar het verdubbelt de API-kosten voor extractie, en het betekent dat het model minder controle heeft over wat als een gedenkwaardige grens telt. Een sessie die afdwaalt naar drie ongerelateerde onderwerpen wordt gefragmenteerd in drie half-uitgewerkte entries in plaats van één samenhangende draad. Handmatige compaction laat de mens beslissen hoe 'één ding' eruitziet.

Vergeten is ook nog handmatig gebouwd, in de zin dat er nog niets vergeet. Elke entry leeft voor altijd, elke embedding blijft geïndexeerd. Dat is voorlopig prima, maar het is een bekende doodlopende weg. Append-only geheugen degradeert bij retrieval lang voordat het degradeert bij opslag: naarmate het corpus groeit, raakt het signaal in elke query begraven onder historische ruis. De juiste oplossing is decay — recency-gewogen retrieval, mogelijk met expliciete 'dit is niet meer actueel'-tombstones. Nog niet gebouwd. Gelogd.

Wat er hierna komt

De roadmap, op volgorde:

  • Continue vastlegging met slimmere grenzen. Detecteer onderwerpwisselingen in het transcript en compact op die overgangen in plaats van te wachten op /compact. Menselijke review van de entries blijft gewenst, maar het markeren van 'wat te compacten' kan automatisch.
  • Decay en tombstoning. Wanneer een beslissing wordt vervangen, mag de oude niet gewoon naast de nieuwe blijven bestaan — hij moet als vervangen worden gemarkeerd, en retrieval moet worden gewogen om hem niet terug te geven.
  • Deelprimitieven. Op dit moment is BenBrain single-user. Dezelfde architectuur kan een team bedienen: een kleine groep met een gedeelde geheugenlaag, waarbij de sessie van elk lid bijdraagt aan dezelfde graaf. Hier wijst het consultingwerk naartoe: hetzelfde duurzaamheidsprobleem dat BenBrain voor mij oplost, loopt elk team uiteindelijk tegen aan.

Het punt

De infrastructuur stond altijd aan. De server was er al. De graph database, de vector store, het netwerk — dat alles.

Wat er is veranderd, is niet de infrastructuur. Wat er is veranderd, is dat het denken nu ook aanstaat. De beslissingen verdampen niet meer aan het einde van een sessie. De fouten worden niet zes weken later opnieuw gedebugd. De rode draad van 'wat we bouwen en waarom' overleeft over dagen, apparaten en contexten heen.

Dat is het deel dat ertoe doet. Niet de stack. Niet de keuze voor Qdrant boven Pinecone of Neo4j boven Aura. Dat zijn voetnoten. Het punt is dat een denkpartner die onthoudt een fundamenteel ander soort partner is dan een die dat niet doet — en om daar te komen bleek één extractieprompt, twee stores en een hook genoeg te zijn.

Wat is jouw geheugenlaag?

Genoemd
  • Qdrant
  • Neo4j
Lees dit op LinkedIn
Cookievoorkeuren

Kies wat aan staat. We delen geen gegevens met derden tenzij u hieronder akkoord gaat, en u kunt dat op elk moment intrekken.