Lo más frustrante de programar con un asistente de IA es lo mal que mantiene el contexto entre sesiones: su memoria de una sesión a otra es la de un pez. Pasas la tarde con Claude Code resolviendo una refactorización complicada: eliges un enfoque, descartas otros dos por buenas razones, acuerdas una convención de nombres. Cierras la terminal. Vuelves tres días después y el asistente es una hoja en blanco. Te vuelve a proponer justo el enfoque que ya habías descartado, porque no tiene ni idea de que esa conversación existió.
A esto se le llama degradación del contexto (o context rot), y no es un error que puedas parchear. Cada sesión es un proceso nuevo con una ventana de contexto nueva. Lo que hace falta es una forma de mantener contexto entre sesiones — memoria real que sobreviva de una sesión a la siguiente — y la buena noticia es que puedes construirla por capas. Este artículo describe el patrón que uso de verdad, explicado para que lo repliques con las herramientas que prefieras.
Por qué una ventana de contexto más grande no evita perder el contexto entre sesiones
La suposición fácil es “usa un modelo con una ventana de contexto más grande”. Eso ayuda dentro de una misma sesión — puedes tener más código a la vista a la vez — pero no hace nada entre sesiones. Cuando el proceso se reinicia, esa ventana enorme vuelve a empezar vacía. Tendrías que volver a pegar todo tu historial cada mañana, algo caro y que, siendo sinceros, dejarás de hacer para el miércoles.
La otra mitad del problema es que el historial en bruto no es lo mismo que recordar. Aunque pudieras meter tres meses de conversaciones en un solo prompt, el asistente se ahogaría en vez de recordar. Lo que realmente quieres es recuperación: poder preguntar “¿qué decidimos sobre el flujo de autenticación en mayo?” y recibir los dos párrafos que importan, no el pajar donde están escondidos.
Así que la solución real son dos cosas trabajando juntas: guardar de forma duradera lo que importa, y recuperar barato la parte correcta en el momento correcto. Yo lo divido en tres capas.
Capa 1: Un índice de archivos versionado para los hechos permanentes
La capa base es la menos ingeniosa y la más confiable: un archivo markdown normal, versionado en git, que se carga al inicio de cada sesión.
Claude Code lee un CLAUDE.md (y un pequeño índice de memoria junto a él) de forma automática al arrancar una sesión. Así que mantengo un archivo corto y cuidado con los hechos permanentes — las cosas que deberían ser ciertas en todas las sesiones, para siempre, hasta que yo las cambie:
- Decisiones ya cerradas (“usamos Bun, no npm; y por esta razón”).
- Preferencias (“crea una rama primero, nunca hagas commit directo a main”).
- Convenciones (“el idioma por defecto es el español; el inglés vive bajo
/en/”). - Reglas estrictas (“nunca añadas una línea
Co-Authored-Bya los commits”).
La disciplina está en mantenerlo corto y curado, no en convertirlo en un cajón de sastre. Este archivo se carga en todas las sesiones, así que cada línea cuesta contexto en cada ejecución futura. Si crece hasta ser un muro de texto, el asistente lo lee por encima y vuelves al punto de partida. Lo trato como un README para el agente: las diez cosas que jamás debe olvidar, y nada más.
Como vive en git, es revisable, comparable y se revierte como cualquier otro archivo. Cuando una decisión cambia, edito la línea y el cambio queda en el historial. Es la misma lógica de fondo que aplico al aprender a programar: lo permanente se anota en un lugar donde puedes verlo cambiar. Si estás empezando, escribí aparte sobre la mejor forma de aprender a programar, y este hábito de dejar por escrito lo que decides es parte de él.
Capa 2: Un segundo cerebro semántico para las decisiones viejas
El índice de archivos es genial para las diez cosas que siempre son ciertas. Es inútil para las mil cosas que fueron ciertas una vez — el razonamiento detrás de una decisión de hace seis semanas, el callejón sin salida que exploraste el mes pasado, el motivo por el que un valor de configuración es exactamente ese número.
Para eso sirve el segundo cerebro. La idea: tomar tu código más tus notas de sesiones pasadas e indexarlo con embeddings, para poder consultarlo en lenguaje natural. No un grep por palabra clave, sino búsqueda semántica. Preguntas “¿cómo terminamos manejando los límites de peticiones?” y encuentra las notas y el código relevantes aunque ninguno contenga literalmente esa frase.
Yo uso una herramienta llamada gbrain para esto, pero lo importante es el patrón, y tiene tres partes:
- Indexar todo lo que valga la pena recordar — los archivos de código, y notas breves que escribes al cerrar sesiones importantes (“decidí X por Y; descarté Z”).
- Consultarlo en lenguaje natural — recuperación que ordena por significado, para que una pregunta redactada de forma muy distinta a la nota original igual la encuentre.
- Exponerlo al agente vía MCP para que pueda buscar en su propia memoria a mitad de una tarea, sin que tú hagas de bibliotecario.
Ese tercer punto es el que cambia cómo se siente trabajar así. MCP (el Model Context Protocol) es simplemente una forma estándar de darle a un asistente un conjunto de herramientas que puede invocar por su cuenta. Conecta tu segundo cerebro como una de esas herramientas y Claude Code puede detenerse a mitad de una tarea, decidir que necesita saber a qué conclusión llegaste sobre algo el mes pasado, consultar el cerebro él mismo y seguir adelante. Dejas de ser tú la memoria — el agente recupera de su propio historial.
No tienes que usar mi stack exacto. Cualquier almacén basado en embeddings que puedas consultar en lenguaje natural y exponer por MCP sirve. Lo que gana su lugar es la combinación: recuperación más allá de la búsqueda por palabra clave, sobre todo tu historial, invocable por el agente sin ti en medio. Si estás armando un conjunto de herramientas para este tipo de trabajo, conté aparte cómo es mi stack de desarrollo con IA y Claude Code.
Capa 3: Punteros de sesión para cerrar el círculo
El índice de archivos guarda los hechos permanentes. El segundo cerebro guarda las decisiones viejas. El último hueco es el más mundano: cuando me vuelvo a sentar, ¿dónde exactamente lo dejé?
Eso lo resuelve un puntero de sesión. Al terminar una sesión guardo un puntero pequeño — nada dramático, solo el estado actual:
- La rama en la que estaba.
- El directorio de trabajo.
- Los últimos commits.
- El estado del árbol de trabajo (en staging, sin staging, sin seguimiento).
Después, un hook de inicio inyecta ese puntero al arrancar la sesión siguiente: aquí es donde lo dejaste. Y, lo más importante, lo primero que hago es orientarme desde git — git log, git status, git diff, los PRs abiertos — antes de tocar nada. El puntero le dice al asistente qué cajón abrir; git le dice qué hay realmente dentro en este momento.
Esta capa es barata y rinde de inmediato. Sin ella, cada sesión empieza con cinco minutos de “¿en qué estaba yo?”. Con ella, el asistente arranca sabiendo ya la rama, el trabajo reciente y los cambios sin confirmar — y se reorienta desde el repositorio vivo en lugar de desde un resumen viejo.
El ángulo que hace esto relevante hoy: la memoria nativa no es recuperación semántica
Aquí está la parte que vale la pena pensar, porque cambió hace poco. Los agentes modernos — Claude Code incluido — ya traen memoria nativa: pueden guardar notas entre sesiones por su cuenta. Así que es justo preguntarse si todo lo anterior sigue haciendo falta.
Sí hace falta, porque son trabajos distintos:
- La memoria nativa es ideal para el hilo activo — el conjunto de trabajo del esfuerzo actual, arrastrado un poco hacia adelante para no repetirte de una sesión a otra.
- El índice de archivos es ideal para los hechos permanentes — las decisiones y reglas cerradas que quieres revisar en git y cargar textualmente cada vez, no resumidas a criterio del modelo.
- El cerebro semántico es ideal para las decisiones viejas — recuperación a lo largo de meses de historial que ninguna memoria de tamaño fijo puede contener, ordenada por significado y no por lo reciente.
La memoria nativa no es recuperación semántica sobre todo tu historial. Una es un bloc de notas corto que va evolucionando; la otra es memoria de largo plazo que se puede buscar. El movimiento no es elegir una — es combinarlas por capas. Deja que la memoria nativa lleve el hilo activo, que el índice de archivos ancle los hechos permanentes, y que el segundo cerebro responda “¿qué decidimos sobre X, allá lejos?”. Cada capa cubre lo que las otras no pueden.
La conclusión
Nunca vas a hacer desaparecer la degradación del contexto — cada sesión sigue siendo un proceso nuevo. Lo que sí puedes hacer es lograr que no importe, dándole al asistente un lugar duradero donde mantener contexto entre sesiones y una forma barata de recuperar la parte correcta cuando la necesita.
Empieza por la capa que casi no cuesta nada: un archivo corto, curado y versionado en git con los hechos permanentes, que se carga al inicio de cada sesión. Añade punteros de sesión para que cada sesión arranque sabiendo dónde se detuvo la anterior. Y luego, cuando tu historial crezca más allá de lo que cualquier archivo puede contener, añade un cerebro semántico para que el agente busque en su propio pasado en lenguaje natural. Tres capas, cada una haciendo el único trabajo en el que de verdad es buena — y un asistente que por fin recuerda por qué tomaste las decisiones que tomaste.
