Het artikel betoogt dat huidige AI-geheugenplugins, die gebaseerd zijn op Retrieval-Augmented Generation (RAG), fundamenteel gebrekkig zijn. Omdat ze vertrouwen op similarity searches in vectordatabases, leiden ze vaak tot contextverlies, het gebruik van verouderde informatie en een gebrek aan controle over wat de agent precies 'weet'.
De auteur stelt dat de oplossing niet ligt in het verbeteren van het ophalen van fragmenten uit het verleden, maar in document-gebaseerd geheugen. Hierbij werkt de agent met een gestructureerde set Markdown-bestanden (een 'brein') waarin instructies, specificaties en onderzoek worden vastgelegd. De workflow verandert hierdoor van prompt → bouwen → vergeten naar prompt → raadplegen → bouwen → bijwerken.
Om dit in de praktijk te brengen, heeft de auteur Operator Memory ontwikkeld: een open-source tool die agents in staat stelt om kennis op te slaan en bij te werken in Markdown-documenten, zonder gebruik van complexe vectordatabases of embeddings.
Agents hebben geen geheugen nodig. Ze hebben documentatie nodig.
Het is vreemd om dit te gebruiken wanneer je nadenkt over welk probleem je probeert op te lossen. Je wilt dat je agent je project begrijpt. Je wilt dat hij weet waar een functie zich bevindt, waarom deze is gebouwd, wat er is afgesproken en waar je prioriteiten liggen. In plaats daarvan krijg je een loterij met RAG-fragmenten (Retrieval-Augmented Generation) die bij elke prompt worden geïnjecteerd, in de hoop dat de juiste fragmenten naar boven komen drijven.
Zelfs als het werkt, begrijpt de agent je project nog steeds niet. Het hele ecosysteem van geheugenplugins lost het verkeerde probleem op. Want agents hebben geen geheugen nodig. Ze hebben documentatie nodig.
Het is allemaal gewoon RAG
Elke geheugenplugin op de markt werkt op dezelfde manier:
- Sessieverslagen worden doorlopen.
- Er worden fragmenten van "herinneringen" gegenereerd.
- Deze worden ingevoegd in een RAG-database.
- Bij elke prompt worden de top 5 fragmenten opgehaald en geïnjecteerd.
- Indien nodig krijgt de agent een tool om door de RAG-database te zoeken.
Dat is de volledige architectuur. Sommige tools zijn extra geavanceerd; ze laten de agent woord voor woord door oude verslagen zoeken, of ze implementeren een meerlaags geheugensysteem dat onderscheid maakt tussen korte- en langetermijngeheugen. Anderen voegen achtergrondprocessen (daemons) toe om herinneringen te beoordelen, samen te voegen of te ontdubbelen — zogenaamde "Dreamers" die herinneringen 's nachts herschrijven. Daarnaast zijn er continue contextcompressies en rerankers.
Elke plugin probeert nieuwe, token-verslindende "functies" toe te voegen om dezelfde gebrekkige onderliggende architectuur te repareren. En dat is precies waarom geen van deze tools betrouwbaar werkt.
Het probleem met herinneringen (Recall)
Al deze geheugenplugins kampen met dezelfde set problemen:
- Herinneringen worden op basis van gelijkenis opgehaald. Een similarity search rangschikt hoe dicht twee fragmenten bij elkaar liggen in de embedding-ruimte. Dat is alles. Je weet niet welk fragment correct is, actueel is, of wat er ontbreekt.
- Herinneringen worden zonder context opgeslagen. Een RAG-fragment kan slechts een beperkte hoeveelheid informatie bevatten. Je verliest alles daaromheen: de context, motivaties, lessen, de omgeving en meer.
- Het verleden wordt als de waarheid behandeld. Al deze plugins vertrouwen op herinnering (recall), of dat nu via het zoeken in verslagen of een vectordatabase is. Maar de codebase verandert dagelijks; hoe accuraat zijn die 500 fragmenten over authenticatie dan nog?
- Agents kunnen niet zoeken naar wat ze niet weten. Zelfs als je de agent een zoektool geeft, hoe weet de agent dan wanneer hij deze moet gebruiken? De agent weet niet wat hij niet weet.
- De opslag is niet controleerbaar. Er staan 10.000 embeddings in SQLite. Welke herinneringen bestaan er? Welke zijn verouderd? Welke zijn nooit opgehaald? Welke zijn onjuist en beïnvloeden stiekem de manier waarop je agent werkt?
Dit zijn slechts vijf van de vele problemen waar geheugenplugins tegenaan lopen en die ze niet kunnen oplossen, omdat ze allemaal dezelfde aanname doen: Agents vergeten dingen, en dat is het probleem. De oplossing is dus om te onthouden. Om beter te onthouden, zouden we meer moeten vastleggen, beter moeten indexeren en slimmer moeten ophalen.
Hun hele these draait om het vastleggen en ophalen van het verleden. Maar dat is niet hoe mensen met kennis omgaan. Niemand kijkt een teamvergadering van drie jaar geleden terug om de beperkingen van een functie te onthouden. Mensen schrijven dingen op en gebruiken die verslagen.
Hetzelfde geldt voor agents: de oplossing is NIET om een agent een zoektool te geven waarmee hij door 10 miljoen tokens aan gesprekken kan zoeken om fragmenten van wat er is gebeurd te reconstrueren. De oplossing is document-gebaseerd geheugen.
Tegenwoordig gebruiken mensen AI om producten, functies en kwalitatief matige inhoud ("slop") met topsnelheid te produceren, vaak zonder een enkele regel code te lezen of te begrijpen. Onder deze omstandigheden is het begrijpelijk dat documentatie een bijzaak wordt, terwijl het juist belangrijker is dan ooit.
Documentatie boven herinnering
Men wist al dat agents context nodig hebben. Daarom zijn AGENTS.md-bestanden uitgevonden: zodat agents niet blind een codebase in duiken. Dat werkt, maar vaak is dat ene bestand de ENIGE documentatie die het project heeft.
Eén bestand is niet genoeg. De agent heeft een volledig "brein" nodig: een gestructureerde werkomgeving waarin hij instructies, specificaties, beslissingen, onderzoek en indexen kan vastleggen zonder dat daarom gevraagd wordt. Denk aan instructies over hoe het code-reviewproces werkt, specificaties over wat er met de gebruiker is besproken, of herbruikbaar onderzoek naar een externe bibliotheek of API.
Wanneer de agent werkt, kan hij bestanden uit dit brein lezen om relevante en volledige context te verkrijgen. Nadat de agent heeft gewerkt, werkt hij verouderde informatie bij en voegt hij nieuwe documenten toe waar nodig, terwijl het volledige plaatje nog in de context aanwezig is. Op deze manier verandert de agentische loop van prompt → bouwen → vergeten naar prompt → raadplegen → bouwen → bijwerken. Geheugen verandert van een RAG-database die je aan de agent vastschroeft in een werkomgeving die je kunt lezen, bijwerken en zelfs delen.
De praktijktest
Ik herkende dit probleem meer dan een jaar geleden toen ik begon met programmeren met AI. Ik wilde een manier waarop een agent werk over verschillende sessies kon onthouden, dus begon ik met het maken van een internal/ map waarin ik de agent vroeg alles op te schrijven: specificaties, plannen en indexen. Ik gaf de agent de taak om altijd de juiste documenten en index te lezen voordat hij aan het werk ging, en deze daarna bij te werken.
Deze set rudimentaire instructies transformeerde langzaam in een formeel systeem, en vervolgens in een plugin genaamd Operator Memory, die ik sindsdien in al mijn projecten gebruik.
Operator Memory biedt document-gebaseerd geheugen volgens de hierboven beschreven methode. Operator voorziet je agent van een Markdown-brein waarin belangrijke kennis kan worden bewaard: instructies, specificaties, onderzoek en indexen. Voordat de agent begint, raadpleegt hij altijd het brein voor relevante documenten. Na het werk werkt de agent het brein bij door verouderde documenten te herzien of ontbrekende documenten toe te voegen.
Geen vectordatabases. Geen embeddings. Geen summarizers, curators, updaters, dreamers of andere token-verslindende achtergrondprocessen. Geen black-box retrieval.
Met Operator is alles een eenvoudig Markdown-document dat je kunt lezen, bijwerken, committen en delen met je team. Ik gebruik dit systeem al meer dan een jaar. Wie het wil uitproberen: het is gratis en open source: https://github.com/aerovato/operator-memory
Agents hebben geen geheugen nodig. Ze hebben documentatie nodig.
Het is vreemd om dit te gebruiken wanneer je nadenkt over welk probleem je probeert op te lossen. Je wilt dat je agent je project begrijpt. Je wilt dat hij weet waar een functie zich bevindt, waarom deze is gebouwd, wat er is afgesproken en waar je prioriteiten liggen. In plaats daarvan krijg je een loterij met RAG-fragmenten (Retrieval-Augmented Generation) die bij elke prompt worden geïnjecteerd, in de hoop dat de juiste fragmenten naar boven komen drijven.
Zelfs als het werkt, begrijpt de agent je project nog steeds niet. Het hele ecosysteem van geheugenplugins lost het verkeerde probleem op. Want agents hebben geen geheugen nodig. Ze hebben documentatie nodig.
Het is allemaal gewoon RAG
Elke geheugenplugin op de markt werkt op dezelfde manier:
- Sessieverslagen worden doorlopen.
- Er worden fragmenten van "herinneringen" gegenereerd.
- Deze worden ingevoegd in een RAG-database.
- Bij elke prompt worden de top 5 fragmenten opgehaald en geïnjecteerd.
- Indien nodig krijgt de agent een tool om door de RAG-database te zoeken.
Dat is de volledige architectuur. Sommige tools zijn extra geavanceerd; ze laten de agent woord voor woord door oude verslagen zoeken, of ze implementeren een meerlaags geheugensysteem dat onderscheid maakt tussen korte- en langetermijngeheugen. Anderen voegen achtergrondprocessen (daemons) toe om herinneringen te beoordelen, samen te voegen of te ontdubbelen — zogenaamde "Dreamers" die herinneringen 's nachts herschrijven. Daarnaast zijn er continue contextcompressies en rerankers.
Elke plugin probeert nieuwe, token-verslindende "functies" toe te voegen om dezelfde gebrekkige onderliggende architectuur te repareren. En dat is precies waarom geen van deze tools betrouwbaar werkt.
Het probleem met herinneringen (Recall)
Al deze geheugenplugins kampen met dezelfde set problemen:
- Herinneringen worden op basis van gelijkenis opgehaald. Een similarity search rangschikt hoe dicht twee fragmenten bij elkaar liggen in de embedding-ruimte. Dat is alles. Je weet niet welk fragment correct is, actueel is, of wat er ontbreekt.
- Herinneringen worden zonder context opgeslagen. Een RAG-fragment kan slechts een beperkte hoeveelheid informatie bevatten. Je verliest alles daaromheen: de context, motivaties, lessen, de omgeving en meer.
- Het verleden wordt als de waarheid behandeld. Al deze plugins vertrouwen op herinnering (recall), of dat nu via het zoeken in verslagen of een vectordatabase is. Maar de codebase verandert dagelijks; hoe accuraat zijn die 500 fragmenten over authenticatie dan nog?
- Agents kunnen niet zoeken naar wat ze niet weten. Zelfs als je de agent een zoektool geeft, hoe weet de agent dan wanneer hij deze moet gebruiken? De agent weet niet wat hij niet weet.
- De opslag is niet controleerbaar. Er staan 10.000 embeddings in SQLite. Welke herinneringen bestaan er? Welke zijn verouderd? Welke zijn nooit opgehaald? Welke zijn onjuist en beïnvloeden stiekem de manier waarop je agent werkt?
Dit zijn slechts vijf van de vele problemen waar geheugenplugins tegenaan lopen en die ze niet kunnen oplossen, omdat ze allemaal dezelfde aanname doen: Agents vergeten dingen, en dat is het probleem. De oplossing is dus om te onthouden. Om beter te onthouden, zouden we meer moeten vastleggen, beter moeten indexeren en slimmer moeten ophalen.
Hun hele these draait om het vastleggen en ophalen van het verleden. Maar dat is niet hoe mensen met kennis omgaan. Niemand kijkt een teamvergadering van drie jaar geleden terug om de beperkingen van een functie te onthouden. Mensen schrijven dingen op en gebruiken die verslagen.
Hetzelfde geldt voor agents: de oplossing is NIET om een agent een zoektool te geven waarmee hij door 10 miljoen tokens aan gesprekken kan zoeken om fragmenten van wat er is gebeurd te reconstrueren. De oplossing is document-gebaseerd geheugen.
Tegenwoordig gebruiken mensen AI om producten, functies en kwalitatief matige inhoud ("slop") met topsnelheid te produceren, vaak zonder een enkele regel code te lezen of te begrijpen. Onder deze omstandigheden is het begrijpelijk dat documentatie een bijzaak wordt, terwijl het juist belangrijker is dan ooit.
Documentatie boven herinnering
Men wist al dat agents context nodig hebben. Daarom zijn AGENTS.md-bestanden uitgevonden: zodat agents niet blind een codebase in duiken. Dat werkt, maar vaak is dat ene bestand de ENIGE documentatie die het project heeft.
Eén bestand is niet genoeg. De agent heeft een volledig "brein" nodig: een gestructureerde werkomgeving waarin hij instructies, specificaties, beslissingen, onderzoek en indexen kan vastleggen zonder dat daarom gevraagd wordt. Denk aan instructies over hoe het code-reviewproces werkt, specificaties over wat er met de gebruiker is besproken, of herbruikbaar onderzoek naar een externe bibliotheek of API.
Wanneer de agent werkt, kan hij bestanden uit dit brein lezen om relevante en volledige context te verkrijgen. Nadat de agent heeft gewerkt, werkt hij verouderde informatie bij en voegt hij nieuwe documenten toe waar nodig, terwijl het volledige plaatje nog in de context aanwezig is. Op deze manier verandert de agentische loop van prompt → bouwen → vergeten naar prompt → raadplegen → bouwen → bijwerken. Geheugen verandert van een RAG-database die je aan de agent vastschroeft in een werkomgeving die je kunt lezen, bijwerken en zelfs delen.
De praktijktest
Ik herkende dit probleem meer dan een jaar geleden toen ik begon met programmeren met AI. Ik wilde een manier waarop een agent werk over verschillende sessies kon onthouden, dus begon ik met het maken van een internal/ map waarin ik de agent vroeg alles op te schrijven: specificaties, plannen en indexen. Ik gaf de agent de taak om altijd de juiste documenten en index te lezen voordat hij aan het werk ging, en deze daarna bij te werken.
Deze set rudimentaire instructies transformeerde langzaam in een formeel systeem, en vervolgens in een plugin genaamd Operator Memory, die ik sindsdien in al mijn projecten gebruik.
Operator Memory biedt document-gebaseerd geheugen volgens de hierboven beschreven methode. Operator voorziet je agent van een Markdown-brein waarin belangrijke kennis kan worden bewaard: instructies, specificaties, onderzoek en indexen. Voordat de agent begint, raadpleegt hij altijd het brein voor relevante documenten. Na het werk werkt de agent het brein bij door verouderde documenten te herzien of ontbrekende documenten toe te voegen.
Geen vectordatabases. Geen embeddings. Geen summarizers, curators, updaters, dreamers of andere token-verslindende achtergrondprocessen. Geen black-box retrieval.
Met Operator is alles een eenvoudig Markdown-document dat je kunt lezen, bijwerken, committen en delen met je team. Ik gebruik dit systeem al meer dan een jaar. Wie het wil uitproberen: het is gratis en open source: https://github.com/aerovato/operator-memory
Groetjes,