![Imagen de portada de [Contexto IA #6] Memoria de agentes fuera del contexto](/assets/images/posts/9c901582-b6d3-47a4-a582-ff7c6393053d/1.jpg)
Esta entrega trata sobre ese destino. ¿Dónde y cómo se guarda el conocimiento que debe sobrevivir al final de una sesión? La ventana de contexto es una mesa de trabajo y el sistema de archivos, un almacén. La mesa es pequeña, cara y se despeja al terminar la sesión. El almacén es grande, barato y permanece. En última instancia, operar bien un agente consiste en diseñar la logística entre la mesa y el almacén.
El tema de esta entrega es ese destino. Se trata de dónde y cómo colocar el conocimiento que debe sobrevivir al final de una sesión. La ventana de contexto es una mesa de trabajo y el sistema de archivos, un almacén. La mesa es pequeña, cara y se despeja al terminar la sesión. El almacén es grande, barato y permanece. En última instancia, operar bien un agente consiste en diseñar la logística entre la mesa y el almacén.
Archivos de planificación, la línea de vida de las tareas largas
La forma más básica de externalización es un archivo de planificación. Al comenzar una tarea, haz que el agente cree un archivo como PLAN.md con los objetivos, las decisiones confirmadas y los pasos pendientes, y que lo actualice durante el trabajo.
Este único archivo resuelve varios problemas a la vez. Para empezar, sobrevive a los reinicios de sesión. Tanto si ejecutas /clear porque el contexto está lleno como si cierras el portátil y abres una sesión nueva al día siguiente, leer el archivo de planificación permite continuar el trabajo. A diferencia del resumen incierto de auto-compact que vimos en la tercera entrega, es un registro preciso cuyo contenido controlas directamente.
También tiene un efecto secundario. Si el agente actualiza y vuelve a leer el archivo de planificación en cada paso, el objetivo general reaparece una y otra vez cerca del final del contexto. Como vimos en la segunda entrega, la atención del modelo se concentra especialmente en esa zona. Al aprovechar esta propiedad, mantienes visible «qué estaba haciendo». Es el remedio para el problema de que un agente olvide el objetivo original y se desvíe durante tareas de decenas de pasos. En la práctica, los productos de agentes que gestionan tareas largas usan este patrón: guardan una lista de tareas en un archivo y la reescriben continuamente.
Memoria, conocimiento que se acumula entre sesiones
Si un archivo de planificación prolonga la vida de una tarea, la memoria acumula conocimiento durante todo el proyecto. Los agentes, incluido Claude Code, admiten funciones de directorio de memoria, cuyo principio es sencillo: guardar cada hecho descubierto en un archivo independiente, mantener cargado de forma permanente solo un índice resumido y leer el contenido completo cuando una tarea relacionada lo necesite. El principio de los punteros de la cuarta entrega también se aplica aquí.
Lo importante aquí es el criterio de almacenamiento. Si anotas cualquier cosa, la memoria se convierte enseguida en un vertedero. El umbral es «información que no puede derivarse de otro lugar». La estructura del código queda fuera porque puede conocerse leyendo el código; el historial de commits queda fuera porque Git lo recuerda. En cambio, sí merece la pena guardar reglas operativas como «el servidor de desarrollo de este proyecto debe ejecutarse siempre en el worktree principal», preferencias como «el usuario quiere un registro formal» y trampas específicas del entorno descubiertas tras mucho ensayo y error, porque no están registradas en ningún otro sitio.
Las memorias obsoletas también deben formar parte del plan. No hay garantía de que un hecho escrito hace seis meses siga siendo cierto. Las reglas de lectura y escritura de la memoria deben incluir «si una memoria consultada no coincide con la realidad, actualizarla o eliminarla». Así se evita que un recuerdo incorrecto vuelva convertido en el context poisoning descrito en la segunda entrega.
RAG, cuando el almacén tiene el tamaño de una biblioteca
Los archivos de planificación y la memoria cubren unas pocas decenas de archivos. Pero ¿qué ocurre si el almacén tiene el tamaño de una biblioteca? Miles de páginas de la wiki interna, decenas de miles de artículos y cientos de miles de consultas de clientes. La información necesaria está sin duda en algún lugar, pero no puedes cargarla completa en el contexto.
La técnica usada en estos casos es RAG (Retrieval-Augmented Generation, generación aumentada mediante recuperación). Cuando llega una pregunta, primero se buscan fragmentos relevantes en el almacén y después solo algunos de ellos se incorporan al contexto para generar la respuesta. La búsqueda suele usar embeddings. Al convertir el texto en coordenadas de un espacio semántico, una pregunta sobre «normas de reembolso» y un documento sobre «política de cancelación de pagos» pueden quedar cerca aunque usen expresiones distintas, lo que permite encontrarlos incluso sin palabras clave coincidentes.
Durante un tiempo, RAG se consideró la única respuesta para los documentos largos, pero los agentes de programación ofrecieron un giro interesante. Se comprobó que los agentes capaces de usar herramientas pueden encontrar bastante bien el código necesario repitiendo búsquedas con grep y explorando archivos, incluso sin búsqueda por embeddings. Por eso, el enfoque práctico actual es híbrido. La exploración directa del agente es fuerte para código con identificadores precisos, mientras que la búsqueda por embeddings es fuerte para conjuntos de documentos en lenguaje natural con expresiones variadas. En ambos casos, el principio es el mismo: no cargues todo; carga solo lo relevante en el momento de la consulta.
Resumen
- El contexto es una mesa de trabajo y los archivos son un almacén. La práctica básica es sacar del contexto y enviar a archivos el conocimiento que debe permanecer tras el final de una sesión.
- Los archivos de planificación mantienen vivas las tareas largas después de los reinicios de sesión y exponen repetidamente el objetivo cerca del final del contexto para evitar desviaciones.
- Guarda en la memoria solo la información que no pueda derivarse de otro lugar, mantén cargado de forma permanente únicamente el índice y gestiona las entradas obsoletas con reglas de actualización y eliminación.
- Cuando el almacén es muy grande, usa RAG para cargar solo fragmentos relevantes en el momento de la consulta. La exploración directa es fuerte para el código; la búsqueda por embeddings lo es para colecciones de documentos en lenguaje natural.
Solo queda la última entrega de la serie. Hasta ahora hemos gestionado el contexto para mejorar la calidad; la última trata sobre dinero. Explica cómo el funcionamiento de la caché de prompts puede hacer que los costes de API varíen varias veces según cómo se construya el mismo contexto, y por qué no se debe modificar a la ligera el principio del contexto.