Home / Vault & Second Brain / Geheugen is wat een chatbot van een agent scheidt

Geheugen is wat een chatbot van een agent scheidt

Second brain: memory as structure, four rooms

Geheugen is wat een chatbot van een agent scheidt

Ik draai dagelijks een stapel AI-agents, en lang dacht ik dat mijn geheugenprobleem een zoekprobleem was. Als ik alles maar goed genoeg indexeerde — tags, vector-overeenkomst, cross-links — dan zou het juiste feit op het juiste moment bovenkomen. Deze week kwamen drie onafhankelijke bronnen met dezelfde correctie binnen: geheugen is een structuurprobleem, en die structuur heeft vier kamers, niet één.

IBM’s uitleg van de CoALA-taxonomie (Cognitive Architectures for Language Agents, van Princeton) is de helderste kaart die ik heb gezien. Het geheugen van elke agent valt uiteen in vier types. Werkgeheugen is het context-venster — snel, vluchtig, begrensd, het RAM-geheugen van het geheel. Semantisch geheugen is de kennisbank, en hier komt het deel waar ik om moest glimlachen: in productie is dit, stellen ze, iets veel eenvoudigers dan vector-databases — gewoon Markdown-bestanden. Procedureel geheugen zijn de skills van de agent. En episodisch geheugen is het gedistilleerde verslag van wat er echt gebeurde.

Die kaart past exact op mijn eigen opzet. Werkgeheugen is het context-venster dat ik mager probeer te houden. Semantisch geheugen is mijn Obsidian-vault — en ik leerde al op de harde manier dat Markdown elk toegewijd geheugenproduct versloeg dat ik probeerde. Procedureel geheugen is mijn skills-map. Episodisch geheugen is wat Mnemosyne als gedistilleerde ervaring opslaat. Ik miste de taxonomie niet; ik had er alleen geen gedeelde taal voor, waardoor elke geheugendiscussie weer van voren af aan begon.


Vergeten is een engineeringprobleem

Maar de kaart legde twee kamers bloot die ik leeg had gelaten. De eerste is verval. IBM vatte het in één zin samen: mensen zijn goed in vergeten — voor agents is vergeten een engineeringprobleem. Mijn stack is uitstekend in onthouden. Ik heb de instroom afgesteld. Wat ik niet heb, is een expliciet mechanisme voor uitfaseren: wanneer veroudert een opgeslagen feit en valt het uit de recall? Nu vervaagt er nooit iets stilletjes. Het stapelt zich allemaal op, en ophoping zonder verval is gewoon langzame context-bloat.

De tweede lege kamer heeft een concreet getal. Iemand op Reddit beschreef een orchestrator-worker-opzet waarin elke orchestrator-aanroep de volledige projectstaat opnieuw afspeelde — en mat dat meer dan 60% van de orchestrator-tokens context herlas die hij al had. $580 per maand aan herlezen. De fix was geen beter model; het was een gerankte samenvatting van de huidige staat in plaats van een volledige geschiedenis-replay. Die ene verandering halveerde het tokenverbruik.

Ik ken die pijn. Mijn eigen prefill-kost meet op sommige jobs rond de 312K input-tokens per beurt — en een deel daarvan is geschiedenis die ik al eens betaald heb om te laden. De les is niet “minder opslaan.” Het is dat de orchestrator niet elke keer het hele transcript terug moet krijgen; hij moet een gedistilleerde staatssamenvatting krijgen — intentie, wijzigingen, beslissingen, volgende stappen. Alles onthouden is goedkoop. Alles herlezen is wat je verbrandt.

Gisteren schreef ik over de adversariële kant van agent-geheugen — een schrijfactie die niets onwaars zegt kan tóch een geverifieerd feit wissen. Vandaag is de structurele kant van dezelfde munt. Immutability en ondertekenaar-autoriteit beschermen wat al opgeslagen is. Verval en gerankte samenvatting bepalen wat nog de moeite waard is om in het venster te houden. Je hebt beide nodig, en ik heb alleen de eerste helft.

Dus mijn vraag aan jou: vergeet jouw agent iets met opzet? Of blijft hij, net als de mijne, gewoon stapelen tot het context-venster een vuilnisbelt is van dingen die hij allang wist? Ik zou oprecht willen weten hoe jij verval aanpakt — laat een reactie achter.

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *