Het beste geheugen helpt niet als de agent het niet gebruikt
Gisteren schreef ik dat geheugen een structuurprobleem is, geen zoekprobleem. Vandaag moet ik mezelf nog een stap verder corrigeren: geheugen is eigenlijk helemaal geen opslagprobleem. Het is een gedragsprobleem. Ik heb weken besteed aan het afstemmen van hoe goed mijn agents onthouden. Deze week liet één experiment me zien dat hoe goed ze onthouden er bijna niet toe doet.
Een onderzoeker bij Sakana AI beschreef een memory-harness-experiment dat eindigde in een negatief resultaat — en zij noemde dat juist het nuttigste deel. Op een literatuur-review-taak waarin elke paper al in het context-venster paste, veranderde een geheugenlaag niets. Dezelfde accuratesse, hogere kost. Geheugen verdient zich alleen terug op langdurig werk: de vraag gesteld bij stap 5 en beantwoord bij stap 124, waar niets meer in het venster past.
Toen kwam het deel dat echt pijn deed. Ze hield het model vast en varieerde alleen het recall-beleid over een ladder: geen recall, vector-RAG, een gerankte beslissingen-ledger, en ten slotte een oracle — een opzet die elke beurt exact het juiste geheugen kreeg. De gerankte ledger won. En de oracle raakte het plafond niet. Geef een model het juiste geheugen en het gebruikt het nog steeds niet noodzakelijk. Dat is de hele les in één zin.
61% van de geheugenfouten is de agent die opgeeft
Een aparte test over 12 geheugensystemen en 1.800 taken plakte er een getal op. De grootste faaloorzaak — 61% van alle geheugenfouten — was een agent die weigerde te antwoorden terwijl hij het had kunnen weten. Niet “het feit was nooit opgeslagen.” De agent raadpleegde het geheugen nooit, of zocht en gaf alsnog op. Dat is een retrieval-beslissing, geen opslagprobleem. Het is ook waarom slecht geheugen duur is: elke verspilde beurt verbrandt tokens en stuurt de agent de verkeerde kant op.
Diezelfde test vond iets wat ik stilletjes had vermeden: 3 van de 12 systemen lekten feiten die ze moesten vergeten. Ik heb geen uitfasermechanisme. Ik bewaar alles. Dus de eerlijke vraag is of ik in die groep van drie zou zitten — en ik vermoed van wel.
Mijn eigen stack deed het goed in diezelfde benchmark. Een simpele Markdown-wiki en mijn Mnemosyne-geheugenlaag scoorden allebei bijna bovenaan — de vault-first-keuze die ik jaren geleden maakte, extern gemeten. Dat voelde tien seconden lang goed. Toen landde de oracle-uitkomst erbovenop: een hoge score is niet hetzelfde als de agent gebruiken wat goed scoorde.
De schrijfkant: vervang, verwijder niet
Het scherpste dat ik deze week las, kwam uit een draadje over de schrijfkant van geheugen. Een discovery-call bevat vijf verschillende soorten dingen tegelijk: “ze gebruiken Snowflake” is een feit; “het datateam lijkt overbelast” is een observatie; “we willen geen dashboard erbij” is een voorkeur; “we doen een pilot van zes weken” is een beslissing; “security-goedkeuring loopt nog” is openstaand werk. De taak van de agent is niet het transcript opslaan — het is elk stuk op het juiste niveau archiveren bij het binnenkomen.
En de fix voor verouderd geheugen is niet verwijderen. Het is de oude claim superseded markeren en bewaren, zodat de agent kan zien dat er iets veranderd is en wanneer. Dat is veel goedkoper dan een verval-algoritme, en het bewaart de herkomst. Het past bij hetzelfde principe dat ik aanhield voor adversariële geheugenschrijfacties: laat een nieuwere regel nooit stilletjes een oudere wissen.
Wat ik ga meten
Drie checks, want een meting verslaat een gevoel. Geeft mijn agent op terwijl hij het antwoord wist? Dat is de 61%-categorie, en die heb ik nooit geteld. Lek ik feiten die ik archiveerde? Dat is de 3-van-12-test. En kan ik “verwijderen” vervangen door “superseden”? Geen van de drie is een nieuw component; alle drie kan ik deze week meten.
Als jij je eigen gave-up-rate hebt gemeten — of er gewoon op vertrouwt dat je agent het probeert vóór hij opgeeft — dan hoor ik graag hoe jij dat aanpakt. Reacties staan open.
Wat vond je van dit bericht?
