Agent Memory
Agent Memory es información retenida o recuperable para influir en decisiones e interacciones futuras de un sistema agente. Puede conservar antecedentes de una sesión, hechos, preferencias o resultados anteriores bajo los mecanismos que implemente el sistema. La definición de trabajo del Atlas describe esa función informativa; no exige una base de datos, embeddings, un servicio dedicado ni una taxonomía universal de memorias.
Retener información y utilizarla son actividades distintas. Un dato puede existir en un archivo y no ser seleccionado para la siguiente inferencia. También puede llegar al contexto con una interpretación incorrecta. La memoria ayuda cuando conserva información pertinente con procedencia y condiciones de uso claras; acumular historial no garantiza continuidad ni convierte un recuerdo en evidencia autoritativa.
Información retenida y contexto activo
Contexto es la información actualmente puesta a disposición de inferencia o ejecución. Memoria es una fuente retenida o recuperable que puede seleccionarse para formar parte de ese contexto. La distinción importa porque conservar un dato no demuestra que el agente lo recibió, y recibirlo no demuestra que lo interpretó o aplicó correctamente.
Context Engineering for Software Development estudia selección, delimitación, actualización y transferencia de información durante trabajo de software. Puede decidir qué antecedentes recuperar y cómo relacionarlos con observaciones actuales. Memory no sustituye esa estrategia. Una memoria extensa puede aportar ruido o hechos obsoletos si la selección no responde a la tarea.
La relación tampoco exige que todo contexto provenga de memoria. Un resultado de herramienta puede incorporarse como observación inmediata sin retenerse para usos posteriores. Una instrucción del encargo puede estar activa aunque todavía no forme parte de un mecanismo persistente. El propósito y el ciclo de vida de la información ayudan a distinguir esas situaciones.
Memoria y context window
La context window, desarrollada en llm-fundamentals, expresa capacidad o restricciones del modelo para procesar información en una interacción. Memory trata conservación y recuperación más allá de la disponibilidad inmediata. Una ventana mayor puede permitir incluir más antecedentes, pero no elimina la necesidad de decidir qué conservar, qué sigue vigente y cómo recuperar algo que no está presente.
Una ventana grande tampoco garantiza que el contexto contenga la decisión relevante. La información puede no haberse cargado o haberse resumido de forma incorrecta. A la inversa, una memoria pequeña y bien seleccionada puede ser suficiente para una tarea delimitada. No existe equivalencia entre cantidad retenida, cantidad entregada y calidad del siguiente paso.
La distinción evita presentar memoria como una ampliación mágica de capacidad. El sistema sigue teniendo límites de selección, representación y actualización. Si una herramienta recupera un fragmento equivocado, disponer de almacenamiento adicional no resuelve por sí solo el problema.
Memoria y estado de ejecución
Agent state describe la condición operativa actual: trabajo activo, observaciones recibidas, solicitudes pendientes o motivo de detención. Una sesión organiza continuidad de una ejecución o interacción según el runtime. Memory conserva información para uso futuro. Pueden compartir representación física sin que sus responsabilidades se vuelvan equivalentes.
Una respuesta pendiente de una herramienta pertenece al estado operativo del loop. Un antecedente recuperable sobre cómo se resolvió un incidente puede aportar memoria a otra tarea. Al terminar una sesión, algunos datos pueden conservarse y otros descartarse. No todo lo persistido sigue siendo estado activo, ni todo estado necesita transformarse en un recuerdo útil.
Agent Harness sostiene esa relación entre ejecución, estado y fuentes informativas. La memoria no define por sí sola cuándo un agente continúa, qué permisos tiene o qué acción está pendiente. Utilizar un mismo archivo para varias funciones tampoco elimina la necesidad de interpretarlas por separado.
Formas de información retenida
Una implementación puede conservar episodios, hechos sintetizados, preferencias de usuario o proyecto e historiales recuperables. Esas expresiones ayudan a discutir usos; no forman una clasificación obligatoria. Un mismo artefacto puede combinar un hecho observado, una decisión y una interpretación que no tienen la misma autoridad ni la misma vigencia.
La procedencia permite distinguir “el usuario pidió este límite” de “el agente dedujo que era conveniente”. También interesa conocer cuándo se observó el dato y a qué tarea o revisión se refería. Sin ese contexto, una conclusión local puede convertirse en regla general y afectar decisiones que nunca estuvieron incluidas en el encargo original.
El estudio Generative Agents, de 2023, propone una arquitectura de simulación que conserva experiencias en lenguaje natural, sintetiza recuerdos y los recupera para orientar comportamiento. Es un ejemplo de diseño, no una estructura universal de memoria ni evidencia de que todos los agentes necesiten reflexión o almacenamiento del historial completo.
Qué conviene conservar
La selección depende del propósito futuro. Una restricción de proyecto estable puede ser útil entre tareas; un mensaje repetitivo de una instalación quizá no aporte nada. Interesa retener lo que permite continuar, interpretar decisiones o evitar reconstrucción costosa, considerando también el costo de mantenimiento y exposición de información.
Conservar todo puede dificultar la selección y propagar errores. Un resumen excesivo puede perder una excepción decisiva. La elección no se resuelve maximizando volumen ni comprimiendo hasta una frase. Conviene preservar hechos, decisiones y dudas con el detalle necesario para recuperar su significado sin fingir certeza donde solo existía una hipótesis.
Planning puede utilizar antecedentes al elegir próximos pasos. El plan resultante sigue siendo revisable frente a la situación actual. Un precedente favorable no demuestra que otra tarea tenga los mismos requisitos, entorno o consecuencias; debe tratarse como información candidata para el nuevo encuadre.
Recuperación y selección
Recuperar puede significar leer un archivo conocido, consultar un historial o utilizar un índice. No se define por una técnica de búsqueda específica. La pertinencia depende de la pregunta actual y de los límites del conjunto consultado. Un resultado vacío puede expresar falta de cobertura o un criterio inadecuado, sin demostrar que nunca existió el antecedente.
Un sistema puede resumir o combinar recuerdos antes de entregarlos al modelo. Esa transformación puede introducir otra interpretación y necesita conservar límites relevantes. Una síntesis que une decisiones de dos proyectos distintos puede parecer coherente y recomendar una acción equivocada. La capacidad de volver a la fuente ayuda cuando la conclusión importa.
RAG puede recuperar información para generación, pero Memory y RAG no son sinónimos. Memoria describe retención y uso futuro; retrieval es uno de sus mecanismos posibles. El tratamiento general de RAG vive en su canonical de Application Patterns y no implica crear aquí índices vectoriales o una arquitectura de plataforma.
Vigencia, contradicciones y correcciones
Un recuerdo puede quedar obsoleto cuando cambia un contrato, una herramienta o una preferencia. Su edad es una pista, no una regla universal de validez: una decisión antigua puede seguir vigente y un resumen reciente puede estar equivocado. Importa relacionar el contenido con sus condiciones y la fuente que puede confirmar su estado actual.
Los hechos conflictivos deben conservar su procedencia en vez de fusionarse en una certeza inventada. Si una nota dice que el proyecto utiliza una herramienta y la configuración actual muestra otra, el agente necesita investigar la discrepancia. No debería modificar el proyecto para hacerlo coincidir con el recuerdo ni dar prioridad automática al resumen porque fue generado por el propio sistema.
Una corrección puede invalidar o actualizar información retenida sin borrar evidencia histórica que todavía tenga valor. La implementación concreta depende de necesidades de revisión y acceso. El objetivo es evitar que una conclusión retirada siga guiando acciones como si estuviera vigente, no imponer una política universal de almacenamiento o retención.
Cuando varias ejecuciones comparten memoria, una puede seguir utilizando una versión anterior mientras otra registra una corrección. También pueden producir síntesis incompatibles. Conviene poder identificar alcance, procedencia y versión relevante del recuerdo, y decidir quién puede actualizarlo. Compartir información no garantiza que todos los participantes tengan el mismo contexto ni que una última escritura represente la interpretación más correcta.
Memoria y execution records
Development Context and Execution Records conserva evidencia de trabajo: objetivo, decisiones, cambios, checks e incertidumbres. Memory existe para aportar información a decisiones futuras. Un registro puede utilizarse como fuente de memoria, pero no tiene esa función automáticamente por estar guardado.
Un registro histórico debería permitir distinguir una observación original de una corrección posterior. Una memoria operativa puede necesitar destacar la interpretación vigente. Esas necesidades pueden coexistir mediante referencias o representaciones distintas. Confundirlas favorece reescribir el pasado para que parezca coherente con una conclusión nueva o perpetuar un dato obsoleto por respetar su carácter histórico.
Ninguna de las funciones exige guardar razonamiento privado del modelo. Pueden conservarse resultados observables, decisiones pertinentes y sus límites. Una narración detallada tampoco demuestra que las acciones relatadas ocurrieron: la evidencia de herramientas y cambios reales conserva su papel.
Memoria y checkpoints
Agent Checkpoints and Recovery captura estado restorable de ejecución. Memory conserva o recupera información. Un checkpoint puede incluir cierta memoria o referencias a ella, pero guardar recuerdos no permite necesariamente restaurar solicitudes pendientes, posición del loop o condiciones de una sesión.
La restauración también puede reencontrar una memoria que cambió después del checkpoint. El runtime necesita definir qué se recupera y cómo se interpreta esa diferencia. No se puede asumir que volver a un punto anterior produce exactamente el mismo contexto ni que revierte efectos externos realizados desde entonces.
Esta frontera importa al recuperar trabajo interrumpido. Releer un resumen puede ser suficiente para reconstruir intención sin constituir una restauración del runtime. Un checkpoint puede reponer estado operativo sin asegurar que los datos recordados siguen siendo ciertos. La recuperación necesita considerar ambas clases de información.
Privacidad, alcance y contaminación
La memoria puede conservar datos de personas, proyectos o sistemas externos. Retener información innecesaria aumenta exposición y dificulta comprender para qué se utiliza. También puede mezclar ámbitos que deberían permanecer separados. Un antecedente de un proyecto privado no debería convertirse inadvertidamente en contexto público de otro encargo.
El contenido retenido puede ser incorrecto o haber sido influido por entradas no confiables. Si un texto recuperado se conserva como regla autoritativa sin contraste, puede afectar decisiones futuras. Aquí se identifica ese riesgo informativo; Memory Poisoning y su perspectiva de amenazas pertenecen a AI Security, sin materializar otro concepto en esta iteración.
Agent Permissions and Approval Boundaries sigue delimitando acceso y acciones. Un recuerdo que afirma que algo estaba permitido no demuestra autorización vigente para una ejecución diferente. Las Persistent Instructions también tienen alcance y autoridad propios; no toda preferencia memorizada se convierte en instrucción aplicable a cualquier recurso.
Ejemplo: continuidad entre tareas de mantenimiento
Un agente conserva que un repositorio construía el sitio con cierto comando y que una comprobación externa estaba pendiente. Al retomar, debe comprobar revisión y configuración actual antes de tratar ambos datos como hechos presentes. El comando puede seguir vigente y la comprobación haber sido completada por otra persona.
La memoria aporta pistas y reduce reconstrucción, pero no decide por sí misma el siguiente paso. Puede bastar leer el registro y la configuración pertinente. Si la información contradice el estado actual, corresponde actualizar el encuadre y conservar la diferencia relevante, sin volver a ejecutar acciones externas solo para hacer coincidir el mundo con el resumen anterior.
Uso proporcional
Un agente puede resolver tareas útiles sin memoria persistente adicional. También puede beneficiarse de antecedentes acotados sin construir una infraestructura compleja. Elegir una base de datos, un índice o un mecanismo de sincronización es una decisión de implementación que necesita un caso de uso; no está implícita en el concepto de Memory.
El criterio es conservar información que mejore decisiones futuras bajo límites comprensibles. Memoria no garantiza verdad, contexto activo, continuidad de estado ni corrección de resultados. Su utilidad depende de selección, vigencia, procedencia y capacidad de corregir lo que ya no debe orientar el trabajo.
Fuentes
- Generative Agents: Interactive Simulacra of Human Behavior, 2023: arquitectura de simulación citada como ejemplo. Las categorías y límites del Atlas son síntesis editorial, sin adoptar una implementación obligatoria.