Een jaar lang behandelde ik het geheugen van mijn AI als een zoekprobleem. Meer opslaan, beter indexeren, en het juiste feit zou vanzelf bovenkomen als ik vroeg. Dat gebeurde niet. De dag dat het kwartje viel was toen ik las over iemand die een jaar lang agent-memory op knowledge graphs bouwde en het terugbracht tot één harde zin: behandel geheugen niet als een retrieval-probleem, maar als een data-modeling-probleem. Die herformulering legde bloot wat ik al die tijd fout deed.
Denk eens na over wat er écht misgaat. Je agent heeft een feit over een persoon, een project, een voorkeur — maar dat feit leeft op vijf plekken met vijf niveaus van versheid. Als dezelfde keywords alle vijf matchen, wint het verouderde feit keer op keer. Je verbetert de retrieval en het foute antwoord blijft bovendrijven, want de data eronder is nooit gemodelleerd: geen relatie tussen de persoon en het project, geen idee welk feit welk vervangt, geen categorie die je vertelt wat voor soort ding je eigenlijk bekijkt.
Geheugen faalt bij schaal, niet bij de start
In het begin werkt een platte stapel notities prima. Dan groeit de stapel, en blazen bestandszoekopdrachten je context op. Semantische search helpt een beetje, maar kan nog steeds niet de relaties doorlopen tussen personen, onderwerpen, projecten en voorkeuren. Dat was de muur waar ik telkens tegenaan liep. De fix was geen betere zoektool — het was van tevoren beslissen welke categorieën van dingen ik überhaupt onthoud, en hoe ze verbonden zijn.
Het mooiste startpunt dat ik vond is de POLE+O-ontologie: Persoon, Object, Locatie, Event, Organisatie. Begin met die vijf en voeg alleen een categorie toe als je écht tegen een gat aanloopt. Overdesign de ontologie niet op dag één — dat bevriest projecten maandenlang. Behandel de ontologie als een ontdekkingslus: definieer een minimum, draai het, en breid uit alleen wanneer de werkelijkheid het afdwingt.
Persistente state en recovery verslaan modelkracht
In dezelfde week dat ik over de knowledge-graph-bouwer’s fouten las, zag ik NVIDIA’s AVO agent-harness Claude Opus 5 tillen van 30% naar 100% op de publieke ARC-AGI-3-set — met hetzelfde model. Iedereen noemde de score. De bruikbare les was waarom: persistente state, tool feedback en recovery bepalen of een agent zijn werk afmaakt. Niet het model. De harness.
Dat is precies wat ik zelf ervaar met mijn eigen agents. De winsten komen uit de lagen om het model heen — een geheugen dat state bewaart tussen sessies, een manier om na een tool-fout door te gaan in plaats van op te geven, een graph die me vertelt welk feit actueel is. Wanneer ik geheugen behandel als een data-modeling-probleem met die eigenschappen ingebouwd, maken mijn agents meer werk af met minder tussenkomst. Het model was nooit de bottleneck.
De vraag waar ik op terug blijf komen
Als je het geheugen van je agent morgen zou modelleren als vijf entiteitstypes en een handvol relaties, waar zou je dan beginnen? Welke feiten in jouw opzet worden nu gewoon gezocht terwijl ze gerelateerd zouden moeten zijn — en is het stale-feit-probleem een retrieval-probleem, of een data-modeling-probleem in vermmomming?
Reacties zijn open — ik hoor graag hoe je het geheugen van jouw agent structureert, of je dezelfde muur hebt geraakt als ik.
Wat vond je van dit bericht?
