Kort antwoord
LLM memory in n8n is geen simpel aan/uit-vinkje. Je kiest bewust tussen context window, chat memory, Redis/Postgres/MongoDB memory en retrieval. De juiste keuze hangt af van sessieduur, privacy, kosten en hoeveel de agent echt moet onthouden.
Waarom memory snel rommelig wordt
Veel agent-workflows beginnen met "onthoud het gesprek". Dat klinkt logisch, maar in productie wordt memory een ontwerpkeuze. Bewaar je alles, dan stijgen kosten en ruis. Bewaar je te weinig, dan voelt de agent dom en herhaalt hij vragen. Bewaar je gevoelige data zonder beleid, dan maak je van memory een compliance-risico.
n8n ondersteunt verschillende memory-routes via LangChain-subnodes, waaronder Simple Memory en Redis Chat Memory. De vraag is niet welke node het modernst is, maar welke geheugenlaag bij je use case past.
Welke memory kies je?
| Type | Past bij | Let op |
|---|---|---|
| Context window | Korte gesprekken of een enkele taak. | Wordt duur en rommelig bij lange sessies. |
| Simple Memory | Prototype of lichte chatflow. | Niet bedoeld als robuuste enterprise datastore. |
| Redis/Postgres/MongoDB memory | Persistente sessies en schaalbare chatagents. | Gebruik duidelijke session keys en TTL. |
| Retrieval/RAG | Kennis ophalen uit documenten of tickets. | Dit is kenniscontext, geen persoonlijke herinnering. |
Drie regels voor betrouwbare memory
- Maak session keys expliciet. Gebruik klant-, gebruiker- of gesprek-ID's bewust, zodat memories niet mengen.
- Zet TTL waar dat kan. Niet elke herinnering hoeft maanden te blijven bestaan.
- Scheid facts van gespreksruis. Laat een agent niet elke losse zin opslaan als permanente waarheid.
Voorbeeld: supportagent met geheugen
Een supportagent kan de laatste interacties in Redis bewaren, maar productdocumentatie via retrieval ophalen. Dat voorkomt dat de agent oude chatruis verwart met actuele kennis. Voeg daarna een human-in-the-loop stap toe voor refund, opzegging of accountwijziging.
Interne route
Lees ook n8n AI Agents, Multi-Domain RAG met n8n en credentials veilig beheren.
Memory is niet hetzelfde als RAG
Een veelgemaakte fout is om elke vorm van context "memory" te noemen. RAG haalt kennis op uit documenten of databases. Chat memory bewaart gesprekscontext. Profielmemory bewaart stabiele voorkeuren of feiten over een gebruiker. Die drie door elkaar gebruiken maakt agents onvoorspelbaar.
In n8n kun je deze lagen juist netjes scheiden. Laat retrieval productkennis ophalen, Redis of Postgres recente gesprekshistorie bewaren en een aparte datastore alleen bevestigde klantvoorkeuren opslaan.
Voorbeeld: sales intake agent
Een sales intake agent hoeft niet elk woord te onthouden. Hij moet weten wie de lead is, welk probleem is genoemd, welke tools al gebruikt worden en wat de volgende stap is. Dat zijn samenvatbare feiten. Bewaar daarom niet het hele gesprek als permanente waarheid, maar laat de workflow na elke sessie een korte, gestructureerde samenvatting maken.
Bij het volgende gesprek haalt de agent alleen die samenvatting en relevante CRM-context op. Dat houdt de prompt korter en verkleint de kans dat oude ruis het antwoord stuurt.
Session keys en TTL in gewone taal
De session key bepaalt welk geheugen bij welk gesprek hoort. Gebruik je een te algemene key, dan kunnen gesprekken mengen. Gebruik je elke keer een nieuwe key, dan is er effectief geen geheugen. Kies daarom bewust: per gebruiker, per klantaccount, per ticket of per chatkanaal.
TTL bepaalt hoe lang memory blijft bestaan. Voor supportchat kan 7 of 30 dagen genoeg zijn. Voor een persoonlijke assistent kan langer logisch zijn, maar dan moet je ook kunnen uitleggen welke data bewaard blijft en hoe iemand die laat verwijderen.
Risico's die je vooraf moet oplossen
- Privacy: sla geen gevoelige data op zonder noodzaak.
- Veroudering: oude voorkeuren kunnen fout worden. Voeg een manier toe om memory te corrigeren.
- Ruis: niet elke chatregel is een feit.
- Debugging: log welke memory is opgehaald, anders kun je foute antwoorden moeilijk verklaren.
Wanneer Redis of Postgres logischer is
Redis past goed bij snelle sessiegeheugenflows waar TTL en performance belangrijk zijn. Postgres past beter wanneer je memory wilt combineren met relationele data, rapportage of langere bewaartermijnen. MongoDB kan prettig zijn voor flexibele documenten, maar vraagt net zo goed duidelijke datamodellen.
Kies dus niet op populariteit van de node, maar op operationele behoefte: snelheid, bewaartermijn, querybaarheid, beheer en compliance.