Dar memoria a un agente de IA parece sencillo: dejar que escriba notas y que las lea la próxima vez. El nuevo artículo de investigación de Anthropic muestra por qué no lo es, y por qué la respuesta ha cambiado a medida que mejoraban los modelos. En resumen, los modelos Claude más potentes guardan mucho menos, eligen mejor qué guardar y rinden peor cuando se les dice exactamente qué anotar.
El ejemplo más claro viene de Pokémon Rojo. A unos 10.000 pasos de partida, Claude Sonnet 3.7 había escrito 413 archivos de memoria en 225 carpetas, con archivos separados para combates, objetos y personajes concretos, y había ganado una medalla. Claude Fable 5 escribió nueve archivos en dos carpetas más un único panel general, y ganó cuatro. Buena parte de lo que guardaba el modelo antiguo, como el dinero o la posición en el mapa, se puede leer en pantalla de todos modos, y en un momento pasó 17 pasos reorganizando archivos sin hacer ningún movimiento. Opus 5.5 mantuvo un conjunto pequeño de notas que reescribía sin parar y terminó el juego. En una tarea de preguntas sobre una base de datos de Continual Learning Bench 1.0, Opus 5 fue el primer modelo en cerrar el ciclo, escribiendo reglas junto con cómo sabía que eran ciertas; Opus 5.5 y Sonnet 5.5 hicieron lo mismo.
Las pautas para quien construye agentes son concretas. Decirle a Claude para qué sirve la memoria, sin dictarle cómo usarla, funcionó mejor con los modelos potentes. Imponer una regla como "registra solo los fallos" costó a Opus 5 y Opus 4.7 buena parte de lo que ganaban con la memoria. Los modelos antiguos aún necesitan guía: pedir a Sonnet 4.6 que leyera su memoria y comprobara sus teorías casi duplicó su puntuación, mientras que Sonnet 5 leyó su memoria sin que se lo pidieran nueve de cada diez veces.
La segunda idea es soñar: repasar transcripciones pasadas sin conexión para corregir notas erróneas. En una partida de Pokémon, Claude anotó mal en qué lado de Mt. Moon estaba un punto de referencia y volvía a caer por el mismo saliente; después de que el sueño contrastara la nota con la transcripción, volvió a entrar en la cueva y llegó a la siguiente ciudad. Con un corpus de unos 350.000 archivos internos, construir una wiki enlazada a lo largo de 128 sesiones de sueño elevó los aciertos en 25 preguntas del 13% al 48%, y la wiki junto con la búsqueda superó a la búsqueda sola, 61% frente a 53%, ahorrando unos 20.000 tokens por pregunta.
Para quien desarrolla en Claude Developer Platform, buena parte de esto funciona a través de Managed Agents y se puede usar directamente. Las salvedades son que todos los resultados proceden de tareas y juegos de la propia Anthropic, algunas comparaciones se basan en una sola ejecución y el propio artículo muestra una wiki que acabó siendo más grande que los documentos que resumía, un recordatorio de que más memoria no siempre es mejor memoria.