GUÍA TÉCNICA
Memoria en agentes de IA: contexto, estado, qué guardar y qué olvidar
Cuando se dice que un agente de IA «tiene memoria», puede parecer que el modelo recuerda por sí mismo lo ocurrido días o semanas atrás. Técnicamente, no tiene por qué ser así.
En muchos sistemas, la memoria es una capa construida alrededor del modelo. El sistema decide qué información guardar, dónde persistirla, para quién es válida, cuándo recuperarla y cómo volver a introducirla en el contexto de una ejecución futura.
RESPUESTA RÁPIDA
La memoria de un agente de IA es información que el sistema conserva para reutilizarla más adelante. Puede abarcar desde el historial de una sesión hasta preferencias, hechos, resúmenes o resultados relevantes que deben persistir entre ejecuciones. No todos los agentes necesitan memoria y memoria no significa que el modelo esté aprendiendo o modificando sus parámetros. Tampoco es lo mismo que RAG, contexto o estado.
Una arquitectura de memoria bien diseñada necesita decidir cuatro cosas: qué guardar, para quién, durante cuánto tiempo y qué hacer cuando esa información cambia o deja de ser útil.
Qué significa que un agente tenga memoria
Un modelo de lenguaje recibe una entrada, procesa el contexto disponible y genera una salida. Si en una ejecución posterior queremos que «recuerde» algo anterior, el sistema tiene que volver a proporcionarle esa información de alguna manera.
Esa continuidad puede construirse de formas muy diferentes.
Un chat puede conservar el historial de mensajes y volver a enviarlo en el siguiente turno. Un agente puede guardar un resumen de una tarea larga. Un sistema puede extraer que un usuario prefiere informes en PDF y recuperar esa preferencia una semana después. También puede almacenar que una determinada estrategia falló en una ejecución anterior para evitar repetir exactamente el mismo recorrido.
OpenAI, por ejemplo, distingue actualmente entre la memoria de sesión de su Agents SDK, que mantiene historial conversacional entre ejecuciones, y mecanismos de memoria de agente que pueden destilar información útil de trabajos anteriores. Microsoft Foundry, Google Memory Bank y AWS AgentCore utilizan también sistemas persistentes que extraen, consolidan y recuperan información entre sesiones.
Lo importante es no antropomorfizarlo.
En vez de decir «el agente recuerda como una persona», es más preciso decir que el sistema persiste información seleccionada y la vuelve a recuperar cuando puede ser útil para una nueva ejecución.
Eso nos obliga a pensar en almacenamiento, recuperación, identidad, caducidad y borrado, no solo en capacidad del modelo.
Contexto, estado y memoria no son lo mismo
Estas tres palabras suelen mezclarse, pero describen funciones diferentes.
Contexto
El contexto es lo que el modelo puede considerar durante una inferencia concreta.
Puede contener instrucciones, conversación reciente, documentos recuperados, resultados de herramientas, datos de una API, memoria recuperada o estado del proceso.
El contexto es un recurso de trabajo.
Una ventana de contexto grande permite introducir más información, pero no crea por sí sola memoria persistente.
Estado
El estado responde a otra pregunta: ¿dónde está ahora el proceso?
Por ejemplo:
pedido_validado = true
aprobación = pendiente
reintentos = 2
tarea_actual = revisar_documento
El estado puede almacenarse durante horas o días y seguir sin ser una «memoria» en el sentido que utilizamos aquí. Su objetivo principal es garantizar continuidad operacional.
Memoria
La memoria aparece cuando decidimos que algo ocurrido o descubierto merece estar disponible más adelante porque puede mejorar una nueva ejecución.
Por ejemplo: «El usuario prefiere recibir los informes en PDF» o «La última vez este tipo de documento falló porque faltaba el campo X».
La diferencia no depende exclusivamente de dónde se almacena la información. Depende también de para qué queremos conservarla.
Contexto, estado y memoria cumplen funciones distintas
Que tres tipos de información puedan acabar dentro del mismo prompt no significa que tengan el mismo propósito ni el mismo ciclo de vida.
Equivalente textual del diagrama
- CONTEXTO: Información disponible ahora. Ejemplos: Mensajes · documentos · instrucciones · resultados.
- ESTADO: Información para continuar el proceso. Ejemplos: Paso · aprobación · reintentos · tarea pendiente.
- MEMORIA: Información seleccionada para reutilizar. Ejemplos: Preferencias · hechos · episodios · procedimientos.
Memoria a corto plazo: continuidad dentro de una sesión
La memoria a corto plazo suele mantener información reciente necesaria para que el agente conserve continuidad.
Puede incluir:
- mensajes anteriores;
- llamadas a herramientas;
- resultados recientes;
- decisiones tomadas;
- observaciones;
- resúmenes compactados;
- progreso actual.
OpenAI denomina Sessions al mecanismo del Agents SDK que recupera el historial guardado antes de una nueva ejecución y almacena los nuevos elementos después. AWS AgentCore describe de forma parecida una memoria de corto plazo formada por eventos de una sesión.
Pero tampoco debemos imaginarla como «guardar todo para siempre».
En tareas largas, el historial puede crecer hasta ocupar demasiado contexto. Anthropic señala precisamente que el contexto es un recurso finito y utiliza técnicas como compaction, notas estructuradas y recuperación bajo demanda para conservar lo importante sin mantener cada resultado bruto disponible indefinidamente.
Una tarea de varias horas puede haber ejecutado cientos de llamadas a herramientas. Es posible que, para continuar, el agente necesite saber «ya comprobé A y B; C sigue pendiente» y no volver a recibir todas las respuestas completas que produjeron A y B.
La memoria de corto plazo también necesita selección.
Memoria a largo plazo: información que sobrevive entre sesiones
La memoria a largo plazo persiste más allá de una única conversación o ejecución.
Aquí ya no basta con conservar mensajes cronológicamente. El sistema necesita decidir qué partes de una interacción merecen convertirse en información durable.
AWS AgentCore describe un proceso de extracción y consolidación para convertir eventos de corto plazo en registros de memoria a largo plazo. Microsoft Foundry habla de conocimiento persistente que se extrae y consolida desde interacciones. Google Memory Bank puede generar recuerdos, compararlos con los ya existentes y crear, actualizar o eliminar información según cambie.
Eso sugiere un ciclo más útil que «guardar conversación»:
evento → evaluar → extraer → consolidar → persistir → recuperar
Y después:
actualizar / sustituir / olvidar
La memoria a largo plazo podría conservar preferencias de un usuario, hechos estables sobre una cuenta, un resumen relevante, precedentes de tareas anteriores, procedimientos reutilizables o información que permite continuar una relación entre sesiones.
Pero que algo pueda guardarse no significa que deba guardarse.
Memoria episódica, semántica y procedimental
Muchas arquitecturas toman prestada una taxonomía inspirada en ciencias cognitivas. Trabajos como CoALA utilizan categorías de memoria para organizar cómo un agente representa experiencias y conocimiento.
Estas categorías son útiles como modelo mental, pero no son una especificación obligatoria.
Memoria episódica: qué ocurrió
Representa acontecimientos concretos.
Por ejemplo: «El martes el agente intentó procesar este tipo de factura, detectó que faltaba el número de pedido y el caso terminó en revisión humana».
Ese episodio puede ser útil como precedente. La memoria episódica suele conservar situación, acciones, resultado y contexto relevante.
Memoria semántica: qué consideramos cierto
Representa hechos o conocimiento que puede reutilizarse sin necesidad de reconstruir todo el episodio que lo originó.
Ejemplos: «Este cliente utiliza EUR como moneda de facturación», «el usuario prefiere resúmenes breves» o «el proyecto X pertenece al departamento Y».
La palabra importante aquí es vigencia. Un hecho puede dejar de ser cierto.
Memoria procedimental: cómo hacemos algo
Representa procedimientos, estrategias o patrones que ayudan a ejecutar tareas.
Por ejemplo: «Para procesar este tipo de solicitud, primero comprueba A; si falta B, consulta C antes de continuar».
No significa necesariamente que el agente pueda reescribir sus propias instrucciones ni que haya aprendido mediante entrenamiento. Puede ser simplemente una pauta persistida que el sistema recupera cuando corresponde.
Memoria de trabajo: qué está activo ahora
A veces se incluye también una categoría de working memory para describir la información inmediata con la que se está trabajando.
En sistemas reales, esta frontera puede confundirse con contexto o estado, por lo que conviene utilizar los términos por su función y no porque exista una taxonomía aparentemente universal.
No necesitamos cuatro bases de datos porque existan cuatro nombres.
Una buena memoria no guarda todo
Aquí empieza el problema verdaderamente interesante.
Imagina una conversación con frases como «gracias», «perfecto», «nos vemos mañana», «creo que quizá prefiera PDF» o «el ticket sigue abierto». Minutos después, el ticket se cierra.
¿Deberían esas frases formar parte de la memoria a largo plazo?
Probablemente no todas.
Una política de memoria necesita evaluar al menos:
- utilidad futura;
- estabilidad;
- certeza;
- procedencia;
- sensibilidad;
- caducidad;
- identidad;
- coste de recuperar algo incorrecto.
Por eso el pipeline no debería ser todo lo ocurrido → guardar, sino algo parecido a evento → ¿es relevante? → extraer → validar → consolidar → persistir.
Una frase como «prefiero los informes en PDF» puede ser una buena candidata si la preferencia es explícita y útil en futuras interacciones.
En cambio, «creo que quizá prefiera PDF» es una inferencia débil. Convertirla automáticamente en un hecho puede introducir una memoria falsa.
Y determinados datos pueden ser ciertos y seguir sin merecer persistencia.
Una contraseña no debería convertirse en memoria porque pueda ser «útil».
Un saldo bancario puede no tener sentido como memoria porque cambia continuamente y existe una fuente de verdad que podemos consultar.
Una de las preguntas más importantes de diseño es: ¿deberíamos recordar esto o volver a consultar su sistema de origen?
No todo lo que ocurre merece convertirse en memoria.
La memoria tiene ciclo de vida
Guardar es solo una etapa. El sistema también debe decidir qué merece persistir, cuándo recuperarlo y qué hacer cuando deja de ser cierto.
Equivalente textual del diagrama
- EVENTO
- EVALUAR
- EXTRAER
- CONSOLIDAR
- PERSISTIR
- RECUPERAR
- CONTEXTO
- ACTUALIZAR / OLVIDAR
Cómo se actualiza una memoria cuando cambia la realidad
Guardar es solo la mitad del problema.
Supongamos que el sistema conserva: «El usuario quiere un informe semanal».
Un mes después, el usuario dice: «Ya no quiero informes semanales. Envíamelo únicamente a final de mes».
Una arquitectura ingenua podría terminar con dos recuerdos:
- quiere informe semanal;
- quiere informe mensual.
Ambos están almacenados, pero no son simultáneamente válidos.
Google Memory Bank documenta procesos de consolidación que pueden comparar información nueva con recuerdos existentes y decidir crear, actualizar o eliminar registros cuando aparecen duplicados o contradicciones. Microsoft Foundry permite operaciones de creación, lectura, actualización y borrado, además de políticas de retención.
Conceptualmente, una memoria necesita poder:
crear → actualizar → sustituir → borrar
Y, cuando sea importante, conservar información temporal como «válido desde», «sustituido por», «fuente» o «última confirmación».
Porque recordar información desactualizada puede ser peor que no recordar nada.
Recordar bien también exige saber actualizar y olvidar.
Memoria y RAG: parecen similares, pero no son lo mismo
La similitud existe porque ambos pueden utilizar recuperación.
En qué es RAG en IA explicamos cómo un sistema recupera conocimiento relevante y lo introduce en el contexto del modelo.
La memoria puede utilizar mecanismos parecidos: búsqueda semántica, filtros, metadatos, índices y ranking.
Pero la función conceptual es diferente.
RAG suele responder: «¿qué conocimiento o evidencia necesitamos recuperar para esta tarea?».
La memoria responde: «¿qué información de interacciones o experiencias anteriores decidimos persistir para reutilizarla después?».
Por ejemplo, una política de compras de la empresa debería probablemente vivir en una base de conocimiento controlada y recuperarse cuando sea necesario.
La preferencia de un usuario por recibir determinados informes en CSV podría vivir en memoria.
Ambas cosas pueden acabar entrando en el mismo contexto del modelo, pero su origen, autoridad, retención y forma de actualización son diferentes.
Separarlas ayuda a diseñar mejor.
Memoria no significa aprendizaje del modelo
Esta distinción es esencial.
Si almacenamos «el usuario prefiere Excel» y la semana siguiente recuperamos esa información y la añadimos al contexto, el modelo puede comportarse de forma diferente.
Pero eso no significa necesariamente que haya cambiado sus parámetros.
No hemos demostrado:
- fine-tuning;
- aprendizaje por refuerzo;
- actualización de pesos;
- aprendizaje continuo del modelo.
Lo que ha cambiado es la información que el sistema vuelve a proporcionarle.
Por eso resulta más preciso hablar de persistir → recuperar → reinyectar que decir simplemente «el agente aprendió».
OpenAI separa actualmente su memoria conversacional de sesión de mecanismos de memoria que destilan información útil de ejecuciones previas. Incluso cuando una plataforma utiliza la palabra learning, conviene preguntar qué se ha modificado realmente: ¿los pesos del modelo, una política, una memoria externa o el contexto de la siguiente ejecución?
El problema de recordar demasiado
La memoria parece una capacidad deseable hasta que empieza a contaminar las decisiones.
Más información persistida puede significar:
- más ruido;
- más coste de recuperación;
- más contradicciones;
- más información obsoleta;
- más superficie de privacidad;
- mayor riesgo de recuperar algo de otra identidad;
- más contexto irrelevante para el modelo.
Anthropic señala un problema equivalente al hablar de context pollution: incluso con ventanas de contexto amplias, introducir demasiada información irrelevante puede perjudicar el rendimiento.
Lo mismo ocurre con memoria.
Si una persona tuvo una preferencia hace dos años y después la cambió, recuperar ambas sin temporalidad no ayuda.
Si un agente guarda todas las incidencias antiguas y recupera cinco episodios irrelevantes para cada caso nuevo, el contexto se vuelve más ruidoso.
Si el sistema convierte hipótesis en recuerdos, puede terminar razonando sobre errores persistentes.
Más memoria no significa mejor memoria.
Una buena memoria es selectiva.
Identidad, permisos y aislamiento
Una memoria siempre debería responder a otra pregunta: ¿de quién es?
AWS organiza AgentCore Memory mediante conceptos como actores, sesiones, estrategias y espacios de nombres. Microsoft utiliza scope para segmentar memorias entre usuarios. Google Memory Bank también permite recuperar o borrar información dentro de un ámbito determinado.
Esto importa porque la similitud semántica no es un criterio de autorización.
Supongamos que dos clientes mencionan el mismo proyecto o producto. El sistema puede encontrar recuerdos técnicamente «relevantes» y, aun así, estar recuperando información que pertenece a otra cuenta.
Por eso necesitamos separar, según el caso:
- usuario;
- organización;
- cuenta;
- proyecto;
- equipo;
- agente;
- entorno.
La regla conceptual es sencilla: encontrar una memoria relevante no significa tener permiso para utilizarla.
El filtrado de identidad y ámbito debe formar parte de la arquitectura de recuperación, no depender de que el modelo decida por sí mismo qué debería revelar.
La relevancia no sustituye la autorización
Una memoria puede ser semánticamente útil y seguir perteneciendo a otra persona, cuenta o proyecto.
Equivalente textual del diagrama
- USUARIO A: Preferencias y recuerdos autorizados para A.
- USUARIO B: Preferencias y recuerdos autorizados para B.
- PROYECTO X: Información compartida solo dentro del proyecto.
Olvidar también forma parte de la memoria
La palabra «memoria» suele hacernos pensar únicamente en retener.
Pero un sistema serio necesita también mecanismos para olvidar.
Puede haber información que deba desaparecer porque:
- ha caducado;
- fue sustituida;
- era incorrecta;
- el usuario pide eliminarla;
- ya no es necesaria;
- pertenecía a un proceso terminado;
- no debería haberse conservado;
- una política de retención exige eliminarla.
Microsoft Foundry dispone de controles de retención y TTL en sus funciones actuales de memoria. Google Memory Bank permite eliminar recuerdos explícitamente y también actualizar o borrar información durante la consolidación cuando aparecen contradicciones o instrucciones de olvido.
Esto introduce una idea importante: olvidar no es necesariamente perder capacidad.
En ocasiones es exactamente lo que mantiene correcta la memoria.
Cuándo un agente no necesita memoria
No todos los agentes tienen que recordar entre ejecuciones.
IBM reconoce expresamente que hay agentes cuyo trabajo puede resolverse con información presente en el momento de actuar y que no necesitan sistemas de memoria.
Puede ocurrir cuando:
- la tarea es puntual;
- toda la información necesaria viene en la petición;
- la ejecución es completamente independiente;
- no existe beneficio real en personalizar futuras tareas;
- el estado solo importa mientras el proceso está abierto;
- volver a consultar la fuente de verdad es más fiable;
- la persistencia introduce más riesgo que valor.
Por ejemplo, un agente que recibe un documento, lo analiza una vez y devuelve un resultado puede no necesitar saber nada de ejecuciones anteriores.
Añadir memoria porque «los agentes avanzados tienen memoria» sería repetir el mismo error que hemos señalado en otros artículos: convertir complejidad en objetivo.
La memoria es una capacidad, no un requisito de madurez.
Un framework para decidir qué debería recordar un agente
Antes de persistir información, conviene pasarla por una serie de preguntas.
El resultado de este análisis no es «guardar» o «no guardar» todo.
Es diseñar una política:
qué → para quién → durante cuánto tiempo → cómo cambia → cómo se recupera → cómo se elimina
Ahí empieza una memoria útil.
Preguntas frecuentes
¿Todos los agentes de IA necesitan memoria?
No. Un agente puede resolver tareas independientes utilizando únicamente el contexto de cada ejecución. La memoria aporta valor cuando información anterior debe influir en tareas futuras.
¿La ventana de contexto es memoria?
No exactamente. La ventana de contexto contiene información que el modelo puede utilizar durante una ejecución. Puede incluir historial o recuerdos recuperados, pero no proporciona por sí sola persistencia entre sesiones.
¿Memoria y RAG son lo mismo?
No. RAG es un patrón de recuperación de conocimiento o evidencia para aportar contexto a una tarea. La memoria se ocupa de qué información persistimos para poder reutilizarla posteriormente. Ambos pueden emplear técnicas de recuperación similares.
¿Dónde se guarda la memoria de un agente?
Depende de la arquitectura. Puede almacenarse en bases de datos relacionales, documentos, índices de búsqueda, almacenes vectoriales, servicios específicos de memoria o combinaciones. El tipo de almacenamiento no define por sí solo la memoria.
¿Qué es la memoria episódica?
Es un marco para conservar información sobre acontecimientos o ejecuciones concretas: qué ocurrió, qué acciones se realizaron y cuál fue el resultado. Puede servir como precedente para futuras tareas.
¿Qué es la memoria semántica?
Es un marco para representar hechos o conocimiento relativamente estable que el sistema puede recuperar en futuras ejecuciones. Es importante gestionar su vigencia y procedencia.
¿Un agente con memoria aprende?
No necesariamente. Persistir y recuperar información no implica modificar los parámetros del modelo. El sistema puede comportarse de manera distinta simplemente porque recibe contexto diferente en la siguiente ejecución.
¿Cómo se actualiza o borra una memoria?
Depende de la implementación, pero una arquitectura puede permitir actualizar registros, sustituir información anterior, aplicar caducidad, eliminar por identidad o criterio y consolidar contradicciones. El borrado debería diseñarse desde el principio.
Fuentes y lecturas recomendadas
Las fuentes siguientes sostienen la separación entre memoria de sesión y memoria persistente, los procesos de extracción y consolidación, el aislamiento por ámbito y las taxonomías utilizadas para describir distintos tipos de memoria.
- 01OpenAI Agents SDK — Sessions (enlace externo)openai.github.io
Documenta memoria de sesión para mantener historial conversacional entre ejecuciones.
- 02OpenAI Agents SDK — Agent memory (enlace externo)openai.github.io
Separa memoria de agente de memoria conversacional y describe la destilación de información útil de trabajos anteriores. La función está en beta.
- 03Microsoft Foundry Agent Service — Memory (enlace externo)learn.microsoft.com
Describe memoria persistente entre sesiones, extracción, consolidación, ámbitos, operaciones de memoria y controles de retención. Algunas capacidades están en preview.
- 04Google Cloud — Memory Bank (enlace externo)docs.cloud.google.com
Documenta extracción, consolidación, actualización y eliminación de recuerdos dentro de un ámbito.
- 05AWS Bedrock AgentCore — Memory types (enlace externo)docs.aws.amazon.com
Distingue memoria de corto y largo plazo y describe extracción, consolidación y recuperación.
- 06Anthropic — Effective context engineering for AI agents (enlace externo)anthropic.com
Explica contexto como recurso finito, compaction, notas persistentes y recuperación bajo demanda en trabajos de larga duración.
- 07CoALA — Cognitive Architectures for Language Agents (enlace externo)arxiv.org
Propone una arquitectura cognitiva para agentes de lenguaje con módulos de memoria y una taxonomía inspirada en ciencias cognitivas.
- 08IBM — ¿Qué es la memoria de agentes de IA? (enlace externo)ibm.com
Ofrece una panorámica de memoria a corto y largo plazo y de categorías episódica, semántica y procedimental.
Sobre el autor
Elvis Mendoza, fundador de Agentes Como Servicio. Trabaja en el diseño de producto, la arquitectura de soluciones, el diseño de agentes y flujos de trabajo y la construcción de software asistida por IA para conectar procesos, datos, herramientas y supervisión humana alrededor de necesidades empresariales concretas.
¿Tu agente debería recordar algo después de terminar una tarea?
Antes de añadir una base de memoria conviene decidir qué información merece persistir, para quién será válida, durante cuánto tiempo y cómo se actualizará o borrará cuando deje de ser cierta.
En Agentes Como Servicio diseñamos memoria como parte de la arquitectura del proceso: persistimos solo lo que aporta continuidad real y mantenemos el resto en su fuente, en el estado de ejecución o fuera del sistema cuando no necesita recordarse.
Solicitar acceso