Explicación de la memoria del agente: de trabajo, episódica, semántica y procedural
Un agente corrigió el mismo error dos veces porque nada mantenía el resultado. Memoria de agente funcional, episódica, semántica y procedural: qué almacena cada una y cómo falla.
Fuentes: **Agent Memory Explained: Working, Episodic, Semantic & Procedural**
Un agente de programación solucionó una vez el mismo error en dos sesiones seguidas. Nadie se lo pidió, y no había nada malo con el modelo.
En la primera sesión, el agente tomó el ticket BUG-142, rastreó la falla hasta el orden en que se ejecutaron las migraciones, modificó el código, ejecutó las pruebas de integración y vio cómo pasaban. Luego terminó la sesión.
Antes de la siguiente sesión, el sistema borró el historial de conversaciones para reducir los costos de tokens. Fue una decisión sensata, ya que reproducir un transcripte cada vez más largo cuesta dinero, aumenta la latencia y ensucia el prompt. Pero el transcripte no fue lo único que desapareció. La ejecución de las pruebas exitosas solo existía en la antigua ventana de contexto. No había registro alguno que indicara que el error se había resuelto, y el sistema de seguimiento de tareas seguía mostrando BUG-142 como pendiente.
Así que comenzó la segunda sesión: vi un ticket abierto y hice lo que se pedía en él. Lo investigué, llegué a la misma conclusión y aplicé la misma solución.
El modelo no había olvidado cómo resolver el problema. El sistema no logró conservar el hecho de que el problema ya estaba resuelto.
Ese fallo replantea la pregunta habitual. En lugar de preguntarse cómo darle memoria a un agente, hay que preguntarse qué tipo de información debería sobrevivir más allá de la sesión.Responder a esta pregunta conduce a cuatro tareas separadas:
- Memoria de trabajo: la tarea que se está realizando en ese momento.
- Memoria episódica: lo que sucedió y cuándo.
- Memoria semántica: lo que se sabe que es cierto.
- Memoria procedural: cómo deben hacerse las cosas.
La memoria no es una sola entidad. Consiste al menos en cuatro funciones, y la mayoría de los errores relacionados con la memoria surgen al confundir una con otra. Esta división toma prestado concepto de la ciencia cognitiva y se observa en investigaciones como CoALA (Arquitecturas Cognitivas para Agentes Lingüísticos), que describe a estos agentes en términos de memoria modular, acciones estructuradas y un proceso de toma de decisiones.
Antes de analizar estas cuatro funciones por separado, hay dos conceptos más que deben diferenciarse de la memoria en sí: la ventana de contexto y el estado autoritativo de la aplicación.
La ventana de contexto es un espacio de trabajo
El contexto abarca todo lo que el modelo puede ver durante una sola llamada de inferencia. Por lo general, esto incluye instrucciones del sistema, definiciones de herramientas, mensajes recientes, documentos recuperados, archivos en proceso de edición, resultados de las herramientas y el plan actual. Es el espacio de trabajo activo del agente.
También es temporal. Cuando finaliza una sesión, una conversación se comprime o los mensajes antiguos se eliminan para ajustarse al presupuesto de tokens; el contenido desaparece a menos que la aplicación lo guarde deliberadamente en otro lugar. Un modelo no tiene recuerdo privado de las llamadas anteriores. O bien la aplicación vuelve a introducir la información, o bien conecta el modelo a un almacenamiento externo.
Por eso una ventana grande no equivale a memoria a largo plazo. Una ventana de contexto más grande es como un banco de trabajo más amplio, no como un archivador. Más material permanece visible mientras el agente trabaja, pero cuando el banco de trabajo se vacía, todo lo que hay en él desaparece, a menos que algo guarde primero las partes importantes.
En este caso, la solución correcta quedó en el banco de trabajo y nada la destacó. Aun así, conservar toda la transcripción no habría sido la solución, porque se había pasado por alto otra distinción importante.
La memoria no es la verdad actual del sistema
Compare dos afirmaciones. Una es un registro en la memoria: “BUG-142 se corrigió durante la sesión de ayer”. La otra corresponde al estado de la aplicación: el campo de estado del ticket indica COMPLETED.
Están relacionadas, pero son tipos diferentes de información. La primera es un registro histórico que indica que ocurrió un evento. La segunda es la fuente de verdad actual del sistema de seguimiento. La memoria registra lo que sucedió, mientras que el estado registra lo que existe en este momento.
La importancia de esta brecha radica en que los recuerdos se vuelven obsoletos, permanecen incompletos o resultan erróneos. Imagine que el agente recupera una nota que indica que BUG-142 está abierto. Esa nota podría haber sido correcta en el momento en que se escribió, pero no demuestra nada sobre la situación actual. Antes de actuar en base a ella, el agente debería consultar el rastreador, revisar el repositorio, ejecutar las pruebas relevantes o intentar reproducir el problema. Un recuerdo recuperado es una afirmación sobre el pasado, no una evidencia del presente.
El incidente original falló dos veces. No se conservó ningún registro útil de la solución aplicada, y el estado autorizado de la tarea nunca se actualizó. Una vez aclarado esto, podemos determinar qué era lo que realmente necesitaba conservar el agente.
Memoria de trabajo: la tarea actual
La memoria de trabajo almacena lo que el agente necesita para continuar con la tarea actual, y poco más. En el caso de BUG-142 podría incluir la tarea en sí, la hipótesis actual (la tabla de dependencias se inicializa demasiado tarde), el paso actual (ejecutar el conjunto de pruebas de integración), la última observación (tres pruebas de migración fallaron) y los archivos que se están editando.
Responde a preguntas prácticas: ¿Cuál es el objetivo? ¿Qué paso se está llevando a cabo? ¿Qué devolvió la última llamada de la herramienta? ¿Qué archivos han cambiado? ¿Qué queda por terminar?
En la práctica, se encuentra en el prompt, en un objeto de estado del agente, en un punto de control del flujo de trabajo o en un almacén de sesiones con vida útil corta. Es temporal y está vinculado a una sola tarea; no tiene como finalidad ser un registro duradero de todo lo que el sistema ha aprendido. La descripción que da IBM de la memoria a corto plazo es similar: información reciente utilizada para decisiones inmediatas y para mantener la continuidad en las conversaciones.
La memoria de trabajo también difiere de los otros tres tipos. Las memorias episódica, semántica y procedural pueden persistir a lo largo de diferentes sesiones, mientras que la memoria de trabajo describe todo aquello que está activo en el momento actual, ya sea lo que se mantiene dentro de su ventana o lo que está almacenado cerca como punto de control.
Su corta duración no es un defecto. Una vez completada la tarea, rara vez hay motivo para conservar todas las hipótesis intermedias, los fragmentos a medio escribir, las órdenes fallidas o las líneas de pensamiento abandonadas. Los problemas surgen cuando un resultado importante solo existe en esta memoria. En ese incidente, desaparecieron dos cosas: el resultado del examen y el hecho de que se había corregido BUG-142. El sistema trató un resultado importante como si fuera un espacio temporal desechable.
La memoria de trabajo sirve para apoyar la ejecución. Nunca debería ser el único registro del trabajo finalizado.
Memoria episódica: el registro de los eventos
La memoria episódica almacena experiencias específicas. Un episodio es más que un simple hecho: ocurre en una situación concreta, generalmente con un momento específico, una acción y un resultado.
Para BUG-142, un episodio útil podría redactarse como un registro estructurado breve:
- Evento: BUG-142 se reprodujo durante la inicialización de las migraciones.
- Contexto: la tabla de dependencias no estaba disponible cuando se inició el servicio.
- Acción: se cambió el orden en que se ejecutan las migraciones.
- Resultado: las pruebas de integración superaron con éxito la verificación.
- Evidencia: commit a7f43d2.
- Hora: 8 de septiembre de 2026, 14:20.
Un registro como ese le indica al agente futuro que esta situación ya se ha presentado antes. Ayuda a evitar trabajar repetidamente, proporciona ejemplos y muestra qué intentos anteriores funcionaron o no. CoALA separa la memoria episódica de la semántica porque un registro de una experiencia tiene un propósito diferente al del conocimiento generalizado.
Tampoco es lo mismo un episodio que el historial de chat. Una transcripción puede contener cientos de mensajes, resultados de herramientas, especulaciones, correcciones y repeticiones. Se puede establecer una línea separadora en el registro original, como “probablemente deberíamos inspeccionar el orden de inicialización”, junto a un episodio resumido: reordenar la inicialización de las dependencias resolvió el BUG-142, y las pruebas dieron resultado positivo en el commit a7f43d2. Este último es mucho más fácil de recuperar y mucho más útil en tareas posteriores.
La memoria episódica aún puede fallar de dos maneras. El sistema podría conservar la acción pero perder el resultado. Un simple mensaje como “Intentado: se cambió el orden de migración” deja al agente futuro indeciso sobre si debe intentarlo de nuevo. O bien, el agente podría recuperar información de éxito de hace seis meses después de que la arquitectura haya cambiado. La memoria episódica preserva el pasado y no describe el presente, por lo que cada episodio debe incluir su momento, contexto, evidencias y resultado.
Memoria semántica: lo que sabe el agente
Un episodio registra lo que sucedió. La memoria semántica registra lo que se aprendió de ello.
El episodio BUG-142 puede generar un hecho reutilizable: el servicio de migración necesita que la tabla de dependencias exista antes de que comience la inicialización. Esto ya no se refiere a una sola sesión de depuración, sino que es una afirmación general sobre el sistema.
Las entradas típicas incluyen la base de datos que utiliza el servicio, un límite de velocidad para las API, una regla que exige que los identificadores de clientes no aparezcan en los registros, el patrón arquitectónico del repositorio, la preferencia de un usuario por respuestas técnicas breves y un requisito de que los scripts de migración sigan siendo compatibles con versiones anteriores. La memoria semántica abarca hechos, conceptos, restricciones, relaciones y preferencias. Tiende a ser de larga duración, pero debe mantenerse revisable, ya que los hechos y las preferencias cambian.
La diferencia con la memoria episódica es sutil y merece ser recordada. La versión episódica indica que BUG-142 ocurrió ayer porque faltaba la tabla de dependencias al iniciar el servicio. La versión semántica señala que la inicialización requiere que la tabla exista primero. Una recuerda la experiencia, la otra recuerda la lección que de ella se puede extraer.
Su fallo característico es la obsolescencia. Supongamos que el equipo adopta posteriormente un nuevo mecanismo de inicialización que ya no depende de la tabla. Si el sistema de memoria simplemente agrega el nuevo dato, el agente podría recuperar ambos: uno que indica que la tabla debe existir primero y otro que afirma que ya no es importante. Ahora hay memoria sin claridad. Un dato desactualizado puede ser peor que no tener ningún dato, ya que el agente actuará sobre él con confianza.
Por lo tanto, la memoria semántica necesita un camino de corrección, con respuestas a algunas preguntas. Alguien debe ser responsable de las actualizaciones de un dato. Necesita una fuente identificada y una fecha de última verificación. Cuando aparece una versión más reciente, la antigua debe marcarse como reemplazada y luego eliminarse o conservarse como historial. Estos aspectos forman parte de la ingeniería de la memoria propiamente dicha. Por ahora, lo importante es que la memoria semántica conserva conocimientos reutilizables, y no solo un registro de un evento.
Memoria procedural: cómo se realiza el trabajo
La memoria procedural indica al agente cómo llevar a cabo una tarea. Almacena habilidades, flujos de trabajo, reglas operativas y métodos repetibles.
A partir del problema, un equipo podría derivar un procedimiento: antes de ejecutar la inicialización de la migración, verificar que la tabla de dependencias esté disponible; ejecutar las pruebas de integración de la migración; registrar el resultado; actualizar el seguimiento de tareas; adjuntar la referencia del commit; confirmar que el problema ya no se reproduce.
Eso no es un hecho, aunque surge de uno. El hecho semántico es que la tabla debe existir antes de la inicialización. La regla procedural consiste en verificar su disponibilidad antes de iniciarla. La memoria semántica indica qué es cierto, mientras que la memoria procedural indica qué hacer. Otros ejemplos: revertir una implementación fallida, investigar un fallo de pago, qué pruebas deben superarse antes de cerrar un error, cómo revisar una solicitud de integración, cuándo solicitar aprobación humana y qué herramienta debe utilizarse antes de manipular datos en producción.
Las implementaciones van desde instrucciones claras y manuales versionados hasta habilidades empaquetadas, definiciones de flujos de trabajo, código puro o patrones aprendidos mediante la práctica. CoALA asigna a los procedimientos un lugar propio en la memoria del agente, vinculado tanto a las capacidades del modelo como al código explícito del agente.
Por eso, los procedimientos deben versionarse como el software y no acumularse como historial de conversaciones. Si una organización cambia su proceso de despliegue, el agente no debería recuperar cinco procedimientos antiguos e intentar adivinar cuál es el actual. Todo lo que se ejecuta en producción debe indicar quién es su responsable, qué versión utiliza, desde cuándo es aplicable, qué cubre, qué lo reemplaza y cómo se sabe que sigue funcionando.
En este incidente, la ausencia de un procedimiento influyó directamente. El agente corrigió el código, pero no había ninguna regla que exigiera convertir ese éxito en un estado actualizado de la aplicación. Lo que faltaba no era una repetición de toda la conversación, sino una instrucción clara del tipo: una vez que las pruebas den resultado positivo, anote el resultado y cierre el ticket. Eso constituye una brecha procedural.
Un error, cinco formas de representarlo
La taxonomía resulta más clara al escribir el mismo error de cinco maneras diferentes.
- Memoria de trabajo: “Actualmente se está corrigiendo BUG-142; el siguiente paso son las pruebas de integración”. Mantiene en marcha la ejecución actual.
- Memoria episódica: “En la primera sesión, BUG-142 se corrigió al cambiar el orden de las dependencias, y las pruebas dieron resultado positivo”. Conserva una experiencia concreta.
- Memoria semántica: “El servicio de migración necesita su tabla de dependencias antes de la inicialización”. Guarda conocimientos reutilizables.
- Memoria procedural: “Antes de inicializar las migraciones, verificar la tabla y ejecutar las pruebas de integración”. Conserva un método repetible.
- Estatus autoritativo: estado COMPLETED, commit a7f43d2, pruebas PASSED. Registra lo que la aplicación considera como verdadero.
Están relacionados pero no son intercambiables. El episodio no reemplaza el registro de tareas, y el registro de tareas no contiene todo lo aprendido durante el incidente. El hecho en sí no define toda la rutina de depuración, y dicha rutina no demuestra que un error específico haya sido corregido. No se puede esperar que la memoria de trabajo sobreviva más allá de la sesión.
El sistema no solo falló al recordar algo, sino que también incumplió en convertir el trabajo completado en las formas duraderas adecuadas.
Cada tipo falla de manera distinta
Si se guarda todo en un único almacenamiento sin diferenciar, la diagnosis se vuelve difícil. Es mejor preguntar qué información relacionada con el trabajo falló.
- La memoria de trabajo falla cuando el agente pierde su plan actual tras un reinicio, generalmente porque el progreso de las tareas solo existía en la ventana o en un proceso local.
Cada tarea merece sus propias reglas respecto a quién puede escribir, cómo se obtienen los elementos, cuánto tiempo se conservan, cómo se corrigen los errores y cómo se evalúa la calidad. Un índice vectorial puede ayudar a recuperar varios tipos de memoria, pero el índice no decide qué tipo es el contenido. Una regla práctica: clasifique la información antes de elegir la tecnología de almacenamiento.
Una breve lista de verificación para la clasificación
Cuando un agente se encuentre con una pieza de información, haga estas preguntas en orden.
- ¿Es necesaria solo para la ejecución actual? Memoria de trabajo. Piense en el plan actual, el resultado más reciente de una herramienta o una hipótesis temporal.
- ¿Se trata de un evento específico que ocurrió? Memoria episódica. Una implementación que falló ayer, un intento de reparación que no funcionó, un diseño rechazado por el usuario.
- ¿Es conocimiento reutilizable? Memoria semántica. Arquitectura, preferencias, restricciones del dominio, definiciones empresariales.
A menudo, una misma experiencia merece varias representaciones. Un despliegue fallido puede generar un episodio (falló a las 14:20), un hecho (el servicio X necesita la versión 17 del esquema), un procedimiento (verificar la compatibilidad del esquema antes de desplegar) y un cambio de estado (el despliegue se anuló). Eso no constituye una duplicación innecesaria, ya que cada forma responde a una pregunta diferente.
Lo que debería haber hecho el sistema
El contexto nunca necesitó existir para siempre. Lo que el sistema de gestión debía hacer era promover los resultados importantes antes de finalizar la sesión: escribir el episodio, extraer los hechos si los había, agregar o actualizar el procedimiento y establecer el estado de la tarea junto con las pruebas del commit.
Con eso en marcha, es seguro eliminar la conversación antigua. La transcripción original puede eliminarse porque todo lo que merece conservarse ya se ha convertido en los formatos necesarios para perdurar. El contexto puede desaparecer, pero los resultados importantes no deberían irse con él.
A dónde lleva esto
La clasificación es el punto de partida, y las cuestiones de ingeniería más complejas surgen después. ¿Qué merece ser almacenado? ¿Dónde debe residir cada tipo de información y quién puede escribirla? ¿Cuándo se recupera y cómo entra en el sistema? ¿Cuándo se actualiza y cuándo expira? ¿Qué sucede cuando dos memorias discrepan, y cómo se mide si la memoria ha mejorado en algo al agente?
Esas preguntas conforman la ingeniería de memorias, y ninguna de ellas puede responderse adecuadamente antes de que la información haya sido clasificada. Por lo tanto, antes de elegir una base de datos vectorial, un marco de trabajo para memorias o una estrategia de recuperación, pregúntese qué tipo de información está intentando preservar el agente.
El objetivo no es hacer que un agente recuerde todo, sino asegurarse de que las partes útiles sobrevivan, almacenadas de una forma que se adapte a cómo se utilizarán. A continuación viene el ciclo de vida que sigue la memoria: experiencia, extracción, una decisión sobre qué conservar, almacenamiento, recuperación, inserción en el contexto, verificación, acción y, finalmente, actualización u olvido.
Leer más
- La memoria de un agente AI no es una base de datos: qué conservar, recuperar y olvidar — Por qué la memoria del agente es un problema de relevancia: cómo difieren el contexto, la memoria, el estado y RAG, qué almacenar, cómo delimitar su alcance, su antigüedad y realizar auditorías, y por qué el olvido es una característica positiva.