Memoria persistente en Claude: 3 setups que cambian cómo trabajas

"Memoria persistente" suena a misterio técnico. En la práctica son tres cosas distintas con costos y trade-offs distintos. Te cuento cuál usar y cuándo, sin teatro.

Por qué te importa la memoria

Cada vez que abres un chat nuevo y tienes que volver a explicarle al modelo quién eres, qué proyecto manejas, qué reglas tienes, qué herramientas usas, estás pagando un impuesto de contexto. Ese impuesto es tiempo y es errores. Memoria persistente es lo que quita ese impuesto.

La pregunta no es "¿uso memoria?". La pregunta es "¿qué tipo de memoria, para qué uso?".

Setup 1: Memory feature nativa

Es la opción que activas dentro del cliente oficial. El modelo guarda automáticamente cosas que considera relevantes y las recupera cuando las necesita.

Cuándo tiene sentido

• Uso general personal: preferencias de tono, idioma, formatos.
• Personas que no quieren administrar archivos.
• Casos donde la memoria no es crítica para el resultado.

Limitaciones honestas

• No tienes control fino sobre qué se guarda.
• La memoria vive dentro del cliente; portarla a otro entorno es difícil.
• Para trabajo serio con reglas duras, falla. El modelo "se olvida" o reinterpreta.

Si lo tuyo es chat conversacional liviano, esto te alcanza. Si construyes con Claude flujos serios, salta al setup 2.

Setup 2: Archivo plano tipo MEMORY.md o CLAUDE.md

El más subestimado. Es un archivo de texto que vive en tu carpeta de proyecto y el cliente (Claude Code, por ejemplo) lo carga automáticamente al inicio de cada sesión.

Estructura típica:

• Identidad del proyecto: qué es, para quién, qué reglas no se rompen.
• Convenciones: estilo de código, formato de respuestas, idioma.
• Decisiones previas: por qué elegiste X sobre Y. Evita revisitarlas cada vez.
• Pendientes y contexto vivo: qué se está trabajando hoy.

Por qué gana en la mayoría de casos

• Control total: tú decides qué entra y qué sale. Auditas con un editor de texto.
• Versionable: vive en git, lo revisas, lo revierte si algo se rompió.
• Portable: el mismo archivo sirve para distintos clientes y entornos.
• Cero infraestructura: no necesitas vector DB, ni servicio externo, ni costos recurrentes.

Cuándo se queda corto

• Cuando tu base supera 50 a 100 mil tokens útiles. Cargar todo en cada sesión deja de ser eficiente.
• Cuando necesitas búsqueda semántica precisa entre cientos de documentos.
• Cuando varios agentes leen y escriben sobre la misma base con frecuencia y volumen.

Setup 3: RAG con vector store

Aquí entras al mundo "serio". Tomas tus documentos, los partes en chunks, los conviertes a embeddings, los guardas en una base vectorial, y al momento de la pregunta recuperas los chunks relevantes y se los das al modelo.

Cuándo tiene sentido

• Tienes una base grande: cientos de PDFs, documentación interna, manuales.
• Necesitas que el modelo cite exactamente de qué documento sale cada afirmación.
• Construyes un producto, no solo un asistente personal.

Lo que cuesta de verdad

• Setup técnico: elegir vector store, definir tamaño de chunk, decidir overlap, montar el pipeline.
• Mantenimiento: cuando cambian los documentos, tienes que reindexar.
• Costos recurrentes: embeddings, almacenamiento, llamadas al modelo con contexto extra.
• Calidad: un mal chunking te da respuestas peores que sin RAG. Hay que medir.

RAG no es un setup que prendes una tarde. Es un sistema que mantienes. Si no estás listo para mantenerlo, no lo prendas.

Ejemplo concreto: caso marketer LatAm

Una marketer maneja una marca con 3 países, 4 productos, varios mensajes clave por país. Su base de conocimiento útil son unos 30 documentos: brand book, guías de tono, lineamientos legales, briefings de campaña.

• Setup 1 (Memory nativa): falla. Es demasiado material y demasiado crítico para que el modelo decida qué guardar.
• Setup 2 (MEMORY.md): gana. 30 documentos caben en un repositorio bien estructurado con un archivo índice. Versionable, portable, auditable.
• Setup 3 (RAG): overkill. Le pone 3 horas de setup técnico y un costo mensual a un problema que se resuelve con archivos de texto.

Ejemplo concreto: caso producto SaaS

Un equipo construye un asistente para clientes con 800 artículos de soporte, en tres idiomas, con actualizaciones semanales.

• Setup 1: imposible.
• Setup 2: imposible. La base no cabe en contexto cada sesión.
• Setup 3: la única opción razonable. Vector store, pipeline de actualización, métricas de calidad. Aquí sí justifica el costo de mantenimiento.

Errores comunes que veo

• Saltar a RAG por moda. Antes de armar un vector store, intenta resolver con un MEMORY.md de 500 líneas bien escritas. La mayoría de problemas se acaban ahí.
• MEMORY.md como basurero. Si dejas que crezca sin curaduría, el modelo se vuelve lento y empieza a contradecirse. Trátalo como código: limpio, versionado, con secciones claras.
• No medir. Activas RAG y nadie compara la calidad antes y después. A veces empeora y nadie se da cuenta.
• Mezclar memoria personal y memoria de proyecto. Cuando tu Memory nativa habla de tu cumpleaños y de un cliente, el modelo se confunde. Sepáralas.

Qué hago yo

yo recomiendo esta progresión: empieza con archivo plano tipo MEMORY.md o CLAUDE.md bien curado. Vívelo seis meses. Cuando el archivo pase de 1000 líneas o cuando empieces a sentir que el modelo "se pierde" buscando algo, ahí evalúa partir secciones en archivos temáticos referenciados desde el principal. Solo cuando esa estructura colapse y tengas presupuesto para mantener un sistema, mueves a RAG.

El secreto no es la herramienta más sofisticada. Es la herramienta más simple que resuelve hoy y se aguanta el crecimiento de los próximos seis meses.