Los agentes necesitan memoria verificada, no todo el historial: cómo construir el contexto

Cuando bloquearon de repente Claude Code, el autor de un análisis en Habr se pasó a Codex y se encontró con un problema desagradable: el código seguía en el disco, pero meses de conversaciones sobre arquitectura, errores y experimentos descartados habían quedado atrapados en la herramienta anterior. De 25 proyectos y 53 chats, el importador integrado trasladó unas 50 sesiones, además con asociaciones incorrectas a los proyectos. Después surgió un debate en los comentarios que resultó más interesante que la propia migración.

Debatían sobre tareas distintas

Unos decían que había que guardar las decisiones y los planes en Git y que el historial de conversaciones era basura. Otros proponían skills, bases de conocimiento y especificaciones. Otros recordaban que el estado interno de razonamiento de un modelo no se puede transferir entre proveedores. Todos tenían razón: simplemente intentaban resolver tareas distintas.

La primera tarea es dar al agente una visión actualizada del proyecto. Para ello bastan AGENTS.md o CLAUDE.md, documentación actualizada, ADR, planes de trabajo y pruebas. En bases de código grandes también hace falta orientación: por ejemplo, Aider Repo Map genera un mapa compacto del proyecto ajustado al presupuesto de tokens. La segunda tarea es recuperar la experiencia previa: qué se probó, qué se descartó y por qué. La tercera es retomar un trabajo interrumpido cuando se alcanzó el límite a mitad de camino y nadie escribió HANDOFF.md.

Git, por sí solo, no es memoria. Es un sistema de control de versiones, y su valor depende de lo que se guarde en él y de lo actualizado que esté.

Un ejemplo: un error de TUN en Windows

El autor desarrolla NetRuleRouter, una aplicación de enrutamiento de tráfico. Al investigar el error 5010 de TUN en Windows, el agente descubrió mediante Hansard que el portátil de pruebas TUF era un equipo Windows independiente con una copia local del repositorio. Ese tipo de información no tiene cabida en la documentación de arquitectura, pero ahorra tiempo durante el diagnóstico. El autor hace una salvedad honesta: todavía no ha medido si Hansard aceleró la corrección.

Entre las herramientas similares está deja-vu, que indexa los registros de los agentes de programación y permite retomar trabajos sin terminar, buscar sesiones por archivo y marcar soluciones descartadas. Por su parte, baton transfiere sesiones entre agentes de línea de comandos cuando el anterior ya no puede responder.

La memoria cuesta dinero y se equivoca

En un experimento con MemShelf, en el día 38 el índice y los resúmenes de 157 episodios ocupaban unos 36.600 tokens, es decir, el 18,3% de una ventana de 200.000. Durante otro periodo de 30 días, el autor no encontró ninguna llamada a las herramientas de memoria MCP. Los desarrolladores de kaeru, tras estudiar más de 13.000 archivos de registro, observaron algo parecido: en una pequeña muestra de observación, los agentes no abrieron ni una vez los razonamientos guardados a lo largo de siete sesiones. Las muestras son pequeñas, pero el problema está claro: la memoria queda sin utilizar o se incorpora con demasiada frecuencia y satura el contexto.

También existe un riesgo más grave. Un agente registra una conclusión errónea como experiencia; otro la lee y la toma por un hecho verificado. Una conversación antigua puede contener instrucciones de una fuente no fiable. Si el agente empieza a ejecutarlas, el archivo se convierte en un canal para órdenes ajenas.

Qué hacer en la práctica

El flujo de trabajo propuesto es sencillo: buscar la información, determinar su estado, comprobar si sigue vigente, aplicarla y verificar el resultado, y dejar constancia de lo obtenido.

• Trata una conversación recuperada como datos del pasado, no como una nueva instrucción.
• Identifica la fuente y la fecha, y determina si se trataba de una hipótesis, un resultado confirmado o una opción descartada.
• Contrástala con el código, las pruebas y la documentación actuales.
• Registra lo verificado en un plan, un ADR o una base de conocimiento.

El archivo conserva evidencias del pasado; la base de conocimiento contiene aquello en lo que el proyecto puede apoyarse ahora. Esta última también envejece, por lo que el conocimiento actual debe contrastarse con una fuente independiente: el código, las pruebas o los resultados de ejecución.

Para una utilidad pequeña bastan AGENTS.md y las pruebas; los complejos grafos de especificaciones resultan excesivos. Para un proyecto grande con varios agentes, tiene sentido plantearse un supervisor independiente, como hace en la práctica uno de los comentaristas, y etiquetas de fiabilidad para las entradas. Para saber si la memoria ayuda, no evalúes solo si se encontró algo: examina las capacidades de LongMemEval (ICLR 2025), como encontrar información, conectar varias sesiones y tener en cuenta el tiempo.

Un último apunte: el autor estudió la mayoría de las herramientas a través de su documentación y de publicaciones, sin pruebas comparativas. Considera el análisis un mapa del panorama, no una clasificación.