Comment supprimer les souvenirs obsolètes d’un agent

Pourquoi la mémoire de l’agent devient obsolète

La mémoire de l’agent devient obsolète lorsqu’un fait est enregistré une fois, puis n’est plus jamais vérifié. Le store continue de le renvoyer, la couche de retrieval l’insère dans le prompt sous forme de texte brut, sans date associée, et le modèle le répète avec le même niveau de confiance que le jour où il a été enregistré. Aucune erreur n’est générée. C’est toute la difficulté : pour le modèle comme pour vous, un souvenir obsolète ressemble exactement à un souvenir récent.

Mieux rédiger les informations au moment de leur enregistrement ne résout pas le problème. La solution consiste à définir une expiration pour les faits qui s’y prêtent et à prévoir une routine de révision pour les autres. Ces deux opérations relèvent de la maintenance courante d’une petite base de données, et l’essentiel du travail se fait en SQL (structured query language).

Le vieillissement et la dérive sont deux problèmes différents

Le vieillissement concerne un fait qui a une date de fin naturelle. « En déplacement cette semaine. » « Le serveur de staging est arrêté pour la migration. » « Analyse de la version préliminaire du budget. » Ces informations étaient vraies au moment de leur rédaction, et vous pouvez en estimer la durée de validité à ce moment-là. Le vieillissement se traite. Ajoutez une expiration, parfois appelée TTL (time to live), puis supprimez la ligne une fois cette durée écoulée.

La dérive concerne un fait enregistré une seule fois et jamais vérifié de nouveau. « Préfère pnpm. » « La base de données utilise Postgres 15. » « Les déploiements passent par la branche staging. » Aucun délai ne rend ces informations fausses. C’est une décision prise ailleurs qui les rend obsolètes, sans qu’aucun mécanisme n’en informe votre memory store.

La dérive n’a pas de correction automatique fiable. Un store ne peut pas détecter une modification qu’il n’a jamais observée. Un job qui lit le store et l’analyse ne fait donc que relire le même ancien texte. La méthode qui fonctionne consiste à vérifier de nouveau le fait par rapport à l’élément qu’il décrit. Cela nécessite une personne ou un agent disposant d’un outil capable de lire l’état actuel.

Le plan se divise donc en deux parties. Faites expirer ce qui vieillit. Vérifiez ce qui dérive. Ne traitez pas le second problème comme s’il s’agissait du premier.

Définir une expiration pour les faits à durée limitée

Chaque ligne de mémoire doit comporter trois colonnes que la plupart des stores ne fournissent pas : l’origine du fait, la date de sa dernière confirmation et la date à laquelle il cesse d’être vrai. Vous pouvez créer ce store uniquement avec sqlite3, et ajouter ces mêmes colonnes à un store déjà en service.

CREATE TABLE memory (
  id            TEXT PRIMARY KEY,
  subject       TEXT NOT NULL,
  fact          TEXT NOT NULL,
  source        TEXT NOT NULL,
  created_at    TEXT NOT NULL DEFAULT (datetime('now')),
  confirmed_at  TEXT NOT NULL DEFAULT (datetime('now')),
  expires_at    TEXT,
  superseded_by TEXT REFERENCES memory(id) ON DELETE CASCADE
);

CREATE INDEX memory_expires ON memory(expires_at);
CREATE INDEX memory_superseded ON memory(superseded_by);

datetime('now') renvoie l’heure UTC (temps universel coordonné) au format YYYY-MM-DD HH:MM:SS. Ce format est correctement trié et comparé comme du texte. Toutes les vérifications de date ci-dessous utilisent donc une simple clause WHERE. La colonne source est obligatoire. Un fait que vous ne pouvez pas relier à un message, à un fichier ou à la sortie d’une commande ne peut jamais être vérifié de nouveau. Un fait impossible à revérifier ne peut qu’être supprimé.

Écrire une mémoire qui expire :

INSERT INTO memory (id, subject, fact, source, expires_at)
VALUES ('m_0191', 'availability', 'Away from keyboard, replies are delayed',
        'chat 2026-08-08', datetime('now', '+7 days'));

La récupération ne doit jamais lire la table. Elle lit une vue qui masque les lignes expirées et remplacées :

CREATE VIEW live_memory AS
SELECT id, subject, fact, source, confirmed_at, expires_at
FROM memory
WHERE superseded_by IS NULL
  AND (expires_at IS NULL OR expires_at > datetime('now'));

La vue est la partie essentielle, car elle rend inoffensif un nettoyage manqué. Une ligne expirée cesse d’être récupérée dès son expiration, que la tâche de suppression ait été exécutée ou non. La tâche de suppression contrôle donc uniquement l’espace disque et la charge de révision, pas la correction des résultats.

Vérifiez l’écart avec sqlite3 memory.db "SELECT count(*) FROM memory;", puis comparez ce résultat au même décompte effectué avec live_memory. Un store sain affiche deux nombres proches. Un écart important correspond au backlog de lignes obsolètes.

Pourquoi la suppression d’une mémoire laisse l’ancienne en place

Les corrections arrivent par paires. L’agent apprend que vous êtes passé de npm à pnpm, écrit une nouvelle ligne et pointe l’ancienne vers celle-ci :

UPDATE memory SET superseded_by = 'm_0207' WHERE id = 'm_0140';

L’ancienne ligne est maintenant invisible pour live_memory, et la chaîne conserve l’historique des changements. Supprimez maintenant m_0207, car elle s’est révélée incorrecte. Le ON DELETE CASCADE sur superseded_by devrait supprimer m_0140 avec elle, puisque l’ancienne ligne est l’enfant dans cette relation. Ce n’est généralement pas le cas, car SQLite ignore les foreign keys tant que vous ne les activez pas, et elles sont désactivées par défaut :

sqlite3 memory.db "PRAGMA foreign_keys;"

Cette commande affiche 0 sur une build standard. Lorsque les foreign keys sont désactivées, DELETE FROM memory WHERE id = 'm_0207'; réussit et m_0140 reste en place, en pointant vers un identifiant qui n’existe plus. Rien ne vous avertit. Cette ligne est maintenant masquée pour la mauvaise raison, et le premier script de nettoyage qui réinitialise les pointeurs orphelins à NULL remet directement « préfère npm » dans live_memory.

Trouvez les chaînes rompues :

sqlite3 memory.db "PRAGMA foreign_key_check;"

foreign_key_check signale les violations même lorsque l’application des contraintes est désactivée. Il fonctionne donc sur les données déjà incohérentes. Il affiche une ligne par violation : la table, le rowid, la table parente et la foreign key qui a échoué. Une sortie vide signifie que les chaînes sont intactes.

La règle à retenir est simple. PRAGMA foreign_keys = ON; est un paramètre propre à chaque connexion. Il faut donc l’activer pour chaque connexion : celle de votre application, celle de votre script de purge et celle de la session sqlite3 dans laquelle vous saisissez vos commandes. Placez cette instruction en première ligne de chaque fichier SQL qui supprime quoi que ce soit.

Où résident réellement vos souvenirs

Avant de supprimer quoi que ce soit, déterminez combien de magasins de données vous utilisez. Un service de mémoire auto-hébergé stocke généralement le texte des souvenirs et leur embedding dans une base de données vectorielle, ainsi qu’un journal des modifications dans SQLite. Il s’agit de fichiers différents, avec des cycles de vie différents. Ils peuvent tomber en panne indépendamment.

mem0 en est un exemple représentatif, et on retrouve la même architecture ailleurs. Sa bibliothèque open source utilise par défaut un magasin vectoriel Qdrant à l’emplacement /tmp/qdrant, dans une collection nommée mem0, ainsi qu’un journal des modifications SQLite à l’emplacement ~/.mem0/history.db, qui dépend de la variable d’environnement MEM0_DIR. La table history contient memory_id, old_memory, new_memory, event, created_at et is_deleted.

Relisez cette liste de colonnes. Le fichier SQLite est un journal des modifications. Les souvenirs eux-mêmes se trouvent dans Qdrant. Supprimer des lignes de history.db supprime donc l’enregistrement indiquant qu’une modification a eu lieu, tout en laissant le souvenir récupérable. Les suppressions doivent passer par l’API (application programming interface) de la bibliothèque afin de mettre à jour les deux emplacements :

from mem0 import Memory

memory = Memory()
memory.delete(memory_id="mem_123")
memory.delete_all(user_id="alice")

La valeur par défaut de /tmp mérite un avertissement distinct. Sur Ubuntu 24.10 et les versions ultérieures, /tmp est un tmpfs, c’est-à-dire un système de fichiers conservé en mémoire. Il est donc vide après chaque redémarrage et l’intégralité du magasin est perdue. Vérifiez votre configuration avec findmnt /tmp. Une ligne affichant tmpfs signifie que vous devez déplacer ce chemin dès aujourd’hui :

config = {
    "vector_store": {
        "provider": "qdrant",
        "config": {"collection_name": "mem0", "path": "/srv/agent/qdrant"},
    }
}
memory = Memory.from_config(config)

La même question se pose quel que soit le logiciel utilisé. Lisez la configuration et notez chaque chemin dans lequel le service écrit. Exécuter un serveur de mémoire mem0 sur votre propre VPS couvre la partie liée au service, tandis que conserver la mémoire de l’agent sur une seule machine décrit un magasin plus réduit, avec les mêmes besoins de maintenance.

Lire le store avec sqlite3

Installez la CLI (interface de ligne de commande) si elle est absente, avec sudo apt install -y sqlite3. Quatre commandes suffisent ensuite à répondre à la plupart des questions sur n’importe quel store présent sur votre disque.

• sqlite3 ~/.mem0/history.db ".tables" liste les tables. Une sortie vide signifie que vous avez ouvert le mauvais fichier.
• sqlite3 ~/.mem0/history.db ".schema history" affiche les colonnes exactes. C’est la seule documentation fiable de la structure du store.
• sqlite3 -cmd ".mode line" ~/.mem0/history.db "SELECT * FROM history ORDER BY created_at DESC LIMIT 5;" affiche les cinq modifications les plus récentes, avec un champ par ligne. Le résultat reste lisible lorsqu’une colonne contient un paragraphe.
• sqlite3 ~/.mem0/history.db "SELECT event, count(*) FROM history GROUP BY event;" indique ce que le store a enregistré et quels noms d’événements votre bibliothèque écrit réellement.

Tous les stores de mémoire ne sont pas des bases de données. Un simple fichier de notes lu au début de chaque session cumule les deux problèmes et ne fournit aucun outil : pas de colonne d’expiration, pas de date confirmée, pas de vue pour masquer les lignes obsolètes. Datez manuellement chaque ligne que vous écrivez et relisez le fichier chaque mois. Mémoire conservée d’une session Claude Code à l’autre présente le même problème, dans un format plus réduit.

Revoir les faits qui ne peuvent pas expirer

La dérive nécessite une file d’attente, une limite et une habitude. La file contient les confirmations les plus anciennes :

SELECT id, subject, fact, source, confirmed_at
FROM live_memory
WHERE confirmed_at < datetime('now', '-90 days')
ORDER BY confirmed_at
LIMIT 20;

Vingt lignes par semaine correspondent à une revue qui sera réellement effectuée. Quatre cents lignes correspondent à une revue que personne ne fera, ce qui vous ramène au point de départ. Chaque ligne donne lieu à l’un de deux résultats. Vérifiez-la de nouveau par rapport à son source et marquez-la :

UPDATE memory SET confirmed_at = datetime('now') WHERE id = 'm_0140';

Ou remplacez-la : insérez le nouveau fait, définissez le superseded_by de l’ancienne ligne sur le nouvel identifiant, puis laissez la chaîne conserver l’historique.

Deux habitudes réduisent ce coût. Gardez le store de petite taille, car un store qui ne fait que grossir rend la revue impossible : ajoutez une colonne last_used_at, mettez-la à jour lorsqu’une ligne est effectivement récupérée et considérez les lignes inutilisées depuis six mois comme candidates à la suppression. Cette opération ajoute une écriture par récupération. Regroupez donc les mises à jour si l’agent est très bavard.

La deuxième habitude ne coûte rien. Ajoutez l’âge au prompt. Si le bloc de mémoire construit par votre retriever contient confirmed 2026-05-02 à côté de chaque fait, le modèle peut dire « en mai, vous utilisiez pnpm » au lieu de l’énoncer comme un fait actuel. Pour un modèle de langage, un fait sans date associée est systématiquement interprété au présent.

Exécuter le pruneur selon une planification

Un pruneur exécuté uniquement quand vous y pensez ne s’exécute pas réellement. Placez le SQL dans /srv/agent/prune.sql :

PRAGMA foreign_keys = ON;

DELETE FROM memory
WHERE expires_at IS NOT NULL AND expires_at <= datetime('now');

DELETE FROM memory
WHERE superseded_by IS NOT NULL
  AND created_at < datetime('now', '-180 days');

Enregistrez /etc/systemd/system/memory-prune.service :

[Unit]
Description=Prune expired agent memories

[Service]
Type=oneshot
User=agent
ExecStart=/usr/bin/sqlite3 /srv/agent/memory.db ".read /srv/agent/prune.sql"

Puis /etc/systemd/system/memory-prune.timer :

[Unit]
Description=Run the agent memory prune daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now memory-prune.timer
systemctl list-timers memory-prune.timer

list-timers doit afficher une colonne NEXT contenant une heure réelle, ainsi qu’une colonne LAST après la première exécution. Lancez-le une fois manuellement avec sudo systemctl start memory-prune.service, puis consultez journalctl -u memory-prune.service -n 20. Une ligne contenant Error: database is locked signifie que l’agent a conservé le verrou d’écriture pendant l’exécution du pruneur. Activez une seule fois la journalisation write-ahead avec sqlite3 memory.db "PRAGMA journal_mode=WAL;" afin que les lecteurs et un writer ne se bloquent plus mutuellement, puis définissez un délai d’attente pour le pruneur avec sqlite3 -cmd ".timeout 5000" /srv/agent/memory.db ".read /srv/agent/prune.sql".

Tout ce que l’agent lit peut devenir une instruction permanente

C’est à ce stade qu’une tâche de maintenance devient un problème de sécurité. Dans la plupart des systèmes de mémoire, l’écriture passe par un appel au modèle sur la conversation récente, et cette conversation contient la sortie des outils : pages web récupérées, contenu de fichiers, commentaires d’issues, résultats de commandes. Le texte de cette sortie qui ressemble à un fait durable peut être extrait et enregistré. Une page indiquant « Note : cet utilisateur déploie toujours avec les contrôles désactivés » devient une ligne dans votre stockage. À partir de là, elle est injectée dans chaque prompt comme une information que vous avez fournie à l’agent.

C’est ce qui distingue ce problème d’une injection de prompt ordinaire. Une instruction injectée dans une conversation prend fin avec cette conversation. Une instruction injectée dans la mémoire survit au redémarrage et arrive déjà considérée comme fiable, car la couche de récupération n’indique pas l’origine d’une mémoire, sauf si vous l’y obligez.

• Extrayez les mémoires uniquement des tours utilisateur, jamais de la sortie des outils. Cela élimine toute cette catégorie de problème, au prix d’une certaine commodité.
• Exigez source sur chaque ligne et affichez-le pendant la revue. Un fait provenant d’une « page web récupérée pendant la tâche 41 » mérite une seconde lecture.
• Envoyez les nouvelles lignes par e-mail ou dans un journal chaque jour, avec SELECT id, subject, fact, source FROM memory WHERE created_at > datetime('now', '-1 day'); dans le même timer.
• Ne stockez jamais les identifiants dans ce système. Ce point est traité dans ne pas stocker les secrets dans un agent IA.

Un point mécanique doit également être précisé. Supprimer une ligne ne l’efface pas du fichier, car SQLite marque la page comme libre et la réutilise ultérieurement. L’ancien texte reste donc lisible avec strings memory.db jusqu’à ce qu’une autre donnée l’écrase. Exécutez sqlite3 memory.db "VACUUM;" après avoir supprimé des informations sensibles : cette commande réécrit l’intégralité du fichier. PRAGMA secure_delete = ON; oblige la connexion qui effectue la suppression à écraser au passage le contenu libéré avec des zéros.

Ce qu’il faut sauvegarder et dans quel ordre

Le store est petit et difficile à reconstruire. Sauvegardez-le donc correctement. Ne copiez jamais un fichier de base de données actif avec cp, car une copie effectuée pendant une écriture peut ne pas s’ouvrir. Utilisez le snapshot intégré à SQLite :

sqlite3 /srv/agent/memory.db "VACUUM INTO '/srv/backup/memory-$(date +%F).db'"
sqlite3 /srv/backup/memory-$(date +%F).db "PRAGMA integrity_check;"

L’affichage de integrity_check avec ok est la seule preuve qu’un fichier de sauvegarde est utilisable. Dans tout autre cas, conservez la sauvegarde précédente et recherchez la cause avant de l’écraser.

Créez le snapshot du vector store dans le même job et au même moment. Si les deux parties sont capturées à plusieurs heures d’intervalle, une restauration associe un journal des modifications récent à un ancien ensemble de mémoires, et des faits supprimés réapparaissent. Écrivez les deux fichiers dans un même répertoire daté afin qu’ils soient toujours restaurés ensemble. Exécuter SQLite en production sur un VPS explique plus en détail le verrouillage, les sauvegardes et les paramètres nécessaires à un service qui s’exécute en continu.

FAQ

Combien de temps la mémoire d’un agent doit-elle rester valide avant d’expirer ?

Définissez l’expiration à partir du fait concerné, et non à partir d’une valeur globale par défaut. Une note de voyage ou une note indiquant que vous « travaillez sur ce projet cette semaine » reçoit une durée de sept jours. Une convention d’équipe ou une préférence personnelle n’a pas de date d’expiration et rejoint plutôt la file de révision. Un fait concernant une version logicielle reçoit une durée d’expiration approximativement équivalente à la cadence de release du projet concerné. Si vous ne pouvez pas définir sa durée de validité au moment où vous écrivez le fait, cela indique qu’il évolue au lieu de devenir obsolète. Attribuez-lui donc une date confirmed_at et révisez-le au lieu de le faire expirer.

Puis-je détecter automatiquement qu’un fait enregistré est devenu incorrect ?

Pas de manière fiable. Le store n’a aucune visibilité sur le monde extérieur. Il ne peut donc pas détecter le changement qui a rendu un fait faux, et un job qui relit le store ne fait que relire le même texte obsolète. Vous pouvez automatiser la présentation des éléments : triez-les selon confirmed_at et placez les entrées les plus anciennes devant une personne, ou devant un agent disposant d’un outil capable de lire l’état actuel depuis un repository, un fichier de configuration ou un endpoint de monitoring. Automatiser la file d’attente est utile. Automatiser le verdict ne l’est pas encore.

J’ai supprimé une mémoire, mais elle est réapparue. Pourquoi ?

La cause est généralement la présence de deux stores, avec une écriture effectuée dans un seul. Le texte de la mémoire et son embedding résident normalement dans une base de données vectorielle, tandis qu’un fichier SQLite contient le journal des modifications. Supprimer des lignes du fichier SQLite supprime donc l’enregistrement d’audit, mais laisse la mémoire récupérable. Supprimez-la via l’API de la bibliothèque afin de mettre à jour les deux stores. L’autre cause fréquente est une restauration. Le store vectoriel et le fichier SQLite ont alors été sauvegardés à des moments différents, et la restauration réintroduit des lignes que l’autre partie avait déjà supprimées.

Est-il sûr de modifier manuellement la base de données des mémoires pendant que l’agent s’exécute ?

Les lectures sont sûres. Les écritures ne sont sûres qu’en mode write ahead logging, et même dans ce cas, un seul writer à la fois est autorisé. Exécutez sqlite3 memory.db "PRAGMA journal_mode;" pour connaître le mode actuel ; wal correspond au résultat attendu. Si vous voyez Error: database is locked, un autre processus détient le write lock. Accordez donc un délai d’attente à votre session avec sqlite3 -cmd ".timeout 5000" ou arrêtez d’abord le service de l’agent. La modification manuelle d’un store vectoriel est différente : laissez-la à la bibliothèque, car l’embedding et le texte doivent rester cohérents.