## La convergència que ningú planejava

Manus és un agent d'IA orientat al consumidor. Claude Code és l'assistent de codificació d'Anthropic. OpenClaw és una IA personal de codi obert. Equips diferents, bases de codi diferents, models de negoci diferents.

Tots tres emmagatzemen la memòria de l'agent en fitxers de reducció.

Manus utilitza una llista de verificació "todo.md" que es reescriu després de cada pas. L'OpenClaw utilitza `MEMORY.md` més fitxers datats en un directori `memory/`. Claude Code utilitza fitxers jeràrquics `CLAUDE.md` amb l'àmbit dels directoris, amb un límit de 200 línies al contingut sempre carregat.

Cap semblava copiar els altres. [Yaohua Chen a la comunitat DEV](https://dev.to/imaginex/ai-agent-memory-management-when-markdown-files-are-all-you-need-5ekk) va anomenar aquesta "evolució convergent". Quan tres sistemes independents amb restriccions diferents arriben a la mateixa arquitectura, l'arquitectura t'està dient alguna cosa sobre el problema.

Michael Lanham [va documentar aquesta convergència](https://medium.com/@Micheal-Lanham/the-markdown-file-that-beat-a-50m-vector-database-38e1f5113cbe) el març de 2026. La seva anàlisi dels tres sistemes és la comparació pública més exhaustiva de les arquitectures de memòria d'agents de producció que tinc. Val la pena interactuar directament amb les dades.

## Per què els fitxers són el punt de partida predeterminat

L'explicació òbvia és la senzillesa. Els fitxers són llegibles pels humans, es poden fer un seguiment git i no requereixen infraestructura. Cert però incomplet.

La raó més profunda és l'economia de LLM.

El cofundador de Manus, Yichao "Peak" Ji, va publicar els números. Manus processa 100 fitxes d'entrada per cada testimoni de sortida. A Claude Sonnet, els fitxes en memòria cau costen aproximadament 0,30 dòlars per milió. Les fitxes sense memòria cau costen 3 dòlars per milió. Aquesta difusió de 10 vegades significa que el cost d'entrada domina. Qualsevol cosa que augmenti les taxes d'èxit de la memòria cau KV estalvia diners reals.

La memòria basada en fitxers és un text estable i previsible que funciona bé amb els prefixos de la memòria cau KV. El context d'afegir només que rarament canvia entre les trucades significa que el model pot reutilitzar els càlculs de la memòria cau. Un sistema RAG recolzat per bases de dades que reuneix diferents fragments de context cada vegada derrota aquesta optimització.

El patró "todo.md" de Manus és l'exemple més clar. L'agent reescriu la llista de verificació després de cada pas. Això situa el pla actual a la posició de la finestra de context més recent. La informació enmig de contextos llargs s'ignora. Un fitxer de pla recentment reescrit al final del context ho soluciona sense infraestructura de recuperació.

L'argument econòmic va més enllà de Manus. Claude Code limita la memòria sempre carregada a 200 línies perquè els fitxers de memòria consumeixen fitxes cada sessió. La restricció no és l'emmagatzematge. És un pressupost d'atenció. Els fitxers us permeten controlar què veu el model i on apareix en context.

No són eleccions casuals. Són una arquitectura conscient dels costos.

## On es trenquen els fitxers

L'article de Lanham és honest sobre els modes de fallada. Aquesta honestedat és la part més valuosa de l'anàlisi.

**Presió pressupostària de context.** Claude Code adverteix que els fitxers `CLAUDE.md` grans redueixen l'adherència al model. Els fitxers funcionen fins que queden inflats i internament contradictoris. Un límit de 200 línies és una solució pragmàtica, no una solució. A mesura que l'ús de l'agent s'escala, el fitxer creix, es contradiu a si mateix i ningú sap quina versió d'un fet és actual.

**Concurrència.** Diversos agents escrivint al mateix fitxer de memòria en estat corrupte. Lanham ho afirma directament: "En el moment en què diversos agents o usuaris necessiten tocar la mateixa memòria, les escriptures concurrents de fitxers poden corrompre les dades". El sostre d'agent únic és real. La majoria dels fluxos de treball d'agent [no es quedaran com a agent únic](/posts/when-agents-share-state-everything-breaks) per sempre.

**Sense versions.** Els fitxers es sobreescriuen. La compactació de la memòria d'OpenClaw activa un gir d'agent silenciós que escriu records duradors abans del truncat. Què hi havia a l'arxiu abans de la compactació? Desconegut. Si la versió compactada va deixar caure un fet, desapareixerà. No hi ha registre d'observacions. Cap retrocés.

**Sense procedència.** Quan un agent escriu una entrada de memòria, no hi ha cap registre de quina font la va produir, quan o si contradiu alguna cosa escrita la setmana passada. El fitxer és un resum. Els resums enfosquen els seus ingredients.

**Cap resolució d'entitat.** "Acme Corp" en una sessió i "ACME CORP" en la següent. L'agent torna a inferir la identitat cada cop des de la finestra de context. No hi ha identificacions estables. No hi ha regles de fusió. No hi ha entitats canòniques. Cada sessió és una inferència de l'àmbit de la sessió.

**Sense restriccions d'esquema.** Qualsevol agent o eina pot escriure qualsevol cosa en un fitxer de memòria. Sense validació. Sense comprovació de tipus. Cap aplicació del que hauria de contenir una entrada de memòria. Les males escriptures es propaguen com a veritat.

Aquests errors no són hipotètics. Estan documentats pels equips que construeixen aquests sistemes. Són el sostre operatiu de la memòria basada en fitxers.

## La bretxa en l'equilibri

Lanham proposa una "arquitectura d'equilibri" amb quatre capes. Fitxers com a interfície principal. Descàrrega agressiva al disc. Capes de recuperació derivades (índex vectorial sobre fitxers). Escalada clara a bases de dades quan la concurrència i la correcció ho requereixin.

Les tres primeres capes estan ben documentades. El quart es deixa com a exercici per al lector.

"Escalar a una base de dades" suposa que la base de dades resol els problemes d'integritat. Postgres no us ofereix observacions versionades per defecte. No et dóna cadenes de procedència. No us ofereix una resolució determinista d'entitats entre documents. No us ofereix restriccions d'esquema sobre l'estat escrit per l'agent. Passar d'un fitxer de reducció a una taula de base de dades no soluciona "sense versions". Soluciona "cap accés concurrent". Són problemes diferents.

L'equilibri té un buit entre les capes tres i quatre. Entre "fitxers de reducció que funcionen per a un agent" i "infraestructura de base de dades completa" hi ha una capa que falta. Estat estructurat amb garanties d'integritat. No cal un esquema de base de dades personalitzat.

L'arquitectura d'OpenClaw indica això. La seva recuperació híbrida, sqlite-vec amb ponderació vectorial/text configurable, decadència temporal, diversificació MMR, és més sofisticada que la simple cerca de fitxers. Però encara tracta els fitxers de reducció com a font de veritat. L'índex és una optimització de lectura, no una capa d'integritat d'estat.

Els primitius que falten són els mateixos que vaig identificar [executant la meva pròpia pila agentic](/posts/agentic-search-and-the-truth-layer):

- **Observacions versionades.** Cada escrit s'afegeix, res sobreescrit. Reconstrueix l'estat en qualsevol moment.
- **Procedència.** Tots els fets rastrejables a una font, una marca de temps i l'agent o humà que l'ha escrit.
- **Resolució determinista d'entitats.** Identificadors canònics basats en regles estables, no en inferència per sessió.
- **Restriccions d'esquema.** Validació en escriptures. Dades incorrectes rebutjades abans d'entrar a la botiga.

Aquestes no són característiques de la base de dades. Són característiques d'integritat de l'estat. Podeu crear-los a sobre d'una base de dades. Postgres no us els donarà fora de la caixa. I no podeu obtenir-los d'un fitxer de reducció.

## Els fitxers són el veritable titular

La visió estratègica més important de l'anàlisi de Lanham no és sobre fitxers i bases de dades. Es tracta de com és el panorama competitiu real.

Les empreses d'infraestructures de memòria van recaptar desenes de milions de posicionaments contra problemes de recuperació. [Mem0](https://mem0.ai) va recaptar 24 milions de dòlars. [Letta](https://www.letta.com) va tancar una llavor de 10 milions de dòlars amb una valoració de 70 milions de dòlars. El projecte [Graphiti](https://github.com/getzep/graphiti) de [Zep](https://www.getzep.com) va creuar 20.000 estrelles de GitHub. [MemPalace](https://github.com/MemPalace/mempalace) va assolir 46.000 estrelles en les seves dues primeres setmanes amb un enfocament d'emmagatzematge textual, primer local. Solucionen problemes reals: durabilitat en els desplegaments, personalització, recuperació a escala i recuperació estructurada.

Però els sistemes que gestionen la majoria d'interaccions d'agents no utilitzen bases de dades vectorials per a la memòria. Estan utilitzant fitxers de text. Les proves de producció de plataformes a escala de tres mil milions de dòlars confirmen que el veritable predeterminat no és un producte de base de dades existent. És un fitxer.

Això canvia la història del desplaçament. La ruta d'actualització no és de bases de dades vectorials a alguna cosa millor. És dels fitxers de reducció a l'estat estructurat. Les persones que necessiten garanties d'integritat estatal no estan utilitzant actualment Mem0 o Zep. Actualment estan escrivint a `MEMORY.md`.

## Migració, no substitució

El consell de tancament de Lanham és correcte en esperit: "Comenceu amb un fitxer Markdown. Sempre podeu afegir una base de dades més tard". Els fitxers són una arquitectura inicial racional. L'economia els recolza. La inspeccionabilitat és real. La senzillesa importa.

La pregunta és com sembla "després".

Estic construint [Neotoma](https://github.com/markmhendrickson/neotoma) com a ruta d'actualització. L'estat estructurat amb la integritat garanteix la manca de fitxers: versions, procedència, resolució d'entitats, restriccions d'esquema.

La qüestió de l'eficiència en costos és important. Si la ruta d'actualització sacrifica l'economia de la memòria cau KV que va fer que els fitxers siguin racionals, no és una actualització real. El camí de lectura de Neotoma està dissenyat al voltant d'aquesta limitació. Els agents hi accedeixen mitjançant MCP. La resposta és un text estructurat injectat a la finestra de context, el mateix format que veuria un model en llegir un fitxer. Les instantànies d'entitat són estables entre trucades. La mateixa entitat consultada dues vegades retorna el mateix text tret que una observació el canviï. Text estable significa seqüències de testimonis estables. Les seqüències de testimoni estables signifiquen visites a la memòria cau KV.

El camí d'escriptura és on difereixen l'economia i on haurien de ser. Escriure una observació a una botiga estructurada amb validació d'esquemes costa més que afegir una línia a un fitxer de reducció. Aquesta sobrecàrrega és el preu de la versió, la procedència i la detecció de conflictes. La pregunta és si val la pena pagar aquestes despeses generals. Si mai no heu necessitat de respondre "què va saber el meu agent dimarts passat" o "quina escriptura va corrompre aquesta entitat", aleshores no. Markdown és correcte. Si heu necessitat aquestes respostes i no les podeu obtenir, el cost del camí d'escriptura és la part més barata del problema.

La història de la migració és senzilla. Heu començat amb `MEMORY.md` perquè era l'opció predeterminada correcta. Heu arribat al sostre quan necessiteu versions, accés concurrent, o procedència o resolució d'entitats entre sessions. El següent pas no és "configurar Postgres i crear un esquema personalitzat". És una capa estructurada que us ofereix aquestes garanties tot preservant el que funcionava sobre els fitxers: inspeccionabilitat, senzillesa, primer funcionament local.

L'evolució convergent que va documentar Lanham valida el problema. Tres equips per valor de milers de milions en total van arribar a la mateixa arquitectura i van colpejar les mateixes parets. Les parets defineixen la següent capa.