## La convergencia que nadie planeó Manus es un agente de IA orientado al consumidor. Claude Code es el asistente de codificación de Anthropic. OpenClaw es una IA personal de código abierto. Diferentes equipos, diferentes bases de código, diferentes modelos de negocio. Los tres almacenan la memoria del agente en archivos de rebajas. Manus utiliza una lista de verificación `todo.md` que se reescribe después de cada paso. OpenClaw usa `MEMORY.md` más archivos fechados en un directorio `memory/`. Claude Code utiliza archivos jerárquicos `CLAUDE.md` con alcance en directorios, con un límite de 200 líneas en contenido siempre cargado. Ninguno parecía copiar a los demás. [Yaohua Chen en DEV Community](https://dev.to/imaginex/ai-agent-memory-management-when-markdown-files-are-all-you-need-5ekk) llamó a esto "evolución convergente". Cuando tres sistemas independientes bajo diferentes restricciones llegan a la misma arquitectura, la arquitectura le está diciendo algo sobre el problema. Micheal Lanham [documentó esta convergencia](https://medium.com/@Micheal-Lanham/the-markdown-file-that-beat-a-50m-vector-database-38e1f5113cbe) en marzo de 2026. Su análisis de los tres sistemas es la comparación pública más exhaustiva de arquitecturas de memoria de agentes de producción que he visto. Vale la pena interactuar directamente con los datos. ## Por qué los archivos son el punto de partida predeterminado La explicación obvia es la simplicidad. Los archivos son legibles por humanos, rastreables por git y no requieren infraestructura. Cierto pero incompleto. La razón más profunda es la economía LLM. El cofundador de Manus, Yichao "Peak" Ji, publicó las cifras. Manus procesa 100 tokens de entrada por cada token de salida. En Claude Sonnet, los tokens almacenados en caché cuestan aproximadamente 0,30 dólares por millón. Los tokens no almacenados en caché cuestan 3 dólares por millón. Ese diferencial de 10 veces significa que domina el costo de los insumos. Cualquier cosa que aumente las tasas de aciertos de la caché KV ahorra dinero real. La memoria basada en archivos es texto estable y predecible que funciona bien con los prefijos de caché KV. El contexto de solo agregar que rara vez cambia entre llamadas significa que el modelo puede reutilizar cálculos almacenados en caché. Un sistema RAG respaldado por una base de datos que reúne diferentes fragmentos de contexto cada vez anula esta optimización. El patrón `todo.md` de Manus es el ejemplo más claro. El agente reescribe la lista de verificación después de cada paso. Esto coloca el plan actual en la posición de la ventana de contexto más reciente. La información que se encuentra en medio de contextos prolongados se ignora. Un archivo de plan recién reescrito al final del contexto soluciona este problema sin infraestructura de recuperación. El argumento económico se extiende más allá de Manus. Claude Code limita la memoria siempre cargada a 200 líneas porque los archivos de memoria consumen tokens en cada sesión. La restricción no es el almacenamiento. Es presupuesto de atención. Los archivos le permiten controlar lo que ve el modelo y dónde aparece en contexto. Éstas no son elecciones accidentales. Son arquitecturas conscientes de los costos. ## Dónde se rompen los archivos El artículo de Lanham es honesto sobre los modos de falla. Esa honestidad es la parte más valiosa del análisis. **Presión presupuestaria contextual.** Claude Code advierte que los archivos grandes `CLAUDE.md` reducen la adherencia al modelo. Los archivos funcionan hasta que se vuelven inflados y contradictorios internamente. Un límite de 200 líneas es una solución pragmática, no una solución. A medida que el uso de los agentes aumenta, el archivo crece, se contradice y nadie sabe qué versión de un hecho es la actual. **Simultaneidad.** Múltiples agentes escribiendo en el mismo archivo de memoria están corruptos. Lanham lo afirma directamente: "En el momento en que varios agentes o usuarios necesitan tocar la misma memoria, las escrituras simultáneas de archivos pueden dañar los datos". El límite máximo de agente único es real. La mayoría de los flujos de trabajo agentes [no permanecerán con un solo agente](/posts/when-agents-share-state-everthing-breaks) para siempre. **Sin control de versiones.** Los archivos se sobrescriben. La compactación de la memoria de OpenClaw desencadena un giro de agente silencioso que escribe memorias duraderas antes del truncamiento. ¿Qué había en el archivo antes de la compactación? Desconocido. Si la versión compacta dejó caer un hecho, ya no existe. Sin registro de observación. Sin retroceso. **Sin procedencia.** Cuando un agente escribe una entrada en la memoria, no hay registro de qué fuente la produjo, cuándo o si contradice algo escrito la semana pasada. El expediente es un resumen. Los resúmenes oscurecen sus ingredientes. **Sin resolución de entidad.** "Acme Corp" en una sesión y "ACME CORP" en la siguiente. El agente vuelve a inferir la identidad cada vez desde la ventana contextual. No hay identificaciones estables. Sin reglas de fusión. Sin entidades canónicas. Cada sesión es una inferencia con alcance de sesión. **Sin restricciones de esquema.** Cualquier agente o herramienta puede escribir cualquier cosa en un archivo de memoria. Sin validación. Sin verificación de tipo. No se exige lo que debe contener una entrada de memoria. Los malos escritos se propagan como verdad. Estos fracasos no son hipotéticos. Están documentados por los equipos que construyen estos sistemas. Son el techo operativo de la memoria basada en archivos. ## La brecha en el equilibrio Lanham propone una "arquitectura de equilibrio" con cuatro capas. Archivos como interfaz principal. Descarga agresiva al disco. Capas de recuperación derivadas (índice vectorial sobre archivos). Escalado claro a bases de datos cuando la concurrencia y la corrección lo exigen. Las primeras tres capas están bien documentadas. El cuarto se deja como ejercicio para el lector. "Escalar a una base de datos" supone que la base de datos resuelve los problemas de integridad. Postgres no proporciona observaciones versionadas de forma predeterminada. No te da cadenas de procedencia. No le brinda una resolución de entidad determinista entre documentos. No proporciona restricciones de esquema sobre el estado escrito por el agente. Pasar de un archivo de rebajas a una tabla de base de datos no resuelve la "falta de control de versiones". Resuelve "sin acceso concurrente". Esos son problemas diferentes. El equilibrio tiene un espacio entre las capas tres y cuatro. Entre "archivos de rebajas que funcionan para un agente" y "infraestructura de base de datos completa" falta una capa. Estado estructurado con garantías de integridad. No se requiere ningún esquema de base de datos personalizado. La arquitectura de OpenClaw da pistas de esto. Su recuperación híbrida, sqlite-vec con ponderación vectorial/texto configurable, decaimiento temporal y diversificación MMR, es más sofisticada que la simple búsqueda de archivos. Pero todavía trata los archivos de rebajas como fuente de verdad. El índice es una optimización de lectura, no una capa de integridad del estado. Las primitivas que faltan son las mismas que identifiqué [ejecutando mi propia pila agente](/posts/agentic-search-and-the-truth-layer): - **Observaciones versionadas.** Cada escritura adjunta, nada sobrescrito. Reconstruir el estado en cualquier momento. - **Procedencia.** Cada hecho rastreable hasta una fuente, una marca de tiempo y el agente o humano que lo escribió. - **Resolución de entidad determinista.** ID canónicas basadas en reglas estables, no en inferencias por sesión. - **Restricciones del esquema.** Validación en escrituras. Datos incorrectos rechazados antes de ingresar a la tienda. Estas no son características de la base de datos. Son características de integridad del estado. Puede construirlos sobre una base de datos. Postgres no se los entregará de forma inmediata. Y no puede obtenerlos en absoluto de un archivo de rebajas. ## Los archivos son el verdadero titular La idea estratégica más importante del análisis de Lanham no tiene que ver con archivos versus bases de datos. Se trata de cómo es el panorama competitivo real. Las empresas de infraestructura de memoria recaudaron decenas de millones para luchar contra los problemas de recuperación. [Mem0](https://mem0.ai) recaudó 24 millones de dólares. [Letta](https://www.letta.com) cerró una semilla de 10 millones de dólares con una valoración de 70 millones de dólares. El proyecto [Graphiti](https://github.com/getzep/graphiti) de [Zep](https://www.getzep.com) superó las 20.000 estrellas de GitHub. [MemPalace](https://github.com/MemPalace/mempalace) alcanzó 46.000 estrellas en sus primeras dos semanas con un enfoque de almacenamiento literal y local primero. Resuelven problemas reales: durabilidad en las implementaciones, personalización, recuperación a escala y recuperación estructurada. Pero los sistemas que manejan la mayoría de las interacciones entre agentes no utilizan bases de datos vectoriales para la memoria. Están utilizando archivos de texto. La evidencia de producción de plataformas a escala de tres mil millones de dólares confirma que el verdadero valor predeterminado no es un producto de base de datos existente. Es un archivo. Esto cambia la historia del desplazamiento. La ruta de actualización no es de bases de datos vectoriales a algo mejor. Es desde archivos de rebajas hasta estado estructurado. Las personas que necesitan garantías estatales de integridad no utilizan actualmente Mem0 o Zep. Actualmente están escribiendo en `MEMORY.md`. ## Migración, no reemplazo El consejo final de Lanham es correcto en espíritu: "Comience con un archivo Markdown. Siempre puede agregar una base de datos más adelante". Los archivos son una arquitectura inicial racional. La economía los respalda. La inspeccionabilidad es real. La simplicidad importa. La pregunta es cómo será el "más tarde". Estoy construyendo [Neotoma](https://github.com/markmhendrickson/neotoma) como esa ruta de actualización. Estado estructurado con las garantías de integridad de las que carecen los archivos: control de versiones, procedencia, resolución de entidades, restricciones de esquema. La cuestión de la rentabilidad es importante. Si la ruta de actualización sacrifica la economía del caché KV que hizo que los archivos sean racionales, no es una actualización real. La ruta de lectura de Neotoma está diseñada en torno a esta restricción. Los agentes acceden a él a través de MCP. La respuesta es texto estructurado inyectado en la ventana contextual, el mismo formato que vería un modelo al leer un archivo. Las instantáneas de entidades son estables entre llamadas. La misma entidad consultada dos veces devuelve el mismo texto a menos que una observación lo haya cambiado. Texto estable significa secuencias de tokens estables. Las secuencias de tokens estables significan aciertos en la caché KV. La ruta de escritura es donde las economías difieren, y donde deberían hacerlo. Escribir una observación en una tienda estructurada con validación de esquema cuesta más que agregar una línea a un archivo de rebajas. Esa sobrecarga es el precio del control de versiones, la procedencia y la detección de conflictos. La pregunta es si vale la pena pagar esos gastos generales. Si nunca ha necesitado responder "¿qué sabía mi agente el martes pasado?" o "qué escritura corrompió esta entidad", entonces no. La rebaja es correcta. Si necesitaba esas respuestas y no pudo obtenerlas, el costo de la ruta de escritura es la parte más barata del problema. La historia de la migración es sencilla. Comenzó con `MEMORY.md` porque era el valor predeterminado correcto. Tocó el techo cuando necesitaba control de versiones, acceso simultáneo, procedencia o resolución de entidades entre sesiones. El siguiente paso no es "configurar Postgres y crear un esquema personalizado". Es una capa estructurada que le brinda esas garantías y al mismo tiempo conserva lo que funcionó con los archivos: inspeccionabilidad, simplicidad y operación local primero. La evolución convergente que documentó Lanham valida el problema. Tres equipos con un valor total de miles de millones llegaron a la misma arquitectura y chocaron contra los mismos muros. Las paredes definen la siguiente capa.