Consolider la mémoire d'un agent IA n8n : du fil de conversation aux faits durables

Votre agent IA n8n tourne depuis trois mois avec un Postgres Chat Memory, et la table n8n_chat_histories pèse déjà des centaines de milliers de lignes. Chaque nouvelle conversation rejoue une fenêtre d'échanges facturée en tokens, le contexte se dilue, la latence monte — et malgré tout ce stockage, l'agent ne « sait » toujours rien : la fenêtre courte oublie, et l'historique complet est trop volumineux pour être rejoué. Nos guides précédents couvrent le branchement d'une mémoire de session et le choix d'un stockage persistant. Cet article traite de l'étape que presque tout le monde saute : le processus de consolidation — transformer périodiquement l'historique brut en connaissances compactes, durables et réutilisables.

Le problème : un historique qui gonfle n'est pas une mémoire

Persister les conversations dans PostgreSQL résout la volatilité, pas l'accumulation. Trois symptômes apparaissent à mesure que la table grossit :

• Coût en tokens : la fenêtre de contexte rejoue les N derniers échanges à chaque appel ; sur des conversations longues et fréquentes, c'est le premier poste de dépense de l'agent.
• Contexte dilué : l'information décisive (« le client a résilié l'offre Pro en mai ») se noie au milieu de politesses et de digressions. Le modèle la voit, mais ne la pondère plus.
• Amnésie inter-sessions : la fenêtre ne couvre qu'une session. Ce que l'utilisateur a expliqué il y a trois semaines n'existe plus, alors même qu'il dort dans la table.

Stocker plus ne résout rien : il faut stocker autrement. Une transcription est un enregistrement ; une mémoire est une sélection.

Le principe : faire ce que le cerveau fait pendant le sommeil

La consolidation mnésique est un mécanisme biologique bien documenté. La revue de référence de Susanne Diekelmann et Jan Born, « The memory function of sleep », publiée en 2010 dans Nature Reviews Neuroscience (Google Scholar), montre que pendant le sommeil lent, le cerveau rejoue les expériences de la journée stockées temporairement dans l'hippocampe, en redistribue l'essentiel vers le néocortex sous forme plus abstraite, et laisse le reste s'effacer. Rejouer, résumer, ne garder que ce qui compte : c'est exactement le pipeline à construire.

Le parallèle n'est pas qu'une image. L'étude de Wanjun Zhong et ses co-auteurs présentée à AAAI 2024, « MemoryBank: Enhancing Large Language Models with Long-Term Memory » (Google Scholar), applique ce schéma à un chatbot LLM : les dialogues sont condensés en résumés quotidiens puis en un portrait durable de l'utilisateur, et un mécanisme d'oubli inspiré de la courbe d'Ebbinghaus laisse s'estomper les souvenirs ni rappelés ni renforcés. Résultat : un compagnon conversationnel qui reste cohérent sur la durée sans rejouer des mois de transcriptions.

L'architecture n8n : deux workflows, deux rythmes

Workflow 1 — l'agent, inchangé ou presque

L'agent conversationnel garde sa mémoire de session courte (fenêtre de 10-15 échanges) pour le fil du dialogue. On lui ajoute un accès aux faits consolidés — soit injectés dans le system prompt (voir plus bas), soit exposés comme un outil de rappel qu'il appelle quand il en a besoin. Rien d'autre ne change : la consolidation est invisible côté conversation.

Workflow 2 — la consolidation nocturne

Un second workflow, déclenché chaque nuit par un Schedule Trigger (3 h du matin, heure creuse), déroule cinq étapes :

1. Lire les sessions de la veille : une requête sur la table de chat memory, groupée par clé de session, filtrée sur les conversations closes (aucun message depuis quelques heures).
2. Résumer chaque session : un appel LLM par session produit un résumé de 3-5 phrases orienté décision — qui, quoi, issue. Sur ce point, les techniques de notre guide pour résumer des documents longs s'appliquent telles quelles.
3. Extraire des faits structurés : un node Information Extractor (ou un LLM avec Structured Output Parser) transforme le résumé en faits typés : préférences, décisions, informations client.
4. Dédupliquer et mettre à jour : avant insertion, vérifier si un fait équivalent existe pour cet utilisateur. S'il est identique, ignorer ; s'il le contredit, marquer l'ancien comme remplacé (superseded_at) plutôt que le supprimer.
5. Purger ou archiver : les sessions consolidées sont déplacées vers une table d'archive à rétention courte, puis supprimées de la table chaude.

La table de faits, dans Supabase ou n'importe quel PostgreSQL (les Data Tables natives de n8n conviennent aussi pour de petits volumes) :

create table agent_facts (
  id bigint generated always as identity primary key,
  user_key text not null,          -- même valeur que la Session Key de l'agent
  category text not null,          -- preference | decision | client_info
  fact text not null,
  source_session text not null,    -- session d'origine : traçabilité anti-hallucination
  valid_from timestamptz default now(),
  superseded_at timestamptz        -- null = fait actif
);

create unique index idx_facts_active
  on agent_facts (user_key, category, md5(fact))
  where superseded_at is null;

Et le prompt d'extraction, dont chaque ligne est un garde-fou :

Tu reçois le résumé d'une conversation entre un client et notre assistant.
Extrais uniquement les faits durables, en JSON :
- category : "preference", "decision" ou "client_info"
- fact : une phrase courte, autonome, au présent
- quote : la phrase exacte de la conversation qui justifie le fait

Règles :
- N'extrais RIEN qui ne soit pas explicitement dit (aucune déduction).
- Ignore les politesses, les hypothèses, les questions restées sans réponse.
- Si aucun fait durable : renvoie un tableau vide. C'est un résultat normal.

Un fait renvoyé sans quote est rejeté par le workflow : c'est le test le plus simple contre les faits hallucinés. Pour aller plus loin, vectorisez la colonne fact avec pgvector afin de rappeler les faits par similarité sémantique — la même mécanique que dans notre guide RAG avec Supabase, appliquée à des faits par utilisateur plutôt qu'à des documents.

La réinjection : rendre les faits utiles

Deux options, cumulables. La plus simple : injecter les N faits actifs les plus récents (ou les plus similaires au message entrant) dans le system prompt de l'agent, avec leur date :

{{ "Faits connus sur cet utilisateur :\n" + $('Recherche faits').all()
    .map(i => `- [${i.json.valid_from.slice(0,10)}] ${i.json.fact}`)
    .join('\n') }}

La plus souple : exposer la recherche dans agent_facts comme un outil « rechercher dans ma mémoire », que l'agent invoque lui-même quand la question l'exige. L'injection systématique garantit que les faits essentiels sont toujours là ; l'outil évite de payer des tokens pour des faits inutiles à la question posée. En pratique : 3-5 faits injectés d'office, le reste via l'outil.

Hygiène : une mémoire qui sait oublier

• TTL par catégorie : une préférence de contact vaut des années, une intention d'achat quelques semaines. Donnez à chaque catégorie sa durée de vie, et laissez le workflow nocturne marquer les faits expirés.
• Contradictions : ne jamais stocker deux faits actifs contradictoires. Le plus récent écrase l'ancien via superseded_at — l'historique des versions reste consultable, seul le fait actif est rappelé.
• Droit à l'oubli : les faits consolidés sont des données personnelles au même titre que les transcriptions. Une demande d'effacement doit purger la table de faits, l'archive et les éventuels embeddings — le circuit décrit dans notre guide pour traiter les demandes RGPD avec n8n s'y prête directement.

Les pièges

• Consolider trop tôt ou trop souvent : résumer une conversation encore en cours fige des faits provisoires (« hésite entre les offres A et B ») qui seront faux le soir même. Attendez la clôture de session, consolidez une fois par nuit.
• Faire confiance à l'extraction : sans exigence de citation et sans interdiction de déduire, le LLM comblera les silences. « Demande le prix de l'offre annuelle » deviendra « préfère la facturation annuelle ».
• Tout garder « au cas où » : conserver l'historique brut après consolidation recrée le problème initial, en double. La valeur de la consolidation vient autant de ce qu'elle supprime que de ce qu'elle extrait.
• Un seul workflow pour tout : mêler conversation et consolidation dans le même workflow couple deux rythmes incompatibles (temps réel vs batch nocturne) et fait payer la consolidation à chaque message.

En résumé

Une mémoire d'agent qui fonctionne n'est pas une base qui grossit, c'est un cycle : mémoire de session courte pour le fil, consolidation nocturne qui résume, extrait, déduplique, et purge, table de faits horodatés réinjectés au bon moment. C'est le même mouvement que le cerveau pendant le sommeil — rejouer, abstraire, oublier le reste — et il se construit intégralement avec des nodes n8n standard. La brique la plus technique, le stockage vectorisé et le rappel par similarité, est exactement celle que livre le Pack Assistant RAG (119 €) : ses workflows d'embeddings et de recherche pgvector se réorientent en une heure vers votre table agent_facts, et votre agent gagne ce qui le sépare d'un vrai assistant — une mémoire qui apprend chaque nuit.