El problema de la amnesia: por qué la memoria es el verdadero cuello de botella de la IA agéntica

En 2026 se ha convertido en un estándar utilizar herramientas de codificación agénticas como Claude Code, Cursor, Windsurf, OpenCode o Codex.

Si usas un IDE agéntico para programar en 2026, probablemente tengas un archivo CLAUDE.md o un AGENTS.md en la raíz de tu proyecto. Estos archivos actúan como ficheros README pero para agentes proporcionándole contexto e instrucciones habitualmente asociados a un proyecto.

Con esto tendríamos lo básico. Estaríamos listos para empezar a trabajar.

Para subir de nivel lo siguiente sería preparar skills y hooks. Las skills son una mecanismo que le proporciona nuevas habilidades a nuestros agentes. En su configuración más sencilla una skill es un fichero en formato markdown pero también puede contener scripts, plantillas, documentación, etc. La clave de las skills es que nos permite compartir conocimiento experto de un dominio (ya sea de nuestra propia empresa o una forma concreta de hacer las cosas) con los agentes. Si volvemos a nuestro proyecto donde tenemos un AGENTS.md, podríamos incluir una skill asociada a nuestro proyecto sobre cómo se opera, cómo se realiza el mantenimiento o cómo se observa. Y si damos atrás y hacemos zoom-out podemos usar las skills para establecer habilidades que apliquen a todos nuestros proyectos. En Éutika usamos skills globales para el hardening de servidores o para establecer los flujos de trabajo que queremos aplicar a todos los proyectos.

Los hooks nos permiten intervenir antes o después de que el agente haga algo (suceda un evento). Un ejemplo muy sencillo es que se ejecute un hook de pre-commit donde, antes de realizarse un commit, se ejecute un linter sobre los archivos que se han modificado y si hay errores se aborte el commit. Otro uso habitual es usarlo a modo de auditoría para registrar las acciones del agente o para prevenir que el agente ejecute comandos peligrosos.

Quizá hayas definido reglas de estilo, convenciones de naming, instrucciones sobre qué frameworks usar y cuáles evitar. Puede que incluso apliques progressive disclosure: un archivo raíz con lo esencial y archivos más específicos en subdirectorios que el agente descubre solo cuando los necesita. Skills, hooks, memoria automática.

Funciona. Pero si lo piensas, lo que estás haciendo es escribir manualmente la memoria de tu agente. Eres tú quien decide qué debe recordar, tú quien estructura ese conocimiento, tú quien lo mantiene actualizado. El agente no está aprendiendo. Eres tú quién manualmente está construyendo su memoria. Y eso es difícil de escalar y mantener.

Lo que percibimos como memoria

Claude Code tiene su sistema de memoria automática que persiste entre sesiones, lee archivos CLAUDE.md por proyecto y por directorio, y compacta el contexto cuando la conversación crece demasiado. Cursor y Windsurf mantienen sus propios mecanismos de indexación y reglas personalizables. OpenCode inyecta contexto explícito a través de menciones y plugins MCP. Además,se puede intervenir antes y después de cada ejecución del agente mediante hooks.

Y sin embargo el problema de fondo persiste: los LLMs no tienen memoria nativa. Cada sesión arranca desde cero, y lo que percibimos como “memoria” es una combinación de archivos de configuración escritos por humanos e inyección de contexto previa a cada llamada al modelo.

Tres niveles de memoria

Para entender qué falta, vale la pena distinguir tres tipos de memoria en un sistema agéntico.

La memoria declarada es lo que tú le dices al agente que recuerde: tu CLAUDE.md, tus skills, tus archivos de instrucciones por directorio. Es explícita y estática, y depende enteramente de ti. Funciona bien a escala individual, pero cuando trabajas en varios proyectos o con equipos grandes, mantener esa documentación al día se convierte en una tarea en sí misma.

La memoria inyectada es el contexto que el sistema recupera automáticamente antes de cada interacción: RAG, indexación del proyecto, compactación de sesiones anteriores, la memoria automática que Claude Code guarda en ~/.claude/. Es más escalable, pero tiene sus propios límites. La calidad de lo que se recupera depende del algoritmo de búsqueda, la ventana de contexto sigue siendo finita, y meter demasiado contexto puede degradar la atención del modelo tanto como meter poco.

La memoria aprendida es el nivel que todavía no existe de forma robusta. Un agente que después de ver cómo resuelves el mismo problema diez veces internaliza tu estrategia sin que se lo expliques. Detecta que siempre rechazas cierto tipo de sugerencias y deja de hacerlas. Construye un modelo del proyecto que evoluciona con el código, no con tus notas manuales.

La mayor parte de la industria opera entre los dos primeros niveles. El tercero es donde está la investigación más interesante, y donde se concentran los retos que voy a explorar en esta serie.

El coste que normalizamos

Las técnicas actuales funcionan. El problema es que tienen un coste que no siempre consideramos.

Un CLAUDE.md o un AGENTS.md desactualizado es peor que no tener uno. He visto agentes intentar usar dependencias que el equipo eliminó hace semanas porque el archivo de instrucciones no se actualizó. El agente hacía exactamente lo que le habías dicho; el problema es que lo que le habías dicho ya no era verdad.

El coste de transferencia de conocimiento también debe tenerse en cuenta. El uso de skills nos permite condensar nuestra forma de trabajar, nuestro contexto, incluso parte de nuestra cultura para que los agentes se comporten como esperamos. Pero al igual que sucede con los AGENTS.md, mantener estas skills requiere constante atención y actualización.

Y las sesiones de trabajo con agentes que se prolongan son también problemáticas. La compactación descarta detalle para retener lo esencial, pero “esencial” lo decide el modelo, y no siempre acierta. Un agente que lleva dos horas de sesión intensa puede olvidar un requisito que mencionaste al principio, aunque técnicamente siga en su contexto compactado.

Cuando son varios agentes

El problema se multiplica cuando pasamos de un agente individual a sistemas multi-agente, los llamados swarms o enjambres. Ya no se trata solo de que un agente recuerde lo que hizo. Se trata de que varios agentes trabajando en paralelo mantengan una visión coherente del estado del sistema.

Los retos que aparecen recuerdan a los problemas clásicos de sistemas distribuidos: escrituras concurrentes, conflictos de estado, sincronización. Pero aquí los conflictos no son colisiones de bytes sino contradicciones semánticas. Un agente puede haber registrado que la base de datos usa PostgreSQL mientras otro apuntó que se migró a DynamoDB la semana pasada. Resolver esa disonancia requiere mecanismos que van bastante más allá de un bloqueo de escritura.

Por qué esto importa

Si ya usas CLAUDE.md, progressive disclosure y skills, probablemente hayas llegado a las mismas conclusiones que yo: funcionan, pero notas sus límites. Son andamios útiles y necesarios, pero andamios sobre una limitación arquitectónica que la industria sigue intentando resolver.

Y si tomas decisiones técnicas sobre qué herramientas adoptar, entender las arquitecturas de memoria subyacentes importa tanto como la calidad del modelo base. Un modelo excelente con mala memoria rinde peor en la práctica que un modelo bueno con un andamiaje bien diseñado.

En los próximos artículos voy a explorar cómo se está resolviendo esto: cómo funcionan las técnicas de compactación por dentro, qué hacen herramientas como Hermes con capas de memoria explícitas, qué es autoDream y por qué un agente que “sueña” para consolidar memoria no es una metáfora sino una descripción técnica bastante literal.