Une mémoire d’agent devient vraiment intéressante le jour où elle se trompe.

Imaginez qu’un agent revienne dans un dépôt trois semaines après une décision : « les retries sont gérés par le worker ». Il retrouve cette phrase dans sa mémoire, construit son plan autour et évite de relire vingt fichiers. Parfait, sauf si l’architecture a changé jeudi dernier.

Sans provenance, la phrase ressemble toujours à une vérité. Sans notion d’obsolescence, elle vieillit très bien. Sans moyen de savoir ce qui l’a remplacée, l’agent peut même devenir plus cohérent à mesure qu’il devient plus faux.

C’est le problème qui rend Memory, un jeune projet open source d’Aictx, plus intéressant que sa promesse de « mémoire persistante ».

Le dépôt a été créé fin avril, la version inspectée est encore en 0.2.1 et le projet ne compte que quelques dizaines d’étoiles GitHub. Ce n’est pas une nouvelle infrastructure standard qu’il faudrait installer partout lundi matin. C’est un bon objet pour regarder ce qu’une mémoire d’agent devrait contenir en plus du souvenir lui-même.

La mémoire contient une raison d’exister

Memory stocke localement un graphe du produit dans .memory/. Les corps sont en Markdown, les métadonnées en JSON, avec un index SQLite pour la recherche. Pas d’embeddings, pas de compte cloud et pas d’appel de modèle nécessaire pour conserver les données.

Le choix le plus utile est ailleurs.

Un objet mémoire peut porter des anchors, par exemple des chemins de code, mais aussi des éléments d’evidence. La version actuelle du schéma sait référencer un fichier, un commit, une tâche, une autre mémoire ou une source. Elle conserve également qui a introduit l’information via source, et peut décrire une provenance externe dans origin avec un locator, une date de capture, un digest ou un type de média.

Elle garde aussi un hash du contenu et peut marquer un objet comme stale ou superseded, avec une référence vers ce qui l’a remplacé.

Ça paraît presque excessif pour retenir que « le worker possède la logique de retry ».

C’est précisément le point.

Une mémoire persistante transforme une petite affirmation locale en entrée réutilisable par de futures décisions. Plus elle est efficace à rappeler cette affirmation, plus une erreur devient capable de voyager.

Les chercheurs voient déjà l’erreur voyager

Une étude présentée à ACL 2026 s’est intéressée directement à la manière dont les agents réutilisent leurs expériences passées. Les chercheurs décrivent un comportement qu’ils appellent experience-following : lorsqu’une nouvelle tâche ressemble fortement à une expérience retrouvée en mémoire, la sortie de l’agent tend elle aussi à ressembler à la sortie précédente.

Ça explique pourquoi la mémoire peut aider. Ça explique aussi son côté légèrement inquiétant.

L’étude observe deux problèmes. Le premier est la propagation d’erreurs : une mauvaise expérience stockée influence les suivantes. Le second est le misaligned experience replay : même une exécution qui avait l’air correcte dans son contexte peut être une mauvaise expérience à réutiliser ailleurs.

Autrement dit, « ce plan a déjà marché » n’est pas la même information que « ce plan est une bonne preuve pour cette tâche ».

Les auteurs montrent que la qualité des expériences conservées doit être régulée. La mémoire n’est donc pas simplement un disque plus long posé derrière le contexte du modèle. Elle devient un système éditorial : ajouter, corriger, oublier, requalifier.

Une provenance n’est toujours pas une preuve de vérité

Il faut garder une distinction importante.

Savoir qu’une affirmation vient du commit abc123, d’un fichier ou d’un message utilisateur ne rend pas cette affirmation vraie. La provenance répond à « d’où ça vient ? », pas automatiquement à « est-ce correct ? ».

Memory ne résout pas magiquement ce problème.

Sa commande sync regarde les ancres reliées au code et signale celles dont les fichiers ont changé ou disparu depuis la dernière synchronisation. Dans le code du projet, la sortie demande ensuite à l’agent de re-vérifier les objets concernés, de corriger les ancres et de marquer ce qui ne tient plus comme obsolète.

C’est une bonne limite à conserver : un fichier modifié est un signal de révision, pas la preuve mathématique que toutes les décisions qui le citaient sont mortes.

Le mécanisme ressemble davantage à un détecteur de fumée qu’à un expert en architecture. C’est déjà très utile si personne ne lui demande d’éteindre l’incendie tout seul.

La provenance commence à apparaître dans la recherche aussi

Aictx n’est pas seul à déplacer le problème dans cette direction.

MemORAI, publié dans les Findings d’ACL 2026, cite explicitement l’absence de suivi de provenance parmi les faiblesses des mémoires en graphe existantes. Son approche enrichit le graphe avec l’origine factuelle des informations au niveau des tours de conversation.

La comparaison est intéressante, mais il ne faut pas la transformer en validation d’Aictx. Les deux systèmes n’ont pas le même objectif, et l’article MemORAI n’a pas testé Memory.

Ce qu’ils partagent est plus simple : une mémoire utile doit conserver davantage que du texte récupérable.

Un autre benchmark ACL 2026, Mem2ActBench, pousse encore le problème. Il ne demande pas seulement si l’agent retrouve un souvenir. Il vérifie s’il sait réellement l’utiliser pour choisir un outil et remplir correctement ses paramètres. Sur sept frameworks de mémoire évalués, les systèmes actuels restent insuffisants sur cette application active de la mémoire.

Retrouver la bonne phrase n’était donc que la moitié facile du problème.

Une mémoire devrait être contestable

Il y a quelques mois, la conversation sur les agents tournait beaucoup autour de la taille du contexte : combien de tokens peut-on garder, comment résumer une session, comment rappeler les bons fichiers.

La mémoire persistante ajoute une question moins confortable : qu’est-ce qu’on autorise à devenir durable ?

Pour un agent de code, une entrée vraiment utile devrait idéalement pouvoir répondre à plusieurs choses quand on la conteste :

  • quelle affirmation est conservée ;
  • quelle source ou quel artefact la justifiait ;
  • à quel code elle était liée ;
  • quand elle a été observée ;
  • ce qui a changé depuis ;
  • si une décision plus récente l’a remplacée.

Toutes les mémoires n’ont pas besoin du même schéma qu’Aictx. Une préférence utilisateur comme « je veux les températures en Celsius » n’a pas besoin d’un commit Git signé par trois témoins.

Mais dès qu’un souvenir commence à piloter une action coûteuse, modifier du code, choisir un environnement, envoyer quelque chose ou prendre une décision pour l’utilisateur, sa provenance devient beaucoup plus intéressante que son score de similarité.

Une mémoire qui se rappelle tout peut être impressionnante. Une mémoire qui sait expliquer pourquoi elle croit encore quelque chose est beaucoup plus utile.