Sistemas de memoria de Claude Code: los 6 niveles explicados

Sistemas de memoria de Claude Code: los 6 niveles explicados

Casi rompo toda mi operación de contenido el martes pasado al actualizar mi sistema de memoria a un nivel que no necesitaba.

La configuración que sostiene mi negocio: 232 posts publicados en mejba.me, cuatro voces de marca, un agente @aria que escribe artículos de 3.000 palabras de una sola pasada y una capa de memoria que tiene que recordar el tono de cada marca, cada cluster, cada frase prohibida y cada plantilla de pie. Durante unos tres meses esa capa de memoria fueron solo dos archivos markdown. Luego leí un hilo afirmando que los usuarios "de verdad" de Claude Code corren palacios de memoria respaldados por RAG con índices vectoriales, y me pasé una tarde entera intentando enchufar uno.

Al final de esa tarde había roto tres skills, corrompido la auto-memoria de un proyecto y producido exactamente cero contenido nuevo. Así que reverté todo, abrí un doc en blanco y me obligué a mapear de verdad cómo se ve la memoria de Claude Code en 2026 — cada nivel, qué cuesta, para quién es. No en teoría. Basado en lo que de hecho he corrido, lo que he visto correr a otros operadores y lo que he visto irse de lado.

Hay seis niveles. La mayoría de la gente que corre Claude Code nunca necesita subir más allá del nivel tres. Algunos sí. Elegir el nivel equivocado — demasiado simple o demasiado complejo — es lo que quema fines de semana. Este post es el mapa que me hubiera gustado tener antes de empezar a subir.

Por qué la memoria de Claude Code importa siquiera en 2026

Si usas Claude Code como un autocompletado glorificado, la memoria es irrelevante. Abres una pestaña, tecleas un prompt, la cierras, listo. El modelo no necesita recordar nada de ti porque no hay nada que recordar.

Pero en el momento en que tu flujo de trabajo tiene forma — tareas recurrentes, voces de marca, convenciones de código, decisiones que has tomado y no quieres reexplicar cada lunes — la memoria se convierte en la palanca más grande entre "Claude es útil a veces" y "Claude es un compañero de equipo". Eso no es lenguaje de marketing. Soy yo, viendo al mismo agente pasar de generar posts SEO genéricos a clavar mi voz de marca a la primera, solo porque le di una capa de memoria estructurada a la que recurrir.

El problema en 2026 es que "memoria de Claude Code" ahora se refiere a al menos seis arquitecturas distintas, que van desde un archivo markdown en la raíz de tu proyecto hasta una base de datos Postgres autoalojada con embeddings compartidos entre Claude, ChatGPT y Cursor. Los docs oficiales cubren bien la primera. La comunidad ha construido las otras cinco. Casi nadie explica dónde cada una deja de valer la complejidad.

Esa es la pregunta que de verdad me importa. Porque cada nivel por encima del que necesitas es solo impuesto — impuesto de ingeniería, impuesto de debugging, impuesto de atención. Así que recorrámoslos.

Nivel 1: Memoria nativa básica (claude.md + memory.md)

Esto es con lo que viene Claude Code. Sin plugin. Sin base de datos vectorial. Sin hooks. Solo dos archivos markdown que el modelo carga al inicio de la sesión.

claude.md es tu archivo de instrucciones a nivel de proyecto. Lo escribes tú. Contiene las reglas, convenciones, voces de marca, frases prohibidas, rutas de archivos — cualquier cosa que quieras que el modelo sepa cada vez que abras una sesión en ese directorio. Según los docs oficiales de Claude Code, el archivo se carga automáticamente en el contexto y se trata como guía autoritativa del proyecto.

memory.md (también llamado auto-memoria) es lo que Claude escribe sobre ti. Cuando lo corriges ("no uses punto y coma en este codebase"), o averigua un comando de build, o aprende una preferencia de flujo, te pregunta si guardarlo como memoria. Apruebas. La siguiente sesión, lo recuerda.

Juntos, estos dos archivos forman una capa de memoria funcional que cuesta cero dólares, corre enteramente en tu máquina y maneja quizá el 70% de lo que necesita un flujo de un solo developer u operador en solitario. Mi claude.md principal para el repo ai-agents-team tiene unas 180 líneas. Define las cuatro voces de marca, el formato de salida, las restricciones duras, el layout de directorios. Y ya. Sin vectores. Sin embeddings. Sin daemons.

La trampa — y esta es la trampa de la que nadie te avisa — es la putrefacción de contexto. Cuando claude.md crece más allá de unas 200 líneas, el modelo empieza a leerlo por encima. Reglas específicas se ignoran. Frases prohibidas vuelven a colarse en la salida. Empiezas a pensar que el modelo está roto, pero en realidad has metido demasiado en el slot del contexto que más atención merece. He visto pasar esto en mi propia configuración tres veces distintas. El fix es siempre el mismo: dividir el archivo, o mover las reglas estables a algo más estructurado.

Para quién es el nivel 1: Cualquiera que esté empezando con Claude Code. Cualquiera cuyo flujo entero quepa en un proyecto. Cualquiera que pueda responder "¿qué necesita saber esta IA sobre mí?" en menos de 200 líneas. Si todavía no puedes responder esa pregunta, no tienes un problema de memoria — tienes un problema de claridad, y añadir infraestructura no lo arreglará.

Dónde se rompe: La semana en que te das cuenta de que estás manteniendo siete archivos claude.md distintos a través de siete proyectos, todos repitiendo las mismas reglas core.

Nivel 2: Inyección de memoria mejorada (Hooks + estructura de carpetas)

Aquí es donde viví la mayor parte de 2026. También es donde se ha asentado la mayoría de la gente que respeto en este espacio.

La idea es simple. En lugar de un claude.md gigante, divides la memoria en una estructura de carpetas — usualmente tres cubos:

• general/ — reglas inter-proyecto. Voz, ética, formato de salida.
• domain/ — memoria específica de tema. SEO, copywriting, seguridad, diseño.
• tool/ — memoria específica de herramienta. Skills de Claude Code, uso de Figma MCP, gotchas de Webflow.

Luego añades un hook de inicio de sesión — un script que se ejecuta en el momento en que Claude Code arranca. El hook lee un índice de tus carpetas de memoria e inyecta solo la rebanada relevante en el contexto. ¿Necesitas SEO? El hook inyecta la memoria SEO. ¿Trabajando en un sistema de diseño? Trae la memoria de diseño y se salta el resto.

Los hooks no son instrucciones en lenguaje natural — son scripts que se disparan ante eventos. PreToolUse, PostToolUse, SessionStart, UserPromptSubmit. Los docs oficiales en 2026 son claros sobre esta distinción, e importa: los hooks son deterministas. Corren tenga el modelo "ganas" o no. Ese es todo el punto.

Lo que obtienes del nivel 2:

1. Sin putrefacción de contexto. Cada rebanada inyectada se mantiene pequeña y específica.
2. Compartir en equipo. Tu carpeta de memoria es solo markdown — comprométela en git, tu compañero la clona, obtiene tus estándares.
3. Recall selectivo. ¿Trabajando en un proyecto Laravel? La memoria de Figma no se carga. Tu ventana de contexto se mantiene limpia.
4. Versionado. La memoria es ahora un artefacto rastreado, no un efecto colateral en runtime.

El coste es una tarde de configuración. Escribes la estructura de carpetas, escribes un script hook diminuto (el mío son 40 líneas de Bash más una config JSON), lo pruebas una vez y luego simplemente corre. Cubro el patrón de hooks más amplio en mi análisis sobre automatizar comprobaciones SEO con rutinas de Claude Code — misma arquitectura, aplicación distinta.

Para quién es el nivel 2: Cualquiera que lleve más de un mes usando Claude Code. Cualquiera cuyo archivo de memoria haya cruzado las 200 líneas. Cualquiera trabajando con un equipo. Cualquiera corriendo flujos multi-proyecto donde las reglas se solapan pero no son idénticas.

Dónde se rompe: Cuando tu carpeta de memoria llega a cierto tamaño — digamos 50+ archivos — y el hook de índice empieza a inyectar demasiadas rebanadas "relevantes", o peor, se pierde la verdaderamente relevante. En ese punto el scoring de relevancia tipo keyword no es suficiente. Necesitas semántica.

Nivel 3: Búsqueda vectorial semántica con MemSearch

Este es el nivel que corro actualmente, y el nivel en el que recomiendo detenerte salvo que tengas una razón específica para ir más allá.

MemSearch es un sistema de memoria markdown-first lanzado por Zilliz, el equipo detrás de Milvus. Su propia descripción lo llama "una librería independiente para cualquier agente de IA, inspirada por OpenClaw". El plugin de Claude Code se sienta encima del CLI core, y la arquitectura es honesta sobre lo que es: una capa de retrieval híbrida sobre archivos markdown planos.

Aquí va lo interesante. MemSearch no reemplaza tus archivos de memoria. Los indexa. Tu memoria sigue viviendo como markdown legible para humanos — la puedes editar en cualquier editor de texto, versionarla en git, leerla en un avión sin internet. El índice vectorial es una caché. Según el post del blog de Milvus sobre MemSearch, el índice "se reconstruye desde Markdown en cualquier momento".

Tres capas de recall:

1. Hechos de largo plazo — conocimiento duradero. Reglas de voz de marca, políticas de seguridad, decisiones arquitectónicas.
2. Notas diarias — resúmenes de sesión con timestamp, ID de sesión, ID de turno. Texto plano. Totalmente legible para humanos.
3. Soñar / promoción — compactación periódica donde las notas de corto plazo se promocionan a hechos de largo plazo si demuestran ser duraderas.

El retrieval usa búsqueda híbrida — vectores semánticos para "encuentra contenido relacionado con esta query aunque el wording difiera", más BM25 para "encuentra contenido que use estas keywords exactas", fusionados con reranking Reciprocal Rank Fusion (RRF). Ese último bit es lo que vence a la búsqueda por keywords a escala. Cuando mi memoria tiene 400 chunks markdown a través de cuatro marcas, la búsqueda semántica encuentra la regla de voz de marca de colorpark.io aunque haya planteado mi prompt con palabras completamente distintas a las que usé en el archivo de memoria. La búsqueda por keywords se la pierde. Semántica + BM25 + RRF las captura ambas.

El retrieval también es por niveles, lo cual me encanta:

• L1 (automático): los top-3 resultados semánticos con previews, inyectados en cada prompt. Cubre la mayoría de casos de uso.
• L2 (bajo demanda): secciones markdown completas cuando se necesita el contexto entero.
• L3 (profundo): registros de conversación crudos cuando necesitas el diálogo exacto de una sesión pasada.

Para mí, L1 acierta en cerca del 90% de lo que necesito. L2 se dispara cuando estoy escribiendo algo denso y necesito el perfil completo de voz de una marca. L3 lo he usado quizá dos veces en dos meses — ambas para encontrar el wording exacto de la decisión de un cliente.

La configuración es la instalación de un plugin más un store vectorial (Milvus corre localmente; también puedes apuntarlo a uno gestionado). El coste es tu tiempo aprendiendo qué hace cada capa. La primera semana se siente sobreingenierizado. La segunda semana dejas de notarlo porque simplemente funciona.

Para quién es el nivel 3: Operadores con memoria acumulada sustancial — digamos 100+ archivos markdown, o un año de historial de sesiones, o flujos multi-marca como el mío. Founders en solitario corriendo un negocio AI-first. Cualquiera cuya configuración de nivel 2 haya empezado a perder la rebanada relevante en prompts complejos.

Dónde deja de ser suficiente: Cuando necesitas recall literal de conversaciones pasadas, no paráfrasis semánticamente similares. O cuando tu memoria necesita vivir en algún sitio que no sea tu portátil.

Aquí también es donde la mayoría de los operadores de contenido genuinamente debería detenerse. Probé los niveles 4, 5 y 6, y reverté al nivel 3 cada vez — porque la mejora marginal de recall no valía la pena ante la complejidad operativa para mi trabajo real, que es enviar artículos. Si tu trabajo es otra cosa, la matemática puede invertirse. Veamos cuándo.

Nivel 4: Recall literal con Memory Palace (RAG)

Aquí es donde la arquitectura de memoria empieza a parecer ingeniería de verdad, y donde deberías detenerte y preguntarte si de verdad la necesitas.

Un memory palace — a veces llamado Me Palace, MemPalace o memory palace RAG — es un sistema de Retrieval-Augmented Generation que almacena el texto exacto de la conversación en una estructura indexada simbólicamente. La metáfora es la antigua técnica mnemotécnica: tienes alas, habitaciones en esas alas, armarios en esas habitaciones y cajones en esos armarios. Cada cajón contiene un chunk literal específico. Los punteros indexan todo.

Los números publicados sobre las mejores implementaciones son reales: aproximadamente 42 ms de latencia de retrieval vía punteros indexados, con lo que sus autores afirman es el benchmark de recall publicado más alto en el espacio open-source de memoria. La arquitectura es típicamente SQL más DB vectorial — SQL para el índice estructurado de punteros, vectores para el match semántico. Local. Gratis. Autoalojable.

¿Por qué querrías esto? Porque la búsqueda semántica en el nivel 3 devuelve paráfrasis y resúmenes. Un memory palace devuelve las palabras exactas que alguien dijo, en el orden exacto, con la puntuación exacta. Para algunos flujos eso importa enormemente:

• Trabajo legal o de compliance — necesitas el wording literal de una cláusula.
• Notas de terapia o coaching — necesitas citar el fraseo real del cliente de vuelta hacia él.
• Transcripciones de investigación — necesitas citar exactamente lo que se dijo en la entrevista 47, no un resumen.
• RPGs de larga duración o proyectos de ficción — necesitas que el personaje recuerde lo que de hecho dijo en el capítulo 3.

¿Para mi flujo de contenido? No necesito recall literal. Cuando escribo un artículo sobre Claude Code, no necesito citar lo que dije sobre Claude Code hace seis meses — solo necesito la idea general. Así que un memory palace sería infraestructura cara a la que nunca recurriría.

Para quién es el nivel 4: Personas cuyo trabajo depende del wording exacto. Legal, médico, investigación, ciertos pipelines de escritura creativa, análisis voice-of-customer donde parafrasear destruye el dato.

Dónde se rompe: Cuando pasas más tiempo afinando la jerarquía del índice que usando el recall en sí. Los memory palaces tienen un impuesto de mantenimiento real — ahora estás corriendo una pequeña base de datos, y las bases de datos necesitan cuidado.

Nivel 5: Base de conocimiento interconectada (LLM Wiki)

Este es el nivel que más hype recibe porque Andrej Karpathy lo mencionó. También es el nivel más a menudo mal aplicado.

El patrón, originalmente del gist de Karpathy sobre arquitectura de LLM Knowledge Base, es: en lugar de hacer RAG en query-time, tienes a un LLM compilando tus fuentes entrantes — artículos, podcasts, transcripciones, PDFs — en una wiki markdown persistente y navegable. La síntesis ocurre una sola vez al ingerir. Después, cada retrieval es solo leer una página acabada. Como VentureBeat lo resumió, el LLM actúa como un "bibliotecario de investigación a tiempo completo, compilando, lintando e interconectando archivos markdown de forma activa".

Dos carpetas:

• raw/ — inputs de solo lectura. Transcripciones, artículos, notas crudas. Nunca modificados.
• wiki/ — gestionada por la IA. Páginas de síntesis estilo enciclopedia con backlinks entre conceptos.

Puedes visualizar el conjunto en Obsidian, que renderiza la wiki markdown como un grafo de conocimiento navegable — cajas conectadas por líneas, el tipo de cosa que se ve preciosa en un screenshot y es genuinamente útil si tu trabajo es investigación.

Existen varias implementaciones comunitarias. El plugin OpenClaw memory-wiki compila la memoria del workspace en un directorio wiki con un catálogo índice, páginas de síntesis por módulo y digests legibles por máquina. Hay una Agent Skill estilo Karpathy de LLM wiki para OpenClaw y Codex. Hay obsidian-wiki, un framework para que agentes de IA construyan y mantengan una wiki Obsidian usando el patrón de Karpathy.

Es arquitectura preciosa. También está mal para memoria operativa de proyecto. Aquí va por qué.

Una wiki es una referencia estática. Está optimizada para "quiero leer sobre X". Pero la memoria operativa de proyecto necesita responder "¿cuál era la regla sobre X?" o "¿qué decidimos sobre X el sprint pasado?". Ese es un patrón de acceso distinto. Intentar usar una LLM wiki como tu memoria operativa es como usar una enciclopedia como tu lista de tareas — técnicamente posible, profundamente desencajado.

Para qué es buena una LLM wiki: proyectos de investigación profunda. Construir una base de conocimiento real a partir de fuentes que ingieres con el tiempo. Organización de contenido donde estás sintetizando un tema a través de docenas de inputs y quieres un artefacto navegable al final. He considerado construir una para todo el archivo de mejba.me — 230+ artículos sintetizados en una wiki Karpathy — puramente como artefacto de investigación para mi propia escritura futura. No he apretado el gatillo porque el coste de síntesis upfront es real y aún no estoy seguro de que el payoff lo justifique.

Para quién es el nivel 5: Investigadores. Knowledge workers construyendo sobre grandes corpus de fuentes. Escritores haciendo síntesis profunda de temas. Educadores construyendo materiales de curso. Gente que se beneficiaría de un grafo Obsidian de su propio pensamiento.

Dónde se rompe: Como memoria operativa de proyecto. No uses una wiki para eso. Usa el nivel 2 o 3.

Nivel 6: Memoria unificada entre herramientas (Open Brain / Mem.ai)

El nivel final, y el que rompe la frontera del portátil.

La premisa: tu memoria no debería estar atada a una sola herramienta. Si le preguntas algo a Claude el lunes, luego le preguntas a ChatGPT una pregunta relacionada el martes, luego escribes código en Cursor el miércoles — los tres deberían tirar del mismo store de memoria. Un cerebro. Muchas caras.

Dos sabores principales en 2026:

Hosted (Mem.ai, Mem0, Zep, MemPalace): Memoria cross-tool lista para producción como servicio. Según el pricing de Mem0, el tier gratuito cubre 1.000 memorias al mes, los planes de pago empiezan en 19 $/mes para 10K memorias y la memoria de grafo está restringida tras un plan Pro de 249 $/mes. Su cobertura de integraciones recorre 21 frameworks y plataformas en Python y TypeScript. Esto es ahora infraestructura madura — no un side project.

Self-hosted (Open Brain, Postgres + pgvector custom): Misma arquitectura, te perteneces tú. Postgres (a menudo vía Supabase, que provee pgvector de fábrica) almacena chunks más embeddings. Más barato a escala porque pagas costes de infraestructura, no precios por memoria. Más control. Más setup. Más cosas que tienes que mantener.

Cualquier sabor añade memoria compartida en tiempo real entre Claude Desktop, Claude Code, ChatGPT, Cursor y cualquier herramienta con un servidor MCP o un hook de API. Esa es la magia. Pregúntale a Claude sobre una decisión de proyecto; más tarde, en Cursor, la generación de código ya lo sabe.

Las trampas no son teóricas:

1. Latencia. Una llamada de red a un store de memoria remoto añade 100-500 ms por retrieval. En un prompt rápido está bien. En un loop apretado con retrievals frecuentes, se nota.
2. Dependencia externa. Memoria hosted significa confiar tu contexto a un vendor. Self-hosted significa hacer de niñera de una base de datos.
3. Conflictos de sync. Dos herramientas escribiendo en la misma memoria al mismo tiempo crea problemas de merge que ninguna arquitectura ha resuelto del todo.
4. Superficie de privacidad. Lo que viva en tu memoria unificada es ahora alcanzable desde cada herramienta que has conectado. Esa es la feature. También es el riesgo.

Para quién es el nivel 6: Power users corriendo flujos genuinamente multi-herramienta. Ingenieros que cambian de contexto entre Claude, ChatGPT y Cursor varias veces al día. Equipos donde el trabajo asistido por IA cruza fronteras de herramientas constantemente. Cualquiera corriendo un pipeline real de "segundo cerebro" que ya se extiende más allá de una sola IA.

Dónde se rompe: Para la mayoría de operadores en solitario, el impuesto de latencia y complejidad pesa más que la conveniencia cross-tool. Probé tanto el tier hosted de Mem0 como una configuración Supabase + pgvector. Ambos funcionaron. Ambos añadían 200-300 ms a cada prompt. Ambos requerían atención que prefiero gastar escribiendo.

Cómo elegir tu nivel sin quemar un fin de semana

Aquí va el framework de decisión que le entregaría a mi yo del pasado antes de aquel martes roto.

Empieza en el nivel 1. Envía algo. Mira qué se rompe. Las dos preguntas que importan: ¿claude.md ha pasado de 200 líneas? ¿Estás manteniendo las mismas reglas core en múltiples proyectos?

Pásate al nivel 2 cuando la respuesta a cualquiera de las dos preguntas sea sí, o cuando lleves más de un mes en Claude Code y tu memoria haya crecido claramente más allá de lo que un solo archivo debería contener. Estructura de carpetas más hook de inicio de sesión. Una tarde.

Pásate al nivel 3 cuando el nivel 2 empiece a perder la rebanada de memoria correcta en prompts complejos, o tu memoria cruce los ~100 chunks markdown. Plugin MemSearch, retrieval híbrido. Un día de configuración. Aquí es donde se asienta la mayoría de operadores serios.

Considera el nivel 4 solo si tu trabajo depende del wording literal — legal, médico, investigación, voice-of-customer. No construyas un memory palace porque suena cool.

Considera el nivel 5 solo si estás haciendo síntesis profunda de investigación a través de muchas fuentes y quieres un artefacto navegable. No es memoria operativa. Es un producto de conocimiento.

Considera el nivel 6 solo si ya estás cambiando de contexto entre tres o más herramientas de IA a diario y la brecha de memoria entre ellas está hiriendo activamente tu trabajo. De lo contrario, el impuesto de latencia no vale la pena.

El patrón: cada nivel por encima del que necesitas es fricción. Cada nivel por debajo del que necesitas es fuga. El sweet spot es el nivel más bajo que maneja tu carga de trabajo real, no el más alto del que tus pares presumen.

Para mí — contenido multi-marca a escala, corriendo @aria en cuatro marcas, a veces coordinando con stacks de skills como los que desglosé en mi post sobre el stack de skills de Claude Code y las mejores skills de Claude Code para eficiencia de negocio — el nivel 3 es donde las cuentas salen. El recall literal no cambia mi salida. La memoria unificada cross-tool tampoco, porque @aria es un agente de Claude Code que vive en una sola herramienta. Así que me quedo en el nivel 3, ahorro el impuesto de ingeniería y envío más artículos.

Si tus cuentas son distintas, sube. Si no, no.

Lo que le diría a quien empezara hoy

La cosa que subestimé, antes del martes roto y la reconstrucción que siguió, es que la memoria es leverage, pero solo en el nivel que encaja con tu trabajo. El nivel 1 es leverage suficiente para la mayoría de la gente. El nivel 3 es leverage suficiente para casi todos los demás. Los niveles restantes existen para formas específicas de trabajo, y tratarlos como objetivos aspiracionales es como pierdes tardes.

Lo que me ayudó a pensarlo correctamente fue mirar cómo evolucionó realmente el ecosistema. El repo memsearch se inspiró en OpenClaw, que se construyó sobre patrones comunitarios, que se construyeron sobre la primitiva original claude.md de Anthropic. Cada nivel envuelve al de abajo. Nada de esto reemplaza la capa subyacente — solo añade. Eso significa que siempre puedes subir más tarde. No pierdes nada empezando pequeño. Solo pierdes tiempo cuando empiezas grande y no encaja.

Si estuviera empezando con Claude Code hoy, sabiendo lo que ahora sé, haría exactamente esto:

1. Abre un proyecto. Escribe claude.md. Mantenlo bajo 200 líneas. Úsalo durante una semana.
2. Fíjate en qué falta. Añádelo. Capa la longitud del archivo en el momento en que amenace las 200.
3. Tras un mes, divide en una carpeta de memoria con cubos general / domain / tool. Añade un hook de inicio de sesión.
4. Tras tres meses, si tu memoria ha sobrepasado claramente el retrieval por keywords, instala MemSearch.
5. Detente. Reevalúa solo si un flujo específico lo demanda.

Ese es el camino. Es aburrido. Funciona. Es como corro una operación de contenido multi-marca sobre una capa de memoria que cabe en un solo repo y se reconstruye desde markdown.

El martes en que intenté saltarme esos pasos me costó una tarde de trabajo. El martes siguiente, con el nivel 3 realmente afinado, @aria envió cuatro artículos a la primera. Mismo agente. Mismo modelo. Arquitectura de memoria distinta, dimensionada al trabajo real.

Elige el nivel que tu trabajo demanda. No el nivel que el hilo te dijo que corrieras.

Preguntas frecuentes

¿Cuál es la diferencia entre claude.md y memory.md en Claude Code?

claude.md es un archivo de instrucciones a nivel de proyecto que escribes manualmente — contiene reglas, convenciones y guía estable cargada al inicio de la sesión. memory.md es auto-memoria, donde el propio Claude guarda notas a partir de correcciones y preferencias entre sesiones. Tú eres el autor de uno; Claude mantiene el otro. Ambos cargan juntos en el contexto.

¿Cómo prevengo la putrefacción de contexto en claude.md?

Mantén claude.md por debajo de unas 200 líneas, luego divide en una carpeta de memoria con cubos general, domain y tool. Usa un hook de inicio de sesión para inyectar solo la rebanada relevante en el contexto por sesión. Los archivos de memoria monolíticos largos hacen que el modelo lea por encima en vez de leer, que es la causa raíz de la putrefacción de contexto.

¿Es MemSearch mejor que la memoria básica de Claude Code?

MemSearch supera a la memoria básica una vez que tu conocimiento acumulado pasa de unos 100 chunks markdown, porque el retrieval híbrido semántico + BM25 encuentra contexto relevante que la carga solo por keywords se pierde. Para configuraciones más pequeñas por debajo de ese umbral, añade complejidad sin mejora significativa. La mayoría de operadores no lo necesitan en sus primeros tres meses.

¿Qué es un memory palace en flujos de IA?

Un memory palace es un sistema RAG que almacena el texto exacto y literal de la conversación en una estructura indexada simbólicamente — típicamente alas, habitaciones, armarios y cajones — usando SQL más una base de datos vectorial para retrieval. Está optimizado para recall de wording exacto, no de significado parafraseado. Útil para flujos legales, médicos o de investigación donde el fraseo exacto importa.

¿Debería usar Mem.ai o construir mi propia memoria cross-tool?

Usa Mem.ai o Mem0 si quieres memoria hosted lista para producción y no quieres mantener infraestructura — el pricing empieza en 19 $/mes para 10K memorias en Mem0. Construye la tuya con Supabase más pgvector si necesitas propiedad total del dato, costes predecibles a escala y te sientes cómodo manteniendo una base de datos. La mayoría de operadores en solitario no necesitan ninguno de los dos tiers.

Trabajemos juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tech? Me encantaría ayudar.

• Fiverr (builds e integraciones a medida): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones enterprise): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io