Een client uit de financiële sector liet ons ooit een agent zien die eenvoudige vragen uitstekend afhandelde — maar zodra het gesprek langer duurde of ze er de volgende dag op terugkwamen, gedroeg de agent zich alsof ze elkaar nooit hadden ontmoet. Hij vergat de context. Hij vergat de beslissingen waartoe ze waren gekomen. Hij vergat wat de client twee uur eerder over zijn prioriteiten had gezegd. "Het is toch AI — waarom onthoudt hij niets?" was hun gefrustreerde vraag.
Dit is een architectuurkwestie, geen modelkwestie. Het geheugen van een AI-agent is geen automatische eigenschap — het is een ontworpen laag van het systeem. En die laag slecht ontwerpen betekent dat de agent vragen herhaalt, bij elke nieuwe aanroep de context verliest en niet kan leren van eerdere interacties. Dit artikel legt uit hoe het geheugen van een agent werkt, waar de grenzen liggen en hoe u die in de praktijk aanpakt.
Wat is agentgeheugen en waarom is het niet hetzelfde als RAG
Voordat we verdergaan, is het belangrijk twee concepten te onderscheiden die in de praktijk vaak door elkaar worden gehaald: agentgeheugen en RAG (Retrieval-Augmented Generation).
RAG is een mechanisme om kennis op te halen — wanneer een agent een vraag moet beantwoorden, raadpleegt hij een vectordatabase en haalt relevante documenten op (technische documentatie, bedrijfsrichtlijnen, productcatalogi). RAG gaat over toegang tot externe kennis.
Agentgeheugen gaat over de toestand van de agent — wat hij onthoudt uit de lopende interactie, uit de sessiegeschiedenis of over een specifieke gebruiker of entiteit. Geheugen gaat over continuïteit van de conversatie en context.
Het praktische verschil: wanneer een agent vraagt "in welk formaat wilt u de uitvoer?" en u antwoordt "Excel", zou hij dat tot het einde van de sessie moeten onthouden. Dat is geen RAG — dat is het werkgeheugen van de agent. RAG gebruikt u wanneer de agent moet opzoeken welke uitvoerformaten uw systeem ondersteunt.
Verwarring tussen deze twee concepten leidt tot slechte architectuurbeslissingen. Teams implementeren RAG wanneer ze geheugen nodig hebben, of omgekeerd.
De vier lagen van agentgeheugen
In de praktijk onderscheiden we vier afzonderlijke typen geheugen, waarbij elk een ander probleem oplost:
1. In-context geheugen (short-term)
Dit is het primaire werkgeheugen van de agent — de gespreksgeschiedenis die zich rechtstreeks in het contextvenster van het model bevindt. De agent "ziet" de volledige gespreksgeschiedenis als onderdeel van de invoer.
De voordelen zijn voor de hand liggend: nul latency bij toegang, de agent "ziet" altijd wat er gezegd is, eenvoudig te implementeren.
De beperkingen zijn even duidelijk:
- De context is niet oneindig. De meeste productiemodellen hebben een context van 128k–1M tokens, maar dat betekent niet dat de agent informatie aan het begin en het einde van een lang gesprek even goed verwerkt.
- Het "lost in the middle"-effect — een bewezen fenomeen: het model besteedt minder aandacht aan informatie in het midden van een lange context. Een lange geschiedenis garandeert geen betrouwbare verwerking van de volledige geschiedenis.
- De kosten groeien lineair met de lengte van het gesprek — elk token in de geschiedenis wordt opnieuw meegestuurd bij elke volgende aanroep.
- Het geheugen verdwijnt na het beëindigen van de sessie. In-context geheugen is vluchtig — bij een nieuw gesprek is de agent een schone lei.
In-context geheugen is uitstekend voor korte, gesloten interacties. Voor lange of persistente scenario's volstaat het niet alleen.
2. Extern (long-term) geheugen
Wanneer een interactie een enkele sessie of het contextvenster overstijgt, is extern geheugen nodig — een persistent opslagmedium waarnaar de agent schrijft en waaruit hij leest.
Meest voorkomende implementaties:
- Vectordatabase (bijv.
Qdrant,pgvector) — de agent slaat sleutelfeitjes of volledige gesprekssfragmenten op als vectoren. Bij een volgende sessie haalt hij deze op via semantisch zoeken. Dit lijkt op RAG, maar dan voor geheugengeschiedenis in plaats van een kennisbank. - Relationele database / key-value store — voor gestructureerde feiten over entiteiten (gebruiker prefereert Nederlands, werkt op afdeling X, heeft rol Y). Snel en deterministisch.
- Episodisch geheugen — registraties van eerdere interacties opgeslagen als "wat er in sessie Z is gebeurd" — de agent kan deze ophalen, ervan leren of ernaar verwijzen.
Het essentiële verschil met RAG over een kennisbank: in extern geheugen schrijft de agent zelf — het is zijn eigen toestand, geen extern document.
Extern geheugen brengt eigen uitdagingen mee: wanneer te schrijven (na elke uitwisseling? aan het einde van de sessie?), wat het bewaren waard is en wat niet, en hoe conflicterende of verouderde records te verwerken.
3. Samenvatting geheugen
Voor lange gesprekken is doorlopende samenvatting een praktische oplossing. In plaats van de volledige geschiedenis te bewaren, comprimeert de agent (of een afzonderlijke summarizer-stap) periodiek oudere gespreksonderdelen tot een beknopte samenvatting.
Typisch implementatiepatroon in LangGraph:
- Houd de laatste N berichten volledig in de context (bijv. de laatste 20 uitwisselingen)
- Comprimeer alles ouder tot 2–3 alinea's samenvatting
- De samenvatting staat aan het begin van de context als "stand van zaken tot nu toe"
Voordelen: de context blijft beheersbaar, de kosten groeien niet onbeperkt, de agent heeft nog steeds toegang tot de essentie van eerdere gesprekken.
Nadelen: samenvatting gaat gepaard met informatieverlies — details kunnen verdwijnen. Bij juridische of compliance-scenario's waar de exacte formulering telt, is dit een risico. Bij technische gesprekken waar één specifieke configuratieparameter een uur geleden werd genoemd, kan de samenvatting die weglaten.
4. Werkgeheugen (procedureel / toestandsgeheugen)
Dit is de meest over het hoofd geziene laag. Werkgeheugen is de gestructureerde toestand die de agent bijhoudt tijdens het uitvoeren van een taak — niet de conversatie, maar de *operationele context*.
Voorbeelden: - De lijst met stappen die de agent heeft voltooid en die nog wachten - Tussenresultaten van tool-aanroepen - Beslissingen genomen in eerdere stappen (bijv. "we hebben gekozen voor XML-formaat") - De toestand van een multi-step pipeline (in welke fase we zijn)
In LangGraph wordt werkgeheugen op natuurlijke wijze afgebeeld op de State van de graaf — elk knooppunt leest en schrijft naar een gedeeld state-object. Dit is een van de belangrijkste voordelen van expliciet state management ten opzichte van eenvoudigere frameworks.
Werkgeheugen is kritisch voor agents die lange pipeline-taken uitvoeren — zonder dit "vergeet" de agent wat hij in eerdere stappen heeft gedaan en kan hij werk dupliceren of zichzelf tegenspreken.
Hoe deze lagen samenwerken
In de praktijk combineert een productieagent alle vier lagen. Hoe ziet dat eruit aan de hand van een voorbeeld van een agent voor technische ondersteuning bij een productiebedrijf:
- 1.De gebruiker opent een nieuwe sessie → de agent laadt uit extern geheugen (vectordatabase) relevante informatie over deze klant: zijn machines, eerdere tickets, voorkeurcontact. Dit gaat aan het begin van de context.
- 1.Tijdens het gesprek → de volledige berichtengeschiedenis is in-context. De agent houdt werkgeheugen bij: "de klant beschreef een probleem met motor M3, ik heb al stap A en B gecontroleerd, ik wacht op de uitvoer van het diagnostische gereedschap."
- 1.Het gesprek overstijgt 20 uitwisselingen → de samenvattingsstap comprimeert oudere onderdelen. Sleutelfeiten (machinetype, serienummer, probleembeschrijving) worden geëxtraheerd en opgeslagen in de samenvatting.
- 1.De sessie wordt beëindigd → de agent schrijft naar extern geheugen: "ticket #1234, klant X, probleem Y, oplossing Z, tevredenheid 4/5". Dit is beschikbaar bij de volgende opening.
- 1.Een week later schrijft de klant opnieuw → de cyclus herhaalt zich, maar nu met de geschiedenis als basis.
Dit is geen sciencefiction — het is een standaard productiearchitectuur die wij voor klanten implementeren. De complexiteit zit niet in de technologie, maar in de beslissing wat op te slaan, wanneer en in welk formaat.
Ontwerp van extern geheugen: wat opslaan en wat niet
Een van de meest voorkomende problemen bij de uitrol van agents met langetermijngeheugen is geheugenexplosie — de agent slaat te veel op, de relevantie van de records daalt, en bij het ophalen krijgt hij irrelevante ruis terug.
Een aantal richtlijnen die in de praktijk werken:
- Sla feiten op, niet tekst. In plaats van een volledige alinea van het gesprek slaat de agent een geëxtraheerd feit op:
{"user_id": "X", "preference": "output_format: Excel", "confidence": "explicit"}. Een gestructureerd feit is makkelijker te zoeken, makkelijker te updaten en neemt minder ruimte in.
- Onderscheid duurzaamheid. Sommige informatie is permanent (klant heeft Siemens-machines), andere is tijdelijk (in deze sessie lossen we een specifiek storing op). Deze moeten in afzonderlijke opslagplaatsen staan met een verschillende TTL (time-to-live).
- Geheugen heeft versiebeheer. Wanneer een klant een voorkeur wijzigt, mag de oude waarde niet worden overschreven — ze moet worden gearchiveerd met een tijdstempel. Dit is belangrijk voor auditbaarheid.
- Expliciet versus impliciet geheugen. Wanneer een gebruiker expliciet zegt "onthoud dat...", is dat ondubbelzinnig. Wanneer de agent uit de context afleidt (de klant heeft driemaal naar hetzelfde onderwerp gevraagd → het is waarschijnlijk een prioriteit), is dat impliciet geheugen — minder betrouwbaar, vereist een hogere mate van vertrouwen.
Wanneer een lange context niet volstaat
Het lijkt misschien alsof de geheugenproblematiek is opgelost met modellen met een miljoencontext — zet gewoon de volledige geschiedenis erin. In de praktijk werkt dat niet zo eenvoudig.
Ten eerste, het "lost in the middle"-effect — het model besteedt onevenredig weinig aandacht aan informatie in het midden van een lange context. Een cruciaal feit uit het begin van een lang gesprek kan de facto onzichtbaar zijn.
Ten tweede, het kostenaspect — de volledige geschiedenis wordt bij elke aanroep meegestuurd. Voor een gesprek met duizenden uitwisselingen is dat onnodige token-overhead die rechtstreeks van invloed is op de kosten van een agent in productie.
Ten derde, schaalbaarheid — een systeem met 10.000 actieve agents waarbij elk de volledige geschiedenis in de context houdt, is niet realistisch. Persistent extern geheugen maakt schaling mogelijk, omdat de toestand buiten het proces staat.
Ten vierde, multi-sessiecontinuïteit — het contextvenster wordt altijd gereset bij een nieuwe sessie. Zonder extern geheugen is elk nieuw gesprek een schone lei, ongeacht hoe vaak de klant eerder contact heeft opgenomen.
Een lange context is een krachtig hulpmiddel — maar het is een hulpmiddel voor de verwerking van lange documenten en complexe eenmalige taken, geen vervanging voor een ontworpen geheugenarchitectuur.
Samenvatting versus selectieve opslag: waar ligt de grens
De twee belangrijkste strategieën voor het beheer van lange gespreksgeschiedenissen zijn samenvatting en selectieve opslag van sleutelfeiten. Beide hebben hun plaats.
Samenvatting is geschikt wanneer: - Het gesprek narratief en contextueel is en moeilijk te structureren valt - De relaties en gedachtestroom belangrijk zijn, niet geïsoleerde feiten - Implementatiesnelheid een prioriteit is
Selectieve opslag van feiten is geschikt wanneer: - Het gesprek duidelijk identificeerbare entiteiten en attributen bevat - Feiten later moeten worden gezocht, bijgewerkt of geaggregeerd - Auditbaarheid een vereiste is (financiën, compliance)
In productiesystemen combineren we doorgaans beide: samenvatting voor het "verhaal" van de sessie, gestructureerde feiten voor entiteiten en beslissingen.
Een directe koppeling aan hoe een agent toestand bewaart tussen stappen vindt u in het artikel over AI-agentarchitecturen — met name in de sectie over checkpointing in LangGraph.
Technische implementatie: LangGraph als referentiepatroon
Voor productie-uitrol bevelen we LangGraph aan als referentieraamwerk voor geheugenpatronen — niet omdat het "trendy" is, maar omdat het toestand expliciet modelleert als een eersteklas burger van de architectuur.
Kernconcepten in de context van geheugen:
- State schema — u definieert wat er in het werkgeheugen van de agent zit: welke velden, welke typen, welke standaardwaarden. Dit elimineert verborgen globale toestanden.
- Checkpointing — LangGraph ondersteunt native het opslaan van de graaftoestand in persistent opslag (SQLite, PostgreSQL). Dit maakt hervatten na onderbreking, HITL (human-in-the-loop interrupt) en post-mortem debugging mogelijk.
- Memory store — nieuwere versies van LangGraph bevatten een toegewijd memory store voor cross-thread geheugen (gedeeld tussen verschillende gesprekken van dezelfde gebruiker).
Checkpointing in LangGraph is ook de basistechniek voor human-in-the-loop bij agents — de agent stopt vóór een kritieke actie, de toestand wordt opgeslagen, en na menselijke goedkeuring gaat hij verder vanaf exact hetzelfde punt.
Alternatief: mem0 is een toegewijde open-source bibliotheek voor agentgeheugen die een abstractie biedt over verschillende opslagmedia (vectordatabase, KV store, graaf). Geschikt als u niet aan één framework gebonden wilt zijn.
Beveiligingsaspecten van agentgeheugen
Dit komt zelden ter sprake in discussies over agentgeheugen, maar het is kritisch: agentgeheugen is een aanvalsoppervlak.
Als een agent geheugen ophaalt uit een extern opslagmedium en het in de context invoegt, kan een aanvaller met toegang tot dat opslagmedium schadelijke instructies injecteren die stille onderdelen van elke toekomstige sessie worden. Dit is een variant van een prompt injection-aanval — en gevaarlijker dan directe injectie, omdat het afkomstig is van een vertrouwde interne bron.
Praktische maatregelen:
- Geheugenrecords moeten worden gesanitiseerd voordat ze in de context worden ingevoegd
- Maak onderscheid tussen vertrouwd geheugen (door het systeem geschreven) en onvertrouwd (door de klant of een externe dienst)
- Log wat de agent uit het geheugen heeft opgehaald — dit is onderdeel van observability voor AI-agents
- Overweeg bij high-risk agents (financiële transacties, toegang tot systemen) geheugen met een expliciet human review vóór activering
Veelgestelde vragen
Is RAG hetzelfde als agentgeheugen?
Nee. RAG is een mechanisme om kennis op te halen uit een externe kennisbank — zoals bedrijfsdocumentatie of een productendatabase. Agentgeheugen gaat over de toestand van de agent zelf: wat hij onthoudt uit het gesprek, over de gebruiker of over eerdere interacties. In de architectuur zijn dit twee afzonderlijke lagen, hoewel beide technisch een vectordatabase kunnen gebruiken voor opslag.
Volstaat een lang contextvenster als vervanging voor extern geheugen?
Voor eenmalige, gesloten taken wel — een model met een miljoencontext kan ook zeer lange documenten verwerken. Voor multi-sessie-agents met geschiedenis, voor schaalbare systemen of voor scenario's waarbij de agent feiten moet onthouden over dagen en weken, volstaat een lange context niet. Bovendien beperkt het "lost in the middle"-effect de betrouwbaarheid bij zeer lange invoer.
Hoe voorkom ik dat een agent een belangrijke informatie uit een lang gesprek vergeet?
Door drie maatregelen te combineren: (1) samenvatting van de geschiedenis met expliciete extractie van sleutelfeiten in gestructureerd formaat, (2) opslag van feiten in extern geheugen zodra ze worden geïdentificeerd (niet aan het einde van de sessie), (3) werkgeheugen als expliciet state-object in de graafagent, waarbij belangrijke beslissingen direct als velden worden opgeslagen — niet verborgen in de gespreksttekst.
Hoeveel kost extern agentgeheugen extra?
De directe kosten zijn laag — een vectordatabase als Qdrant is open-source en een betaalbare server is voldoende voor typische volumes (honderdduizenden records). De grotere kostenimpact zit in retrieval-latency (voegt 50–200 ms per query toe) en ontwikkelaarstijd voor het correct ontwerpen van het geheugeschema. Slecht geheugenbeheer (alles opslaan in plaats van selectief) kan de tokenkosten bij ophalen verhogen — de relevantie van een record heeft directe invloed op hoeveel tokens er terug in de context worden geladen.
Wat is de meest voorkomende fout bij de implementatie van agentgeheugen?
Uit de praktijk: vergeten te samenvatten en op te ruimen. Teams implementeren schrijven naar geheugen, maar lossen niet op wat er gebeurt als het geheugen volloopt met irrelevante records of verouderde feiten. Na enkele weken haalt de agent ruis op die de kwaliteit van zijn antwoorden verlaagt. De geheugenlaag heeft even goed doordachte "vergeetstrategie" nodig als opslagstrategie.
*Geheugenarchitectuur is een van die systeemlagen die het vaakst worden onderschat in de prototypefase — en waarvoor de prijs wordt betaald bij het schalen naar productie. Als u een agent ontwerpt die in een echte omgeving met echte gebruikers moet werken over dagen en weken heen, bespreken we graag welke geheugenlaag zinvol is voor uw specifieke geval.*