Claude Code olvida todo: cómo darle memoria persistente

El problema que nadie menciona cuando usas agentes de IA en proyectos reales

Hay un patrón que se repite en casi todos los equipos que empiezan a trabajar con agentes de IA como Claude Code: los primeros días son mágicos, la productividad sube, todo parece funcionar. Y entonces, a las dos semanas, alguien nota que el agente repite los mismos errores que ya habían corregido, ignora reglas que habían definido con cuidado, o simplemente actúa como si fuera su primer día en el proyecto.

El problema no es el modelo. El problema es la memoria, o más exactamente, la falta de ella. Por defecto, Claude Code no recuerda nada entre sesiones. Cada vez que abres una nueva conversación, el agente empieza desde cero. Sin contexto del proyecto, sin reglas de deployment, sin el historial de decisiones técnicas que tu equipo construyó durante semanas.

Tom Tokita, desarrollador y cofundador de una consultora tecnológica, documentó en detalle cómo resolvió este problema construyendo un servidor MCP con memoria persistente para Claude Code. Sus hallazgos son técnicamente valiosos, pero lo más interesante no es la solución en sí, sino los problemas secundarios que descubrió al implementarla, problemas que cualquier equipo que trabaje con IA en producción va a enfrentar tarde o temprano.

Memoria persistente: más complejo de lo que parece

La solución inicial de Tokita fue indexar el conocimiento del proyecto en una base de datos vectorial. Reglas de negocio, configuraciones de plataforma, errores pasados, decisiones de arquitectura. Al iniciar cada sesión, Claude consulta esa memoria antes de hacer cualquier cosa. El principio es claro: verificar lo que ya sabes antes de adivinar.

Para la búsqueda usó un enfoque híbrido, combinando búsqueda semántica por similitud vectorial con búsqueda por palabras clave exactas. La razón es práctica: la búsqueda semántica sola tiende a retornar resultados conceptualmente relacionados pero que no contienen el valor exacto que necesitas, como un comando específico o una variable de configuración. El keyword matching resuelve ese gap.

Pero aquí apareció el primer problema inesperado: cuando la memoria funciona demasiado bien, retorna demasiado contenido. En un caso documentado, una sola operación de búsqueda retornaba más de 200,000 caracteres de contexto, un payload que literalmente no cabe en la ventana de tokens de Claude. El agente se bloqueaba antes de leer el primer resultado.

La solución fue agregar una capa de condensación: los resultados pasan primero por un modelo más ligero que los resume antes de enviárselos a Claude. Doscientas mil palabras se comprimen a unos pocos miles. El agente recibe la respuesta sin el ruido. Tokita admite que esta debería haber sido la primera cosa que construyó, no la cuarta.

El olvido dentro de la misma sesión: el problema que más cuesta

Hay un comportamiento de Claude Code que muy poca gente menciona y que puede generar fallos serios en producción: el agente también olvida dentro de la misma sesión. Cuando la ventana de contexto se llena, el sistema comprime los mensajes más antiguos en un resumen automático. En teoría es eficiente. En la práctica, las reglas que cargaste al inicio de la sesión pueden desaparecer silenciosamente a las dos horas de trabajo.

Tokita describe el caso concreto: reglas de deployment que Claude había cargado al iniciar la sesión quedaban comprimidas en el historial, y el agente terminaba desplegando paquetes al entorno equivocado porque ya no recordaba las restricciones originales. Los fallos eran silenciosos, lo que los hacía especialmente costosos de diagnosticar.

Su solución fue que el servidor detecte cuando Claude llama al cargador de sesión por segunda vez en la misma conversación, interpretándolo como una señal de que el contexto fue comprimido. En ese caso, el servidor incluye una pista de recuperación con el proyecto más reciente activo, y Claude recarga quirúrgicamente solo el contexto relevante para la tarea actual, no toda la base de conocimiento.

Otro componente valioso fue el compliance checking: en lugar de pedirle a Claude que recuerde una regla mediante un prompt, el servidor valida las acciones propuestas contra un conjunto de reglas predefinidas antes de ejecutarlas. La diferencia entre pedirle a alguien que recuerde un checklist y colocar ese checklist como puerta obligatoria antes de continuar. Las instrucciones en el prompt pueden olvidarse. Una validación en el servidor no.

Cómo aplica esto en empresas de Perú y Latinoamérica

En Consultoría-Ti trabajamos con equipos de desarrollo y empresas que están integrando IA en sus flujos de trabajo, desde automatizaciones con n8n y Claude API hasta agentes que interactúan con sistemas ERP como Odoo. Y el patrón que describe Tokita lo vemos constantemente: los equipos adoptan el agente, lo configuran bien en la primera semana, y luego asumen que ese comportamiento se mantiene solo.

No se mantiene solo. La memoria de los agentes necesita infraestructura igual que cualquier otro componente de software. Si tu equipo está usando Claude Code u otro agente de IA para tareas de desarrollo, soporte técnico, o automatización de procesos, estas son las preguntas que deberían hacerse hoy:

  • ¿Dónde vive el contexto del proyecto? Si solo existe en el prompt inicial de cada sesión, es frágil.
  • ¿Qué pasa cuando la sesión dura más de dos horas? Si nadie lo ha probado, probablemente el agente está perdiendo restricciones importantes sin que nadie lo note.
  • ¿Cómo se aplican las reglas de negocio críticas? Si solo están en instrucciones de texto, no en validaciones de infraestructura, son sugerencias, no restricciones.
  • ¿El conocimiento que genera el agente se acumula? Cada error corregido, cada decisión técnica tomada, debería ser recuperable en la siguiente sesión.

Para empresas medianas en la región que están evaluando implementar agentes de IA en procesos de desarrollo o gestión, la lección más importante de este caso es que la infraestructura de memoria no es un detalle técnico, es parte del diseño del sistema. Ignorarla genera exactamente el tipo de fallos silenciosos que erosionan la confianza en la herramienta.

¿Cómo aplica esto en tu empresa?

Si estás usando o evaluando agentes de IA para desarrollo de software, automatización de procesos, o soporte técnico en tu empresa, el artículo de Tokita ofrece una hoja de ruta práctica. Antes de escalar el uso de cualquier agente, vale la pena diseñar tres cosas con anticipación.

Primero, una capa de memoria persistente que sobreviva entre sesiones. No tiene que ser un servidor MCP propio desde el día uno, puede empezar con algo tan simple como un archivo de contexto estructurado que el agente lee al iniciar. Lo importante es que exista y que se actualice.

Segundo, un mecanismo de condensación para cualquier base de conocimiento que crezca. Si tu agente va a tener acceso a documentación técnica, reglas de negocio, o historial de decisiones, necesitas controlar cuánto contexto se carga en cada llamada. Más contexto no siempre es mejor contexto.

Tercero, validaciones de infraestructura para reglas críticas. Si hay acciones que el agente nunca debería ejecutar sin aprobación, esa restricción no debería vivir en un prompt. Debería estar en una capa de validación que el agente no pueda saltarse por compresión de contexto.

Estos tres elementos no requieren construir un servidor MCP completo desde cero. Requieren pensar en el agente como un sistema con estado, no como un chat que responde preguntas.

Conclusión

La amnesia de los agentes de IA no es un bug que Anthropic va a corregir en la próxima versión. Es una característica del diseño actual de los modelos de lenguaje, y la solución viene del lado de la infraestructura, no del modelo. Los equipos que entiendan esto antes tendrán una ventaja real: sus agentes acumulan conocimiento operativo en lugar de reiniciarlo cada día.

El caso de Tokita es una demostración concreta de que construir esa infraestructura es alcanzable, pero también de que tiene sus propias complejidades. La condensación, el manejo del contexto mid-session, y el compliance checking no son optimizaciones opcionales. Son requisitos para que un agente de IA funcione de manera confiable en proyectos reales.

En Consultoría-Ti ayudamos a empresas en Perú y Latinoamérica a integrar herramientas de inteligencia artificial en sus procesos de desarrollo y gestión, incluyendo el diseño de arquitecturas que hacen que esos agentes sean confiables y escalables. Si tu equipo está evaluando cómo implementar IA de manera robusta, conversemos.

📩 Contáctanos en consultoria-ti.com y cuéntanos en qué etapa está tu proyecto.

Fuentes y Referencias

Tom Tokita — Claude Code Forgets Everything. So I Built It a Memory Server. (Dev.to)



✨ Contenido generado con ContentFlow — Consultoría-Ti

Compartir
Etiquetas
AI Gateway vs MCP Gateway vs Agent Gateway: diferencias clave