Arquitectura de memoria de agentes de Anthropic: cuatro capas, el dreaming y un fallo con 413 archivos (nov. 2026)

¿Qué publicó Anthropic?

El 6 de noviembre de 2026, Anthropic publicó The components of agent memory, un artículo de investigación de Lance Martin sobre cómo Claude traslada conocimiento de una sesión a la siguiente. No es el anuncio de un producto. Describe una arquitectura de memoria que ya funciona dentro de Claude Code y dedica más o menos tanto espacio a lo que falla como al diseño.

El artículo fija primero un límite. Hay tres cosas que se llaman memoria y no lo son: los pesos con los que se entrenó un modelo, el aprendizaje en contexto que ocurre dentro de una conversación y la compactación, el mecanismo que resume una sesión larga para mantenerla dentro de su ventana de contexto. La memoria de agente, tal como la define Anthropic, es el conocimiento que el agente decide anotar durante el trabajo real y que más tarde vuelve a leer por su cuenta, en otra sesión.

Una nota es una apuesta a que algo volverá a importar, formulada antes de saber qué viene después.

¿Por qué anotarlo todo empeoró el rendimiento de Claude en Pokemon?

Anthropic comparó dos partidas de Pokemon Red de unos 10.000 pasos.

Sonnet 3.7 lo registró casi todo. Un archivo por combate contra un Pokémon salvaje, uno por objeto recogido, uno por conversación con un personaje no jugable. Para el paso 10.000 tenía 413 archivos de memoria repartidos en 225 carpetas y una medalla de gimnasio.

Fable 5 hizo lo contrario. Nueve archivos en dos carpetas, más un único archivo de nivel superior llamado global.md. Cuatro medallas. Más tarde, Opus 5.5 mantuvo una carpeta pequeña con su objetivo y sus próximos pasos, reescribió las notas en el mismo lugar y terminó el juego.

La partida con 413 archivos no se quedó sin espacio. Alrededor del paso 10.000 abrió una cuarta carpeta de memoria de nivel superior y, durante los siguientes 17 pasos, creó seis archivos, borró otros nueve y no hizo nada en el juego. El agente estaba reorganizando notas sobre un mundo que ya había avanzado.

Las notas sobre un entorno vivo se degradan mientras las escribes, y cada nota obsoleta compite por la atención con lo que hay en pantalla en ese momento. La memoria no es un recurso gratis.

¿Cómo una nota equivocada arruinó tres partidas seguidas?

El desperdicio es el fallo leve. El grave es una nota que sencillamente está mal, porque sobrevive a la sesión que la escribió.

En Pokemon Red, el Monte Luna tiene desniveles de un solo sentido. Claude anotó que el Centro Pokémon estaba al este de la cueva. Después de salir, dio la nota por buena, decidió que la cueva estaba terminada, la marcó como completada y se dejó caer por un desnivel que te devuelve a la entrada.

Su herramienta de navegación no podía ver la diferencia de altura, así que concluyó que se había pasado mucho hacia el oeste y anotó esa conclusión con más confianza que antes. Las sesiones nuevas heredaron ambos errores. Anthropic informa de tres partidas distintas que cayeron por el mismo desnivel. Una terminó con Claude escribiendo que se detendría en lugar de seguir en un bucle, avanzando hasta Ciudad Plateada y sin llegar nunca a Ciudad Celeste. La partida cuya memoria se había corregido volvió directamente a la cueva y llegó.

Una sola línea mala, y cada sesión posterior parte de ella sin comprobarla.

¿Qué separa un dato que vale la pena conservar del ruido?

Anthropic divide el mundo en cosas que cambian y cosas que se sostienen, un criterio más útil que preguntarse «¿esto es importante?».

Los datos efímeros cambian todo el tiempo: en qué casilla está un personaje no jugable, cuántas pociones quedan, cómo era la página hace un momento. Volver a leerlos es barato, guardarlos cuesta lo mismo, y la copia guardada está mal en el instante en que se escribe. Sacar una coordenada obsoleta de un almacén de memoria es peor que mirar la pantalla otra vez.

Las reglas latentes no aparecen en un solo fotograma. No saltes el desnivel de la derecha después de salir de esta cueva. Toma el bloqueo antes de una llamada concurrente a la API. Esta clase de error significa que falta una variable de entorno. Esas reglas salen de intentos repetidos entre sesiones, incluidos los que fallaron.

Solo la segunda categoría pertenece a la memoria a largo plazo. La primera merece volver a observarse.

¿Conviene escribir reglas que limiten lo que el modelo puede registrar?

Muchos equipos lo intentan. Un prompt que dice «nunca registres coordenadas» u «registra solo los fallos» parece control de calidad, y CL-Bench, el benchmark de Anthropic para memoria en tareas largas, indica que la restricción se vuelve en contra de los modelos fuertes.

Con la instrucción de registrar solo los fallos, tanto Opus 5 como Opus 4.7 perdieron buena parte de la mejora que les daba la memoria. Los modelos siguieron la regla y dejaron de anotar lo que habrían necesitado.

La otra dirección es más interesante. Pedir a Sonnet 4.6 que leyera primero su memoria y luego pusiera a prueba las teorías que encontraba casi duplicó su puntuación en el benchmark. Sonnet 5 leyó la memoria antes de responder en 9 de cada 10 casos sin instrucción alguna. Con solo decirle a Claude que existía una carpeta de memoria, Opus 4.7 y Opus 5 mejoraron.

Los modelos más fuertes juzgan la relevancia mejor que una lista de temas permitidos escrita a mano. Lo que la arquitectura les debe es un lugar seguro donde escribir, una forma de corregirla después y una declaración clara de para qué sirve la memoria.

¿Cuáles son las cuatro capas?

La arquitectura se ordena de abajo arriba: del registro completo al índice delgado. No es una única base de datos vectorial con un prompt atornillado encima.

Transcripciones. El registro completo: turnos de conversación, llamadas a herramientas con sus argumentos, resultados, retroalimentación del entorno. Sin pérdida, con búsqueda por palabra clave y de texto completo, nunca reducido a un resumen. Cuando descubres que todo lo construido encima está mal, este es el archivo al que vuelves.

Notas de memoria. Lo que el agente escribe durante una ejecución cuando algo parece relevante. Notas breves en Markdown sobre las lecciones de una tarea, a menudo con una etiqueta y una fecha.

Representaciones de memoria. Wikis y estructuras similares. En lugar de dejar que las notas se acumulen, una pasada offline fusiona duplicados, abstrae lo que se repite y enlaza las páginas entre sí para formar un mapa por el que un agente puede navegar.

Contexto inyectado. Unas pocas líneas que se cargan al inicio de la sesión. Indica en qué áreas tiene conocimiento el agente y dónde está el detalle, y apenas contiene detalle por sí mismo.

Anthropic midió cuánto vale la tercera capa en Stainless, una base de código real de unos 350.000 archivos, aproximadamente 420 millones de tokens, evaluada con 25 preguntas. El dreaming construyó la wiki a lo largo de 128 sesiones. Pasar de dos sesiones a 128 elevó la proporción de criterios de evaluación cumplidos del 13 % al 48 %. La búsqueda por sí sola obtuvo 53 %. La búsqueda combinada con la wiki subió del 54 % al 61 % conforme la wiki crecía, y ahorró unos 20.000 tokens por pregunta.

La wiki no ganó por sí sola. Ayudó cuando se combinó con la búsqueda, y en una tarea en la que cada respuesta vivía en un solo documento, el artículo dice que la wiki no mostró una mejora clara. En otra tarea, la wiki creció más que los documentos fuente que debía comprimir.

¿Qué es el dreaming?

El dreaming es cómputo que se gasta mientras nadie le pide nada al agente. El nombre viene de la investigación sobre el sueño: el hipocampo repite la experiencia del día durante el sueño de ondas lentas y el sueño REM, recorta el ruido y escribe en el almacenamiento de largo plazo lo que sobrevive.

En un agente, la pasada offline lee a la vez los registros y las notas, y busca desacuerdos. Puede reescribir una nota contrastándola con la transcripción, promover algo que no deja de importar, fusionar dos páginas que describen lo mismo o encontrar enlaces que apuntan a páginas que nadie creó.

La corrección del Monte Luna es el ejemplo más claro. El dreaming comparó la nota con el registro de movimientos, vio que la ruta anotada iba hacia el este y caía, y sustituyó la nota por una instrucción para volver a la cueva y dirigirse al norte. La partida corregida llegó a Ciudad Celeste y las no corregidas no.

También hace reparaciones estructurales. En la prueba de análisis de contratos de Anthropic, la primera pasada produjo un informe que cubría 41 de los 57 datos que importaban, el 72 %. Varios agentes habían sobrescrito una tabla compartida y parafraseado los términos con poca precisión. La solución fue de procedimiento: una página por contrato, un agente por contrato, términos citados palabra por palabra. Ese informe cumplió con el 100 % de los criterios. Una pasada de dreaming posterior encontró nueve enlaces que apuntaban a una página ausente, los reorientó y añadió tres páginas nuevas, incluido un índice.

El resultado del dreaming no está disponible para la sesión que se ejecuta ahora, y el cómputo no es gratis.

¿Cómo logra Claude Code que la capa inyectada sea pequeña?

Claude Code carga solo las primeras 200 líneas o 25 KB de MEMORY.md cuando empieza una sesión. El resto del directorio de memoria espera en el disco.

Esa cabecera es un índice. Le dice al modelo sobre qué áreas tiene conocimiento y dónde están los archivos. Cuando una tarea necesita una regla concreta, el agente busca en la capa inferior o la lee en ese momento.

Anthropic da dos razones. La memoria inyectada se factura como contexto en cada turno. Un archivo de instrucciones más largo hace que el modelo lo siga peor, y la diferencia se puede medir. Un bloque de memoria largo que contiene la respuesta por casualidad puede valer menos que un índice corto que apunta a ella sin fallar.

¿Dónde se vuelve difícil en producción?

Tres tensiones, y todas tienen que ver con el cómputo.

Cuándo escribir. Capturar un evento notable en el momento conserva el detalle, pero el acto de escribir compite con la tarea por el contexto. Escribir offline mantiene limpia la sesión y no entrega nada hasta más tarde.

Cómo mantenerse al día. La memoria deriva, porque las notas sobreviven a las condiciones que las hacían ciertas. El dreaming puede corregirlas, pero comprobar todo el tiempo cuesta tanto como ahorra, así que necesitas una cadencia y una lista de objetivos que revisar: memorias propensas a cambiar y memorias que ya se leyeron una vez y se contradijeron.

Cuánta representación construir. La búsqueda en transcripciones es una base sólida y no necesita mantenimiento. Las wikis ayudan cuando se combinan con la búsqueda, pero necesitan cómputo para seguir siendo exactas, y una wiki sin mantenimiento se convierte en otra capa de errores enunciados con seguridad.

¿Qué puedes sacar de esto?

Los números de Anthropic vienen de las tareas de Anthropic. Aun así, algunas decisiones de diseño se trasladan, y las clasificaríamos como consejos de diseño y no como resultados medidos:

• Conserva el registro bruto palabra por palabra. Cada resumen por encima es una caché, y debería apuntar al original en lugar de reemplazarlo.
• Guarda los registros, las notas y las páginas sintetizadas como cosas separadas. Tienen vidas útiles distintas y fallan de formas distintas.
• Inyecta un índice pequeño y deja que el modelo busque el detalle por su cuenta. No cargues todo el directorio de memoria en el prompt y esperes que funcione.
• Programa la pasada de corrección y dale cómputo real. Un agente que nunca revisa sus notas conserva su primer error para siempre.
• Registra la obsolescencia igual que el costo: fecha de la última verificación, veces leída, veces contradicha. El número de notas no es una métrica de salud.

Si tus sesiones duran cinco turnos y empiezan de cero, nada de esto se amortiza. El diseño supone una tarea que se ejecuta durante miles de pasos contra un mundo que cambia bajo sus pies.