Un cliente del sector financiero nos mostró en su día un agente que resolvía preguntas sencillas de maravilla — pero cuando la conversación se alargaba o volvían al día siguiente, el agente actuaba como si nunca se hubieran visto. Había olvidado el contexto. Había olvidado las decisiones a las que habían llegado. Había olvidado lo que el cliente había dicho sobre sus prioridades dos horas antes. «Es IA — ¿por qué no recuerda nada?» fue su frustrada pregunta.
Es una cuestión de arquitectura, no de modelo. La memoria de un agente de IA no es una propiedad automática — es una capa del sistema que se diseña. Diseñarla mal significa que el agente repite preguntas, pierde el contexto en cada nueva llamada y no puede aprender de interacciones anteriores. Este artículo explica cómo funciona la memoria de un agente, cuáles son sus límites y cómo resolverlos en la práctica.
Qué es la memoria del agente y por qué no es lo mismo que RAG
Antes de continuar, conviene distinguir dos conceptos que en la práctica se confunden con frecuencia: memoria del agente y RAG (Retrieval-Augmented Generation).
RAG es un mecanismo para cargar conocimiento — cuando el agente necesita responder una pregunta, acude a una base de datos vectorial y recupera documentos relevantes (documentación técnica, normativa interna, catálogos de productos). RAG trata sobre el acceso a conocimiento externo.
La memoria del agente trata sobre el estado del agente — lo que recuerda de la interacción en curso, del historial de sesión o sobre un usuario o entidad concretos. La memoria trata sobre la continuidad de la conversación y el contexto.
La diferencia práctica: si el agente pregunta «¿en qué formato quiere la salida?» y usted responde «Excel», debería recordarlo hasta el final de la sesión. Eso no es RAG — es la memoria de trabajo del agente. RAG lo usaría cuando el agente necesita encontrar qué formatos de salida soporta su sistema.
La confusión entre estos dos conceptos lleva a malas decisiones de arquitectura. Equipos que despliegan RAG cuando necesitan memoria, o al revés.
Las cuatro capas de memoria del agente
En la práctica distinguimos cuatro tipos distintos de memoria, y cada uno resuelve un problema diferente:
1. Memoria in-context (short-term)
Esta es la memoria de trabajo primaria del agente — el historial de conversación que se encuentra directamente en la context window del modelo. El agente «ve» todo el historial de la conversación como parte de la entrada.
Las ventajas son evidentes: latencia cero en el acceso, el agente siempre «ve» lo que se ha dicho, sencilla de implementar.
Los límites son igualmente evidentes:
- El contexto no es infinito. La mayoría de los modelos en producción tienen contextos de 128 k–1 M tokens, pero eso no significa que el agente procese con igual atención la información al principio y al final de una conversación larga.
- Efecto «lost in the middle» — fenómeno documentado: el modelo presta menor atención a la información situada en el centro de un contexto largo. Un historial extenso no garantiza que todo ese historial se procese de forma fiable.
- Los costes crecen linealmente con la longitud de la conversación — cada token del historial se reenvía en cada llamada sucesiva.
- La memoria desaparece al cerrar la sesión. La memoria in-context es efímera — en una nueva conversación el agente parte de cero.
La memoria in-context es ideal para interacciones cortas y cerradas. Para escenarios largos o persistentes no es suficiente por sí sola.
2. Memoria externa (long-term)
Cuando la interacción supera una sesión o la ventana de contexto, necesitamos memoria externa — un almacén persistente en el que el agente escribe y del que lee.
Las implementaciones más habituales:
- Base de datos vectorial (p. ej.
Qdrant,pgvector) — el agente guarda hechos clave o fragmentos completos de conversación como vectores. En la siguiente sesión los recupera mediante búsqueda semántica. Es similar a RAG, pero sobre el historial de memoria en lugar de una base de conocimiento. - Base de datos relacional / key-value store — para hechos estructurados sobre entidades (el usuario prefiere el español, trabaja en el departamento X, tiene el rol Y). Rápida y determinista.
- Memoria episódica — registros de interacciones pasadas almacenados en forma de «qué ocurrió en la sesión Z» — el agente puede recuperarlos, aprender de ellos o hacer referencia a ellos.
Diferencia clave respecto al RAG sobre una base de conocimiento: en la memoria externa el agente escribe por sí mismo — es su propio estado, no un documento externo.
La memoria externa trae sus propios desafíos: cuándo escribir (¿tras cada intercambio? ¿al cerrar la sesión?), qué merece guardarse y qué no, cómo gestionar registros contradictorios u obsoletos.
3. Memoria de sumarización
Para conversaciones largas, la solución práctica es la sumarización progresiva. En lugar de conservar todo el historial, el agente (o un paso de sumarización independiente) comprime periódicamente las partes más antiguas de la conversación en un resumen conciso.
Patrón típico de implementación en LangGraph:
- Mantener los últimos N mensajes completos en el contexto (p. ej. los últimos 20 intercambios)
- Comprimir todo lo anterior en 2–3 párrafos de resumen
- El resumen se sitúa al inicio del contexto como «estado hasta el momento»
Ventajas: el contexto se mantiene manejable, los costes no crecen sin límite, el agente sigue teniendo acceso a la esencia de las conversaciones anteriores.
Desventajas: la sumarización es con pérdida — el detalle puede desaparecer. En escenarios legales o de compliance donde importa la redacción exacta, eso es un riesgo. En conversaciones técnicas donde se mencionó hace una hora un parámetro de configuración concreto, la sumarización puede pasarlo por alto.
4. Working memory (memoria procedimental / de estado)
Esta es la capa que se pasa por alto con más frecuencia. La working memory es el estado estructurado que el agente mantiene durante la ejecución de una tarea — no la conversación, sino el *contexto operacional*.
Ejemplos: - Lista de pasos que el agente ha completado y los que aún están pendientes - Resultados intermedios de llamadas a herramientas - Decisiones tomadas en pasos anteriores (p. ej. «elegimos el formato XML») - Estado de un pipeline de varios pasos (en qué fase estamos)
En LangGraph la working memory se mapea de forma natural al State del grafo — cada nodo lee y escribe en un objeto de estado compartido. Esta es una de las principales ventajas de la gestión explícita del estado frente a frameworks más simples.
La working memory es crítica para agentes que ejecutan tareas de pipeline largas — sin ella el agente «olvida» lo que hizo en pasos anteriores y puede duplicar trabajo o contradecirse.
Cómo colaboran estas capas
En la práctica, un agente en producción combina las cuatro capas. Así se ve en el ejemplo de un agente de soporte técnico en una empresa manufacturera:
- 1.El usuario abre una nueva sesión → el agente carga desde la memoria externa (base de datos vectorial) la información relevante sobre ese cliente: sus máquinas, tickets anteriores, canal de contacto preferido. Esto va al inicio del contexto.
- 1.Durante la conversación → todo el historial de mensajes está in-context. El agente mantiene la working memory: «el cliente describió un problema con el motor M3, ya verifiqué los pasos A y B, esperando la salida de la herramienta de diagnóstico».
- 1.La conversación supera los 20 intercambios → el paso de sumarización comprime las partes más antiguas. Los hechos clave (tipo de máquina, número de serie, descripción del problema) se extraen y almacenan en el resumen.
- 1.Se cierra la sesión → el agente escribe en la memoria externa: «ticket #1234, cliente X, problema Y, solución Z, satisfacción 4/5». Esto estará disponible la próxima vez que se abra.
- 1.Una semana después el cliente vuelve a escribir → el ciclo se repite, pero esta vez con el historial como base.
Esto no es ciencia ficción — es arquitectura de producción estándar que implementamos para nuestros clientes. La complejidad no está en la tecnología, sino en decidir qué guardar, cuándo y en qué formato.
Diseño de la memoria externa: qué guardar y qué no
Uno de los problemas más frecuentes que encontramos al desplegar agentes con memoria a largo plazo es la explosión de memoria — el agente guarda demasiado, la relevancia de los registros cae, y al recuperarlos el agente recibe de vuelta ruido irrelevante.
Algunas reglas que funcionan en la práctica:
- Guarda hechos, no texto. En lugar de un párrafo completo de conversación, el agente guarda el hecho extraído:
{"user_id": "X", "preference": "output_format: Excel", "confidence": "explicit"}. Un hecho estructurado es más fácil de recuperar, de actualizar y ocupa menos espacio.
- Distingue la permanencia. Algunos datos son permanentes (el cliente tiene máquinas Siemens), otros son temporales (en esta sesión estamos resolviendo una avería concreta). Deberían estar en almacenes separados con distinto TTL (time-to-live).
- La memoria tiene versiones. Cuando el cliente cambia una preferencia, el valor antiguo no debería sobreescribirse — debería archivarse con una marca de tiempo. Esto es importante para la auditabilidad.
- Memoria explícita vs. implícita. Cuando el usuario dice explícitamente «recuerda que...», es inequívoco. Cuando el agente infiere del contexto (el cliente preguntó tres veces sobre el mismo tema → probablemente es una prioridad), es memoria implícita — menos fiable, requiere mayor nivel de confianza.
Cuándo el contexto largo no es suficiente
Podría parecer que con modelos de contexto de un millón de tokens la cuestión de la memoria está resuelta — basta con meter todo el historial. En la práctica no funciona tan fácil.
En primer lugar, el efecto «lost in the middle» — el modelo presta una atención desproporcionadamente menor a la información en el centro de un contexto largo. Un hecho crítico al inicio de una conversación extensa puede ser de facto invisible.
En segundo lugar, el aspecto del coste — todo el historial se envía en cada llamada. En una conversación con miles de intercambios supone un overhead de tokens innecesario que afecta directamente a los costes del agente en producción.
En tercer lugar, la escalabilidad — un sistema con 10 000 agentes activos donde cada uno mantiene el historial completo en el contexto no es realista. La memoria externa persistente permite el escalado porque el estado está fuera del proceso.
En cuarto lugar, la continuidad multi-sesión — la context window siempre se resetea en una nueva sesión. Sin memoria externa cada conversación nueva parte de cero independientemente de cuántas veces se haya puesto en contacto el cliente antes.
El contexto largo es una herramienta potente — pero es una herramienta para procesar documentos extensos y tareas complejas de una sola vez, no un sustituto de una arquitectura de memoria diseñada.
Sumarización vs. almacenamiento selectivo: dónde está el límite
Las dos estrategias principales para gestionar un historial de conversación largo son la sumarización y el almacenamiento selectivo de hechos clave. Cada una tiene su lugar.
La sumarización es adecuada cuando: - La conversación es narrativa, contextual, difícil de estructurar - Lo importante son las relaciones y el hilo de pensamiento, no hechos aislados - La velocidad de implementación es prioritaria
El almacenamiento selectivo de hechos es adecuado cuando: - La conversación contiene entidades y atributos claramente identificables - Los hechos necesitan recuperarse, actualizarse o agregarse más adelante - La auditabilidad es un requisito (finanzas, compliance)
En sistemas de producción normalmente combinamos ambas: sumarización para la «historia» de la sesión, hechos estructurados para entidades y decisiones.
La conexión directa con la forma en que el agente mantiene el estado entre pasos la encontrará en el artículo sobre arquitecturas de agentes de IA — especialmente en la sección sobre checkpointing en LangGraph.
Implementación técnica: LangGraph como patrón de referencia
Para despliegues en producción recomendamos LangGraph como marco de referencia para los patrones de memoria — no porque esté «de moda», sino porque modela el estado explícitamente como ciudadano de primera clase de la arquitectura.
Conceptos clave en el contexto de la memoria:
- State schema — usted define qué hay en la working memory del agente: qué campos, qué tipos, qué valores por defecto. Esto elimina los estados globales ocultos.
- Checkpointing — LangGraph soporta de forma nativa el guardado del estado del grafo en un almacén persistente (SQLite, PostgreSQL). Eso permite reanudar tras una interrupción, HITL (human-in-the-loop interrupt) y depuración post-mortem.
- Memory store — las versiones más recientes de LangGraph incluyen un memory store dedicado para memoria cross-thread (compartida entre distintas conversaciones del mismo usuario).
El checkpointing en LangGraph es también la técnica base para el human-in-the-loop en agentes — el agente se detiene antes de una acción crítica, el estado se guarda, y tras la aprobación humana continúa desde el mismo punto.
Alternativa: mem0 es una librería open-source dedicada a la memoria de agentes que proporciona una abstracción sobre distintos almacenes (base de datos vectorial, KV store, grafo). Adecuada si no quiere quedar ligado a un solo framework.
Aspectos de seguridad de la memoria del agente
Este aspecto rara vez aparece en las discusiones sobre memoria de agentes, pero es crítico: la memoria del agente es una superficie de ataque.
Si el agente carga memoria de un almacén externo y la inyecta en el contexto, un atacante con acceso a ese almacén puede insertar instrucciones maliciosas que formarán parte silenciosa de cada sesión futura. Esta es una variante del ataque de prompt injection — y es más peligrosa que la inyección directa, porque llega desde una fuente interna de confianza.
Medidas prácticas:
- Los registros de memoria deberían pasar por un proceso de sanitización antes de inyectarse en el contexto
- Distinga entre memoria de confianza (escrita por el sistema) y no confiable (escrita por el cliente o un servicio externo)
- Registre en log qué cargó el agente desde la memoria — eso forma parte de la observabilidad de los agentes de IA
- En agentes de alto riesgo (transacciones financieras, acceso a sistemas) considere una memoria con revisión humana explícita antes de la activación
Preguntas frecuentes
¿Es RAG lo mismo que la memoria del agente?
No. RAG es un mecanismo para cargar conocimiento de una base de conocimiento externa — por ejemplo, documentación interna de la empresa o una base de datos de productos. La memoria del agente trata sobre el estado del propio agente: lo que recuerda de la conversación, del usuario o de interacciones anteriores. En arquitectura son dos capas distintas, aunque técnicamente ambas pueden usar una base de datos vectorial para el almacenamiento.
¿Es suficiente una context window larga en lugar de memoria externa?
Para tareas puntuales y cerradas sí — un modelo con contexto de un millón de tokens puede procesar incluso un documento muy extenso. Para agentes multi-sesión con historial, para sistemas escalables o para escenarios en que el agente debe recordar hechos a lo largo de días y semanas, el contexto largo no basta. Además, el efecto «lost in the middle» limita la fiabilidad con entradas muy largas.
¿Cómo evitar que el agente «olvide» información importante de una conversación larga?
Combinación de tres medidas: (1) sumarización del historial con extracción explícita de los hechos clave a formato estructurado, (2) guardado de los hechos en la memoria externa en cuanto se identifican (no al final de la sesión), (3) working memory como objeto de estado explícito en el agente basado en grafos, donde las decisiones importantes se escriben directamente como campos — no enterradas en el texto conversacional.
¿Cuánto cuesta la memoria externa del agente adicionalmente?
Los costes directos son bajos — una base de datos vectorial como Qdrant es open-source y en volúmenes típicos (cientos de miles de registros) aguanta un servidor de coste asequible. El mayor impacto en costes viene de la latencia de recuperación (añade 50–200 ms por consulta) y del tiempo de desarrollo para diseñar correctamente el esquema de memoria. Una mala gestión de la memoria (guardar todo en lugar de guardar selectivamente) puede incrementar los costes de tokens en la recuperación — la relevancia del registro afecta directamente a cuántos tokens se cargan de vuelta al contexto.
¿Cuál es el error más frecuente al implementar la memoria del agente?
Por experiencia propia: olvidarse de la sumarización y de la limpieza. Los equipos implementan la escritura en memoria, pero no resuelven qué pasa cuando la memoria se llena de registros irrelevantes o hechos obsoletos. Al cabo de pocas semanas el agente recupera ruido que degrada la calidad de sus respuestas. La capa de memoria necesita una «estrategia del olvido» tan meditada como la estrategia de almacenamiento.
*La arquitectura de memoria es una de esas capas del sistema que los proyectos suelen subestimar en la fase de prototipo — y donde se paga el precio al escalar a producción. Si está diseñando un agente que debe funcionar en un entorno real con usuarios reales a lo largo de días y semanas, estaremos encantados de analizar con usted qué capa de memoria tiene sentido para su caso concreto.*