## La convergence que personne n'avait prévue

Manus est un agent d'IA destiné aux consommateurs. Claude Code est l'assistant de codage d'Anthropic. OpenClaw est une IA personnelle open source. Différentes équipes, différentes bases de code, différents modèles économiques.

Les trois stockent la mémoire de l’agent dans des fichiers markdown.

Manus utilise une liste de contrôle `todo.md` qui se réécrit après chaque étape. OpenClaw utilise `MEMORY.md` ainsi que des fichiers datés dans un répertoire `memory/`. Claude Code utilise des fichiers hiérarchiques « CLAUDE.md » limités aux répertoires, avec une limite de 200 lignes sur le contenu toujours chargé.

Aucun ne semblait copier les autres. [Yaohua Chen sur DEV Community](https://dev.to/imaginex/ai-agent-memory-management-when-markdown-files-are-all-you-need-5ekk) a appelé cette « évolution convergente ». Lorsque trois systèmes indépendants soumis à des contraintes différentes arrivent à la même architecture, l’architecture vous dit quelque chose sur le problème.

Micheal Lanham [a documenté cette convergence](https://medium.com/@Micheal-Lanham/the-markdown-file-that-beat-a-50m-vector-database-38e1f5113cbe) en mars 2026. Son analyse des trois systèmes est la comparaison publique la plus approfondie des architectures de mémoire d'agent de production que j'ai vue. Les données méritent d’être exploitées directement.

## Pourquoi les fichiers sont le point de départ par défaut

L’explication évidente est la simplicité. Les fichiers sont lisibles par l'homme, traçables par git et ne nécessitent aucune infrastructure. Vrai mais incomplet.

La raison la plus profonde est l’économie du LLM.

Yichao "Peak" Ji, co-fondateur de Manus, a publié les chiffres. Manus traite 100 jetons d'entrée pour chaque jeton de sortie. Sur Claude Sonnet, les jetons mis en cache coûtent environ 0,30 $ par million. Les jetons non mis en cache coûtent 3 $ par million. Cet écart de 10x signifie que le coût des intrants domine. Tout ce qui augmente les taux de réussite du cache KV permet d'économiser de l'argent réel.

La mémoire basée sur les fichiers est un texte stable et prévisible qui fonctionne bien avec les préfixes du cache KV. Le contexte d'ajout uniquement qui change rarement entre les appels signifie que le modèle peut réutiliser les calculs mis en cache. Un système RAG basé sur une base de données qui assemble à chaque fois différents fragments de contexte met en échec cette optimisation.

Le modèle « todo.md » de Manus en est l'exemple le plus clair. L'agent réécrit la liste de contrôle après chaque étape. Cela place le plan actuel dans la position la plus récente de la fenêtre contextuelle. Les informations au milieu de contextes longs sont ignorées. Un fichier de plan fraîchement réécrit à la fin du contexte corrige ce problème sans infrastructure de récupération.

L’argument économique s’étend au-delà de Manus. Claude Code limite la mémoire toujours chargée à 200 lignes car les fichiers mémoire consomment des jetons à chaque session. La contrainte n'est pas le stockage. C'est un budget attentionné. Les fichiers vous permettent de contrôler ce que le modèle voit et où il apparaît dans son contexte.

Ce ne sont pas des choix accidentels. Il s’agit d’une architecture soucieuse des coûts.

## Où les fichiers se cassent

L'article de Lanham est honnête sur les modes de défaillance. Cette honnêteté est la partie la plus précieuse de l’analyse.

**Pression budgétaire contextuelle.** Claude Code prévient que les gros fichiers `CLAUDE.md` réduisent l'adhésion au modèle. Les fichiers fonctionnent jusqu'à ce qu'ils deviennent volumineux et contradictoires en interne. Un plafond de 200 lignes est une solution pragmatique, pas une solution. À mesure que l’utilisation des agents évolue, le dossier s’agrandit, se contredit et personne ne sait quelle version d’un fait est actuelle.

**Concurrence.** Plusieurs agents écrivant dans le même état de corruption de fichier mémoire. Lanham le déclare directement : « Au moment où plusieurs agents ou utilisateurs doivent toucher la même mémoire, des écritures simultanées de fichiers peuvent corrompre les données. » Le plafond du mono-agent est réel. La plupart des flux de travail agentiques [ne resteront pas à agent unique](/posts/when-agents-share-state-everything-breaks) pour toujours.

**Pas de versionnage.** Les fichiers sont écrasés. Le compactage de la mémoire d'OpenClaw déclenche un tour d'agent silencieux qui écrit des mémoires durables avant la troncature. Que contenait le fichier avant le compactage ? Inconnu. Si la version compactée a laissé tomber un fait, il a disparu. Pas de journal d'observation. Pas de retour en arrière.

**Aucune provenance.** Lorsqu'un agent écrit une entrée de mémoire, il n'y a aucune trace de la source qui l'a produite, quand ou si elle contredit quelque chose écrit la semaine dernière. Le dossier est un résumé. Les résumés obscurcissent leurs ingrédients.

**Aucune résolution d'entité.** « Acme Corp » dans une session et « ACME CORP » dans la suivante. L'agent réinfère l'identité à chaque fois à partir de la fenêtre contextuelle. Aucun identifiant stable. Aucune règle de fusion. Aucune entité canonique. Chaque session est une inférence à l'échelle de la session.

**Aucune contrainte de schéma.** N'importe quel agent ou outil peut écrire n'importe quoi dans un fichier mémoire. Aucune validation. Aucune vérification de type. Aucune application de ce qu'une entrée de mémoire doit contenir. Les mauvaises écritures se propagent sous forme de vérité.

Ces échecs ne sont pas hypothétiques. Ils sont documentés par les équipes construisant ces systèmes. Ils constituent le plafond opérationnel de la mémoire basée sur les fichiers.

## L'écart dans l'équilibre

Lanham propose une « architecture d'équilibre » à quatre couches. Fichiers comme interface principale. Déchargement agressif sur le disque. Couches de récupération dérivées (index vectoriel sur fichiers). Transmission claire aux bases de données lorsque la simultanéité et l'exactitude l'exigent.

Les trois premières couches sont bien documentées. Le quatrième est laissé en exercice au lecteur.

"Transférer vers une base de données" suppose que la base de données résout les problèmes d'intégrité. Postgres ne vous donne pas d'observations versionnées par défaut. Il ne vous donne pas de chaînes de provenance. Cela ne vous donne pas de résolution d'entité déterministe dans les documents. Il ne vous donne pas de contraintes de schéma sur l'état écrit par l'agent. Passer d'un fichier markdown à une table de base de données ne résout pas « l'absence de version ». Cela résout « l’absence d’accès simultané ». Ce sont des problèmes différents.

L'équilibre présente un écart entre les couches trois et quatre. Entre les « fichiers démarques qui fonctionnent pour un seul agent » et « l'infrastructure de base de données complète », il manque une couche. État structuré avec des garanties d’intégrité. Aucun schéma de base de données personnalisé requis.

L'architecture d'OpenClaw y fait allusion. Sa récupération hybride, sqlite-vec avec pondération vecteur/texte configurable, décroissance temporelle, diversification MMR, est plus sophistiquée qu'une simple recherche de fichiers. Mais il considère toujours les fichiers de démarque comme une source de vérité. L'index est une optimisation de lecture, pas une couche d'intégrité d'état.

Les primitives manquantes sont les mêmes que celles que j'ai identifiées [en exécutant ma propre pile agent](/posts/agentic-search-and-the-truth-layer) :

- **Observations versionnées.** Chaque écriture est ajoutée, rien n'est écrasé. Reconstruisez l’état à tout moment.
- **Provenance.** Chaque fait traçable à une source, un horodatage et l'agent ou l'humain qui l'a écrit.
- **Résolution d'entité déterministe.** ID canoniques basés sur des règles stables, et non sur une inférence par session.
- **Contraintes de schéma.** Validation sur les écritures. Mauvaises données rejetées avant d’entrer dans le magasin.

Ce ne sont pas des fonctionnalités de base de données. Ce sont des éléments d’intégrité de l’État. Vous pouvez les créer sur une base de données. Postgres ne vous les fournira pas immédiatement. Et vous ne pouvez pas du tout les obtenir à partir d’un fichier markdown.

## Les dossiers sont les vrais responsables

L’analyse stratégique la plus importante de l’analyse de Lanham ne concerne pas les fichiers par rapport aux bases de données. Il s’agit de savoir à quoi ressemble le paysage concurrentiel réel.

Les sociétés d'infrastructures de mémoire ont levé des dizaines de millions de dollars pour lutter contre les problèmes de récupération. [Mem0](https://mem0.ai) a collecté 24 millions de dollars. [Letta](https://www.letta.com) a clôturé une graine de 10 millions de dollars pour une valorisation de 70 millions de dollars. Le projet [Graphiti](https://github.com/getzep/graphiti) de [Zep](https://www.getzep.com) a croisé 20 000 étoiles GitHub. [MemPalace](https://github.com/MemPalace/mempalace) a atteint 46 000 étoiles au cours de ses deux premières semaines grâce à une approche de stockage verbatim axée sur le local. Ils résolvent de vrais problèmes : durabilité à travers les déploiements, personnalisation, récupération à grande échelle et rappel structuré.

Mais les systèmes gérant le plus d’interactions d’agents n’utilisent pas de bases de données vectorielles comme mémoire. Ils utilisent des fichiers texte. Les preuves de production provenant de trois plates-formes à l'échelle d'un milliard de dollars confirment que le véritable défaut n'est pas un produit de base de données existant. C'est un fichier.

Cela change l’histoire du déplacement. Le chemin de mise à niveau ne va pas des bases de données vectorielles vers quelque chose de mieux. Cela va des fichiers de démarque à l'état structuré. Les personnes qui ont besoin de garanties d’intégrité de l’État n’utilisent actuellement pas Mem0 ou Zep. Ils écrivent actuellement sur `MEMORY.md`.

## Migration, pas remplacement

Le conseil final de Lanham est correct dans son esprit : "Commencez avec un fichier Markdown. Vous pourrez toujours ajouter une base de données plus tard." Les fichiers constituent une architecture de départ rationnelle. L’économie les soutient. L’inspectabilité est réelle. La simplicité compte.

La question est de savoir à quoi ressemble « plus tard ».

Je construis [Neotoma](https://github.com/markmhendrickson/neotoma) comme chemin de mise à niveau. État structuré avec les garanties d'intégrité qui manquent aux fichiers : gestion des versions, provenance, résolution d'entité, contraintes de schéma.

La question de la rentabilité est importante. Si le chemin de mise à niveau sacrifie l’économie du cache KV qui rendait les fichiers rationnels, il ne s’agit pas d’une véritable mise à niveau. Le chemin de lecture de Neotoma est conçu autour de cette contrainte. Les agents y accèdent via MCP. La réponse est un texte structuré injecté dans la fenêtre contextuelle, le même format qu'un modèle verrait en lisant un fichier. Les instantanés d'entité sont stables entre les appels. La même entité interrogée deux fois renvoie le même texte sauf si une observation l'a modifié. Un texte stable signifie des séquences de jetons stables. Des séquences de jetons stables signifient des accès au cache KV.

Le chemin d’écriture est le point où les aspects économiques diffèrent, et où ils devraient le faire. L'écriture d'une observation dans un magasin structuré avec validation de schéma coûte plus cher que l'ajout d'une ligne à un fichier de démarque. Ces frais généraux représentent le prix de la gestion des versions, de la provenance et de la détection des conflits. La question est de savoir si ces frais généraux valent la peine d’être payés. Si vous n'avez jamais eu besoin de répondre « que savait mon agent mardi dernier » ou « qu'est-ce qui a corrompu cette entité », alors non. La démarque est correcte. Si vous aviez besoin de ces réponses et que vous ne parvenez pas à les obtenir, le coût du chemin d'écriture est la partie la moins chère du problème.

L’histoire de la migration est simple. Vous avez commencé avec `MEMORY.md` car c'était la bonne valeur par défaut. Vous atteigniez le plafond lorsque vous aviez besoin de gestion de versions, d'accès simultané, de provenance ou de résolution d'entités entre les sessions. L'étape suivante n'est pas de « configurer Postgres et de créer un schéma personnalisé ». Il s'agit d'une couche structurée qui vous offre ces garanties tout en préservant ce qui a fonctionné sur les fichiers : inspectabilité, simplicité, fonctionnement local d'abord.

L'évolution convergente documentée par Lanham valide le problème. Trois équipes valant des milliards au total sont arrivées à la même architecture et ont heurté les mêmes murs. Les murs définissent la couche suivante.