Le plugin de mémoire de votre agent l'oriente peut-être discrètement avec des faits périmés

Le produit appelé « mémoire » est une loterie

Dans un billet du 3 octobre 2026, le développeur Liao affirme que tous les plugins de mémoire pour agents du marché fonctionnent de la même manière : ils extraient le contenu de vos transcriptions de session, génèrent des extraits, les stockent dans une base de données vectorielle et, à chaque requête, joignent les cinq plus similaires. Si l'agent est toujours perdu, il reçoit un outil pour en chercher davantage. Selon lui, cette architecture ne permettra jamais à un agent de comprendre votre projet, quel que soit le nombre de fonctionnalités ajoutées par-dessus. Ce sont ses affirmations sur le marché, et non des constats vérifiés de manière indépendante.

Comment cela fonctionne, et où cela casse selon lui

RAG signifie retrieval-augmented generation (génération augmentée par la recherche) : avant que le modèle ne réponde, un système récupère les textes qui semblent pertinents et les colle dans la requête. Dans une base de données vectorielle, chaque extrait est converti en une liste de nombres (un embedding) qui représente son sens, et « similaire » signifie que les nombres sont proches les uns des autres. Cela mesure la ressemblance, pas la vérité.

À partir de là, le billet énumère plusieurs modes de défaillance :

• La similarité n'est pas l'exactitude. La recherche classe la proximité dans l'espace des embeddings. Elle ne peut pas vous dire quel extrait est à jour ni ce qui manque.
• Les extraits perdent leur contexte. Les motivations, les leçons tirées et l'environnement ne tiennent pas dans un fragment.
• Le passé est traité comme une vérité. Le code évolue chaque jour : quelle est la fiabilité de 500 extraits sur l'authentification ?
• Les agents ne peuvent pas chercher ce dont ils ignorent l'existence.
• Le stockage est inauditable. Avec 10 000 embeddings dans SQLite, lesquels sont périmés, jamais récupérés, ou erronés tout en influençant silencieusement le comportement ?

L'alternative : écrire les choses

La proposition du billet est une mémoire fondée sur des documents. Personne ne revisionne une réunion vieille de trois ans pour se rappeler une contrainte : on consulte des comptes rendus écrits. De même, l'agent dispose d'un espace de travail Markdown structuré contenant des instructions, des spécifications, des décisions, des recherches et des index. La boucle change : on passe de « requête, construction, oubli » à « requête, consultation, construction, mise à jour ». Avant de travailler, l'agent lit les documents pertinents. Ensuite, il révise ceux qui sont périmés et ajoute ceux qui manquent, tant que le tableau complet est encore en contexte.

L'auteur explique avoir commencé il y a plus d'un an avec un dossier internal/ et quelques instructions rudimentaires, qui sont devenus un plugin gratuit et open source nommé Operator Memory. Il affirme qu'il n'utilise ni base de données vectorielle, ni embeddings, ni outil de synthèse, ni démon en arrière-plan, seulement des fichiers Markdown que vous pouvez lire, modifier, valider (commit) et partager. Il note aussi que les fichiers AGENTS.md fonctionnent déjà, mais qu'ils constituent souvent la seule documentation d'un projet.

Ce qui est en jeu

Le groupe exposé, ce sont tous ceux qui font tourner un agent sur une base de code évoluant vite via un plugin de mémoire. Si l'auteur a raison, ces équipes disposent d'un stockage opaque qu'elles ne peuvent pas inspecter, qui alimente leur agent avec des faits possiblement périmés, sans moyen évident de le savoir. Le billet décrit aussi des personnes qui livrent des fonctionnalités sans lire le code, c'est-à-dire le moment où la documentation compte le plus et s'écrit le moins.

Ceux qui y gagnent sont les équipes capables de lire ce que leur agent sait. Un dossier de fichiers Markdown peut être relu dans une pull request, comparé par diff, corrigé par un humain et transmis à une nouvelle recrue. C'est autant une propriété de gouvernance qu'une propriété technique. Notez que la source est un praticien unique décrivant son propre outil et son expérience ; elle ne propose aucun benchmark comparant les approches.

Les questions à vous poser

• Quelqu'un dans votre équipe peut-il lister tout ce que la mémoire de votre agent contient actuellement, et quelles entrées sont périmées ou erronées ?
• Lorsque le code change, quel processus invalide les souvenirs qui décrivaient l'ancienne version ?
• Si votre agent a pris une mauvaise décision la semaine dernière, pouvez-vous remonter jusqu'au souvenir ou au document précis qui l'a influencé ?
• Qui relit ce que l'agent écrit dans ses propres documents, et qu'est-ce qui l'empêche d'enregistrer une conclusion erronée comme un fait établi ?
• Quelles preuves le fournisseur ou l'auteur apporte-t-il, au-delà de son usage personnel, que son approche surpasse l'alternative sur votre type de projet ?

Ce qu'il faut surveiller ensuite

Le signal à guetter est la preuve, pas l'enthousiasme : des comparaisons directes entre plugins à récupération d'extraits et espaces de travail documentaires sur les mêmes projets de longue durée, et la question de savoir si les éditeurs de solutions de mémoire se mettent à proposer des moyens d'inspecter, de modifier et de faire expirer ce qu'ils stockent. Si l'auditabilité devient une demande courante, c'est que l'argument d'architecture est en train de l'emporter.