Conceptos clave para implementar memoria en Agentes

Un agente sin memoria empieza desde cero en cada interacción y se siente menos inteligente. La memoria ayuda al agente a usar el contexto de interacciones anteriores. Primero debemos definir qué tipo de memoria queremos implementar.

Tipos de Memoria

La memoria en agentes toma analogías de la psicología cognitiva. El modelo Atkinson–Shiffrin distingue almacenes de memoria; semántica, episódica y procedural son distinciones cognitivas diferentes, no categorías de ese modelo.

• Corto plazo: El bloc de notas de tu cerebro, en humanos dura muy poco entre 0 y 20 segundos.
• Semántica: Básicamente el significado del entorno, hechos, definiciones.
• Episódica: Registros de conversaciones anteriores: qué se dijo, decisiones tomadas, eventos importantes.
• Procedural: Instrucciones pasadas, comportamientos aprendidos por repetición.

Estado y memoria

El “estado” es uno de los conceptos más relevantes en LangGraph: una aplicación de LangGraph se modela como una Máquina de Estado. Un agente sin memoria entre sesiones puede seguir orquestando herramientas y flujos de trabajo.

Muchos llamados al API de un LLM son operaciones sin estado salvo por el contexto suministrado; algunos servicios también mantienen el estado de la conversación. La capa de estado es precisamente la forma de introducir memoria en el agente, sea temporal o persistente, a corto o largo plazo. Se podría argumentar que el estado del agente es en sí memoria, pero claramente no es suficiente.

¿Transitoria o persistente?

• Transitoria: vive solo durante la sesión actual; se borra si el agente o el proceso reinicia. Útil para prototipos o agentes que no deben guardar datos por privacidad.
  • Puede modelarse como un bloc de notas en el estado de la aplicación; la ventana de contexto es la entrada limitada que recibe el modelo, no un mecanismo de persistencia.
• Persistente: sobrevive reinicios; puede limitarse a un hilo o compartirse entre conversaciones. La durabilidad es distinta del alcance y del contexto suministrado al modelo. Sistemas y papers (p. ej. Mem0) reportan mejoras bajo sus condiciones de evaluación, no garantías para cualquier aplicación. (arXiv)

Tres preguntas clave

• Qué queremos guardar hechos, resúmenes de conversaciones, decisiones, fallos/éxitos.
• Cómo lo guardamos base de datos relacional, vector DB, grafo o una combinación. Usamos una herramienta o usamos un proceso asíncrono de consolidación.
• Cuándo lo guardamos inmediatamente, a intervalos, al final de la sesión, o mediante procesos asíncronos de consolidación.

Qué queremos guardar

• Datos de usuario (semántica): nombre, preferencias, roles. Son “pequeños” y se guardan como registros CRUD —bajo costo y alta precisión.
• Conversaciones largas (episódicas): no conviene guardar cada token. En su lugar:
  • Chunking + embeddings para búsquedas semánticas cuando se necesite recuperar trozos concretos.
  • Resúmenes incrementales (incremental summarization): al final de N turnos generar un resumen condensado que represente la parte esencial y almacenar solo el resumen; mantener apuntes ampliables si se requiere reconstrucción.
• Relaciones complejas: si necesitas razonar sobre relaciones entre entidades (p. ej. “el cliente X pidió esto en 2023 y lo repitió en 2025”), considera un grafo de memoria o representación relacional que capture aristas/propiedades. Algunos trabajos recientes proponen memoria basada en grafos para capturar relaciones temporales/causales. (arXiv, ResearchGate)

Cómo la vamos a guardar

No existe “la base de datos correcta”; la decisión depende de requisitos de consistencia, latencia, costo y auditoría. Un patrón común:

Memoria de trabajo, scratchpad:

• Redis o in-memory store para los N últimos turnos; la memoria local del proceso se borra al reiniciar, mientras que la durabilidad de Redis depende de su configuración de persistencia.
• O podemos simplemente guardar esto en el estado de la aplicación

Memoria semántica y de hechos:

• Base documental o relacional para hechos (ej. Mongo, Postgres).
• Vector DB (Pinecone, Weaviate, Milvus, o Atlas Vector Search) para embeddings y búsquedas por similitud.

Consolidación, resumen y razonamiento:

• Background workers (cron, jobs) que: extraen, condensan, versionan y escriben la memoria persistente de largo plazo.
• Guardamos en un vector store o grafo de conocimiento.

Entidades y relaciones:

• En un grafo con su propia ontología, como neo4j

Memory layer como servicio

• Proyectos como Mem0 entregan una capa “off-the-shelf” para extracción dinámica, consolidación y políticas de retención; pueden reducir el trabajo de implementación y los costos de operación. (mem0.ai, arXiv)

Cuándo guardarla

• Inmediato: cuando ocurre un evento crítico (ej. cambio de preferencias, compra), el agente de forma autónoma decide qué y cuándo guardar.
• Conteo de turnos: guardar solo cada N turnos para no darle la responsabilidad al agente. Podemos llevar un contador en el estado que dispare el proceso de memoria.
• Idle-trigger: cuando detectas inactividad, consolidar la sesión.
• Batch/asíncrono: para conversaciones largas, enviar trabajos en segundo plano que resumen y limpian antes de persistir.

Cómo la vamos a consumir

• Carga en system prompt: útil para datos pequeños y críticos (persona del usuario, restricciones).
• Recuperación condicionada: usa señales (intención, slot-fill, topic change) para decidir qué memoria traer.
• Tool-based access: el agente llama una “tool” (API) que devuelve memorias relevantes (en lugar de cargar todo en prompt). Esto separa responsabilidades y permite caching, paginación y autorización.
• Decisión híbrida: cargar resumen de contexto + hacer retrieval adicional cuando la respuesta lo requiera.

MongoDB y otros proveedores han publicado patrones y SDKs para habilitar memoria entre sesiones y checkpointers en frameworks de agentes (p. ej. LangGraph). Si trabajas con LangGraph, revisa las integraciones de datastore/Store disponibles para evitar reinventar la rueda. (MongoDB)

Como continuación práctica, lee Capa de memoria para IA: diseñar memoria persistente para agentes.

Herramientas, lecturas y recursos recomendados

• Mem0 — memoria como capa (repositorio y docs). Una opción a evaluar si buscas control y trazabilidad; valida su comportamiento con tus propios requisitos. (GitHub, docs.mem0.ai)
• Mem0 (paper/arXiv) — evaluación sistemática y resultados sobre latencia y costo en tokens. Contexto útil de evaluación, no un sustituto de probar tu propia carga de trabajo. (arXiv)
• Hugging Face — posts sobre memoria y cómo reducir uso de memoria en modelos — buen contexto conceptual y patrones para optimización. (Hugging Face)
• Memory Architectures in Long-Term AI Agents (research) — paper sobre integrar memoria episódica, semántica y procedural inspirado en la cognición humana. Buen soporte teórico. (ResearchGate)
• MongoDB + LangGraph — ejemplos e integraciones (MongoDB Store para LangGraph) si trabajas con LangGraph y buscas una solución de memoria persistente escalable. (MongoDB)