Tu Agente Olvida Todo: Comparación de Memoria por Archivos, Vectores y MCP

El mes pasado vi a Claude Code redescubrir, por cuarta vez, que mi proyecto usa pnpm y no npm. Ejecutó npm test, vio que fallaba, se disculpó, y lo intentó de nuevo con pnpm. Lo había explicado en tres sesiones anteriores. Ninguna sobrevivió. El agente no lleva nada entre ejecuciones a menos que yo lo haga posible.

Ese es el problema completo. Un agente de código no tiene estado entre ejecuciones. Cada sesión comienza con una ventana de contexto vacía. Todo lo que descubrió ayer — tus comandos de compilación, por qué una prueba es inestable, el hecho de que la base de datos de staging se reinicia a medianoche — se ha ido. Tú vuelves a explicar, él vuelve a derivar, ambos desperdician tokens.

Así que le das memoria. Y en el momento en que vas a buscar, encuentras tres cosas diferentes que se llaman "memoria", y la mayoría de lo que se escribe sobre ellas es un discurso de ventas de algún proveedor o un tutorial que no te dirá cuándo el enfoque falla.

La versión corta: para un desarrollador independiente, los archivos planos son el valor predeterminado y deberías agotarlos antes de agregar nada. Los almacenes vectoriales ganan su lugar cuando buscas en un corpus grande que no cabe en el contexto. Los servidores de memoria MCP son los más flexibles y los más fáciles de envenenar silenciosamente. La mayoría de la gente llega primero al más elegante. Eso es al revés.

Qué significa "memoria" aquí

Las tres opciones no son implementaciones competidoras de la misma cosa. Resuelven problemas diferentes y fallan de manera diferente.

Los archivos planos son markdown o texto que el agente lee al inicio — CLAUDE.md, AGENTS.md, un NOTES.md borrador. Tú o el agente los escribís, y se cargan en el contexto en cada sesión. Sin búsqueda, sin embeddings — solo "lee este archivo primero."

Los almacenes vectoriales convierten el texto en embeddings y permiten al agente recuperar por significado en lugar de por nombre de archivo. Escribes algo una vez, el almacén encuentra el fragmento relevante más tarde incluso si las palabras no coinciden.

Los servidores de memoria MCP son procesos separados con los que el agente habla sobre el Model Context Protocol, que expone herramientas, recursos y prompts a cualquier host compatible. Un servidor de memoria agrega herramientas como "almacena este hecho" y "busca en mi memoria" que el agente llama durante una tarea.

He enviado productos con los tres. Aquí está la lectura honesta de cada uno.

Archivos: aburridos, baratos, y el valor predeterminado correcto

La memoria de archivos es la que ya tienes. Claude Code lee CLAUDE.md al inicio de cada sesión, cargado completo como un mensaje de usuario después del system prompt — no como configuración impuesta, lo cual importa, porque el agente aún puede ignorarla. Los archivos se cargan desde una jerarquía: un archivo gestionado de toda la organización, tu ~/.claude/CLAUDE.md personal, el ./CLAUDE.md del proyecto, y un CLAUDE.local.md ignorado por git, ordenados de lo más amplio a lo más específico para que la instrucción más cercana se lea al final.

También hay memoria automática: Claude escribe sus propias notas en ~/.claude/projects/<project>/memory/MEMORY.md, y las primeras 200 líneas (o 25KB) de ese archivo se cargan en cada sesión. Guarda comandos de compilación e ideas de depuración que descubre, sin que tú las escribas. Lo dejo activado; ha capturado algunos hechos como "ah sí, las pruebas de API necesitan Redis local" que de otro modo habría vuelto a explicar.

No voy a repetir qué poner en un CLAUDE.md — escribí un post completo sobre eso. El punto aquí es arquitectónico: los archivos son buenos en exactamente una cosa, y es la cosa que la mayoría de los agentes necesitan — un conjunto pequeño y seleccionado de hechos que deberían ser ciertos en cada sesión.

En qué son buenos los archivos:

• Cero infraestructura. Es un archivo de texto en tu repositorio. Con control de versiones, comparable con diff, revisable en un PR.
• Puedes leer tu propia memoria. Cuando el agente hace algo tonto, abres el archivo y ves exactamente qué se le dijo. Intenta hacer eso con un embedding.
• Sobrevive. El CLAUDE.md de la raíz del proyecto incluso se reinyecta después de un /compact, por lo que una sesión larga no lo pierde.

En qué son malos los archivos:

• Cuestan tokens en cada solicitud. Todo en CLAUDE.md está en tu ventana de contexto durante toda la sesión. Los docs dicen apuntar a menos de 200 líneas, y tienen razón — pasado eso, la adherencia cae y estás pagando por instrucciones que el agente hojea.
• Sin recuperación. No puedes mantener mil hechos en un archivo que el agente lee cada vez. Es un conjunto de trabajo, no una base de datos.
• La obsolescencia es tu responsabilidad. Si tu comando de compilación cambia y olvidas actualizar el archivo, el agente ejecuta con confianza el antiguo. El archivo no sabe que está equivocado.

Para la mayoría de los proyectos independientes, los archivos son suficientes. He enviado productos donde CLAUDE.md más la memoria automática era todo el sistema de memoria y nunca quise más.

Almacenes vectoriales: buen recall, sin criterio

Cuando lo que quieres recordar es demasiado grande para caber en un archivo que el agente lee cada vez — un año de decisiones de arquitectura, una wiki interna grande, cada bug pasado y su solución — te mueves a la recuperación. Una base de datos vectorial almacena embeddings de alta dimensión de tu texto y encuentra las coincidencias más cercanas a una consulta por significado, típicamente en decenas de milisegundos.

No necesitas una base de datos vectorial dedicada para empezar. Si ya ejecutas Postgres, pgvector agrega almacenamiento y búsqueda vectorial a la base de datos que ya tienes, que suele ser el primer paso correcto para un desarrollador independiente. El valor predeterminado de 2026 es la búsqueda híbrida — palabra clave más vector — porque la búsqueda puramente semántica pierde casos de coincidencia exacta como un nombre de función específico o un código de error.

En qué son buenos los almacenes vectoriales:

• Recall a escala. Este es el único de los tres que maneja "tengo diez mil notas, encuentra las tres relevantes." Los archivos no pueden y los servidores de grafos MCP tienen dificultades.
• Significado sobre palabras. Escribiste "el flujo de pago hace doble cargo al reintentar", luego preguntas "por qué el pago se dispara dos veces", y encuentra la nota. La búsqueda por palabras clave no lo haría.

En qué son malos los almacenes vectoriales:

• La calidad de recuperación es un pipeline, no una configuración. El modelo de embedding, la estrategia de segmentación, el tipo de índice y la cadencia de actualización interactúan. Segmentar mal y recuperas la mitad de un pensamiento. Esto es trabajo real, y es trabajo que la mayoría de los desarrolladores independientes subestiman.
• No hay noción de verdadero. Un almacén vectorial devuelve lo que es similar, no lo que es correcto o actual. Si almacenaste un hecho en marzo y la verdad cambió en mayo, ambas versiones están en el índice y la de marzo puede ganar por similitud.
• Es una superficie de envenenamiento. Cualquier cosa que alimente el almacén — una página web que el agente indexó, un documento que alguien dejó en una carpeta compartida — puede plantar texto que luego se recupera como contexto autoritativo. Más sobre eso abajo.

Llego a un almacén vectorial cuando el corpus es genuinamente demasiado grande para el contexto y necesito recall. Para "recuerda mis cinco convenciones de proyecto", es claramente excesivo.

Servidores de memoria MCP: flexibles, estructurados, y mayor superficie de ataque

La tercera opción es un servidor de memoria al que te conectas por MCP. El de referencia es el servidor de memoria de grafo de conocimiento de Anthropic. Modela la memoria como un grafo: entidades (nodos nombrados con un tipo), relaciones (conexiones dirigidas en voz activa entre ellas), y observaciones (hechos atómicos adjuntos a una entidad). Persiste a un archivo memory.jsonl local y expone herramientas como create_entities, add_observations, search_nodes, y read_graph.

El argumento es que la estructura supera a un blob plano. "El usuario prefiere pnpm" se convierte en una observación en una entidad Usuario, relacionada con una entidad Proyecto, y el agente la atraviesa en lugar de buscar en prosa. En la práctica está entre archivos y vectores: más consultable que un archivo de texto, más interpretable que un embedding.

Vale la pena saber: la propia herramienta de memoria de Anthropic es un mecanismo diferente — una herramienta del lado del cliente donde el modelo emite comandos view, create, str_replace, delete contra un directorio /memories y tú implementas dónde viven los bytes. Su system prompt le dice al modelo "SIEMPRE VE TU DIRECTORIO DE MEMORIA ANTES DE HACER CUALQUIER OTRA COSA... tu ventana de contexto podría reiniciarse en cualquier momento." Eso te dice algo: incluso la "herramienta de memoria" de Anthropic son archivos en el fondo.

En qué son buenos los servidores de memoria MCP:

• Recall estructurado sobre el que el agente puede razonar. El recorrido del grafo responde "qué sé sobre este proyecto" con más precisión que una búsqueda por similitud.
• Portabilidad. MCP es un estándar, por lo que el mismo servidor funciona en Claude Code, Cursor y cualquier host compatible. Una memoria, muchas herramientas.
• Escrituras explícitas. El agente decide qué vale la pena almacenar como una observación discreta, lo que mantiene la memoria más limpia que volcar transcripciones completas en un índice vectorial.

En qué son malos los servidores de memoria MCP:

• Configuración y un proceso en ejecución. Es otra pieza móvil para instalar, configurar y mantener viva. Para un proyecto, eso es mucha ceremonia.
• El grafo se desvía. Sin disciplina, obtienes entidades duplicadas ("Proyecto", "el proyecto", "mi app") y observaciones contradictorias. La estructura que se suponía debía ayudar ahora necesita mantenimiento.
• Es el más fácil de envenenar. Persistente, escribible, recuperado como autoritativo — ese es exactamente el perfil que los atacantes buscan.

Los dos modos de fallo que nadie pone en la página de inicio

Cada post de "dale memoria a tu agente" vende las ventajas. Aquí están los dos que me afectaron.

Envenenamiento de memoria. Este es el que hay que tomar en serio. A diferencia de una inyección de prompt, que muere cuando cierra la sesión, el envenenamiento de memoria es un ataque de persistencia — una instrucción maliciosa plantada en tu almacén hoy se ejecuta semanas después, activada por una tarea no relacionada. El ataque y su efecto están temporalmente desacoplados. Cualquier pipeline que escriba a la memoria es un punto de entrada: una página web que el agente indexó, el README de una dependencia que resumió, un documento compartido. Los almacenes vectoriales y los servidores MCP están ambos expuestos porque ambos ingieren contenido automáticamente y lo sirven de vuelta como contexto de confianza. Los archivos son el seguro, precisamente porque un humano los escribe y puede leerlos en un diff.

Hechos obsoletos que anulan la realidad. Menos dramático, más común. Tu memoria dice que el nivel de precios es $20. Subió a $25 el martes pasado. El agente obtiene el hecho almacenado sin verificar tiempo de vida y sirve el número antiguo como autoritativo. El agente no tiene forma de saber que la página cambió hace una hora. Cada sistema de memoria tiene este problema, y cuanto más "automático" es el sistema, peor es, porque nadie está mirando qué se escribió. He enviado un valor de configuración incorrecto exactamente de esta manera. La memoria estaba segura. La memoria estaba equivocada.

La verdad incómoda: cuanto más automatizas la memoria, menos notas cuando te está mintiendo. Los archivos son molestos de mantener a mano, y esa molestia también es la auditoría.

Lo que realmente ejecutaría como desarrollador independiente

Empieza con archivos. CLAUDE.md para los hechos que sigues reexplicando, memoria automática activada para que el agente capture el resto. Esto cubre la mayor parte de lo que un proyecto independiente necesita, no cuesta nada configurar, y puedes leer cada byte de él. No agregues un segundo sistema hasta que los archivos claramente te fallen — y "fallar" significa un síntoma específico: el agente no puede encontrar una decisión que sabes que escribiste, o tu CLAUDE.md ha superado las 200 líneas de cosas que solo importan a veces.

Cuando eso suceda, haz una pregunta: ¿es el problema recall o estructura? Si tienes un corpus grande y el agente no puede encontrar la pieza correcta, eso es recall — agrega un almacén vectorial, empieza con pgvector si ya estás en Postgres, y usa búsqueda híbrida. Si quieres que el agente razone sobre relaciones entre sesiones y trabajas en múltiples herramientas, eso es estructura — un servidor de memoria MCP justifica su costo de configuración.

Independientemente de lo que agregues, trata la memoria como algo que puede estar equivocado. Pon una fecha en los hechos que caducan. Lee periódicamente qué se escribió — el comando /memory de Claude Code te muestra exactamente eso para los archivos, y es markdown simple que puedes editar o eliminar. Nunca dejes que un pipeline automatizado escriba en la memoria desde una fuente que no pegarías tú mismo en tu terminal.

Que el agente olvide todo es molesto. Que el agente recuerde con confianza algo falso es peor. Elige la memoria más simple que resuelva tu problema real, y mantenla lo suficientemente pequeña para que todavía puedas notar cuándo está equivocada.