Donner une mémoire long terme à un agent IA n8n (Postgres, vector store)

Un agent IA n8n équipé d'un Window Buffer Memory tient une conversation correcte pendant dix échanges, puis oublie. Il oublie aussi tout au redémarrage de l'instance, et il n'a jamais su qui était l'utilisateur d'hier. Pour un chatbot jetable, c'est acceptable ; pour un assistant support qui suit des clients dans la durée, c'est rédhibitoire. Cet article complète notre guide sur la mémoire de conversation d'un agent IA — qui couvre la mémoire courte de session — en s'attaquant à l'étage supérieur : persister l'historique dans PostgreSQL et construire une mémoire sémantique long terme dans une base vectorielle. Le tout avec les questions de purge et de RGPD que la persistance rend inévitables.

Ce que le Window Buffer Memory ne peut pas faire

Le node Simple Memory (Window Buffer Memory) branché sur un node AI Agent rejoue les N derniers échanges de la session dans le contexte du modèle. Deux limites structurelles :

• Volatile : l'historique vit dans la mémoire du processus n8n. Redémarrage, mise à jour, crash — tout est perdu, sans erreur ni avertissement. L'agent repart simplement de zéro.
• Borné : la fenêtre garde N échanges, point. Au onzième message d'une fenêtre de dix, le premier échange disparaît du contexte. Ce que l'utilisateur a expliqué au début d'une longue conversation n'existe plus pour l'agent.

Ces limites sont un choix de conception, pas un défaut : la fenêtre glissante maintient le contexte court et le coût par appel prévisible. Le problème n'est pas la fenêtre, c'est de n'avoir que la fenêtre.

Ce constat rejoint le point de départ de l'étude de Packer et al. publiée en 2023, « MemGPT: Towards LLMs as Operating Systems » (Google Scholar) : la fenêtre de contexte d'un LLM étant structurellement limitée, les auteurs proposent de la traiter comme la mémoire vive d'un système d'exploitation — une ressource rare dans laquelle un mécanisme de gestion fait entrer et sortir des informations depuis un stockage externe, exactement comme un OS pagine entre RAM et disque. C'est l'architecture qu'on reproduit en pratique avec n8n : un contexte court géré par la mémoire de session, adossé à un stockage persistant qu'on interroge à la demande.

Étape 1 — Persister l'historique avec Postgres Chat Memory

Le remplacement le plus simple du Window Buffer est le node Postgres Chat Memory : branché sur la même entrée Memory de l'agent, il écrit chaque échange dans une table PostgreSQL et recharge l'historique de la session à chaque exécution. Concrètement :

• L'historique survit aux redémarrages : l'agent reprend une conversation là où elle s'était arrêtée, même après une mise à jour de l'instance.
• L'historique est inspectable : une simple requête SQL montre ce que l'agent a vu, précieux pour déboguer une réponse étrange.
• La base peut être la même instance PostgreSQL que celle de n8n, ou une base dédiée — par exemple votre projet Supabase, dont la connexion est détaillée dans notre guide pour connecter n8n à Supabase.

Le choix décisif : la clé de session

Le paramètre le plus important n'est pas la connexion à la base, c'est la Session Key : l'identifiant qui regroupe les messages d'une même conversation. Quelques choix éprouvés selon le canal :

• Chatbot Telegram / WhatsApp : le chat_id du message entrant — stable, unique par utilisateur, fourni par la plateforme.
• Assistant email : l'adresse de l'expéditeur, éventuellement normalisée (minuscules, suppression des alias).
• Application interne : l'identifiant utilisateur de votre système d'authentification, passé dans le payload du webhook.

Deux erreurs classiques : une clé trop large (un identifiant de canal partagé) fait lire à l'agent les conversations de tout le monde mélangées ; une clé instable (un identifiant d'exécution, un timestamp) crée une session neuve à chaque message, ce qui revient à ne pas avoir de mémoire du tout. Testez explicitement le cas « deux utilisateurs écrivent en même temps » avant la mise en production.

Étape 2 — La mémoire sémantique : des faits, pas des transcriptions

Persister l'historique ne suffit pas : rejouer six mois de conversations dans le contexte est impossible, et l'essentiel s'y noierait. La deuxième couche consiste à stocker des faits distillés — préférences, contexte, décisions — et à ne rappeler que les pertinents. C'est précisément le mécanisme validé par Park et al. dans « Generative Agents: Interactive Simulacra of Human Behavior » (Google Scholar), présenté à UIST 2023 : leurs agents consignent leurs expériences dans un flux de mémoire persistant, puis récupèrent au moment d'agir les souvenirs les mieux classés selon leur pertinence, leur récence et leur importance — et l'ablation de cette mémoire dégrade nettement la crédibilité du comportement.

Transposé dans n8n avec Supabase et pgvector :

• Écriture : en fin de conversation (ou sur détection d'un fait notable), un node LLM extrait les faits durables — « préfère être contacté le matin », « client sur l'offre Pro depuis 2024 », « a déjà signalé le bug X » — puis chaque fait est vectorisé via un node d'embeddings et inséré dans une table pgvector avec l'identifiant utilisateur et un horodatage.
• Rappel : au début de chaque nouvelle conversation, une recherche par similarité entre le message entrant et les faits de cet utilisateur remonte les 3 à 5 plus pertinents, injectés dans le system message (« Contexte connu sur cet utilisateur : … »). Alternative plus agentique : exposer la recherche comme un outil que l'agent appelle quand il en a besoin, sur le modèle de nos outils personnalisés.

La mécanique embeddings + pgvector + recherche par similarité est la même que pour un RAG documentaire — notre guide RAG avec n8n et Supabase la détaille pas à pas, et le workflow chatbot RAG avec citations en montre une implémentation complète. La différence est le contenu indexé : des faits par utilisateur plutôt que des documents partagés.

Deux garde-fous à l'écriture : dédupliquer (vérifier par similarité qu'un fait équivalent n'existe pas déjà) et horodater pour pouvoir arbitrer les contradictions — un fait récent prime sur un ancien.

Purge et RGPD : la mémoire est une donnée personnelle

Dès que la mémoire contient des données personnelles — et un historique de conversation en contient presque toujours — elle entre dans le champ du RGPD. Trois obligations à câbler dès la conception :

• Limitation de conservation : une purge planifiée (un Schedule Trigger et une requête DELETE sur les lignes plus anciennes que votre durée de rétention) plutôt qu'une accumulation indéfinie.
• Droit à l'effacement : pouvoir supprimer toutes les lignes — historique et faits vectorisés — liées à une clé de session donnée. Notre guide sur le traitement des demandes RGPD avec n8n montre comment industrialiser ce type de demande.
• Minimisation : ne pas stocker de données sensibles dans les faits mémorisés ; l'extraction par LLM doit être instruite d'ignorer santé, opinions, coordonnées bancaires.

Un point souvent oublié : les faits distillés sont des données personnelles au même titre que les transcriptions. La purge doit couvrir les deux tables.

Quand ne pas donner de mémoire longue

La mémoire persistante a un coût — infrastructure, complexité, surface RGPD — qui ne se justifie pas toujours :

• Interactions ponctuelles : un formulaire de qualification, une FAQ, un traitement de document n'ont rien à retenir d'une fois sur l'autre.
• Contexte déjà disponible ailleurs : si votre CRM contient déjà l'historique client, un outil qui l'interroge en direct vaut mieux qu'une copie vectorisée qui se désynchronise.
• Risque de mémorisation erronée : un fait mal extrait (« préfère le paiement annuel » déduit d'une question) resurgira avec l'aplomb d'une certitude. Sur des sujets à enjeu, mieux vaut pas de mémoire que de la mémoire fausse.

La progression raisonnable : Window Buffer pour prototyper, Postgres Chat Memory dès que l'agent touche de vrais utilisateurs, mémoire sémantique seulement quand un besoin concret de personnalisation inter-sessions est démontré.

Passer à la pratique

L'architecture complète — agent, mémoire de session, base vectorielle Supabase interrogée par similarité — est exactement celle du Pack Assistant RAG (119 €) : les workflows livrés fournissent la partie embeddings, stockage pgvector et rappel, qu'il suffit d'orienter vers des faits utilisateurs plutôt que des documents pour obtenir la mémoire long terme décrite ici. En le combinant avec la mémoire de conversation pour le fil court et une purge RGPD planifiée, l'agent gagne ce qui manque à la plupart des chatbots : la capacité de se souvenir de la bonne chose, au bon moment, sans garder tout le reste.