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 es parte clave del contexto de un agente para ser más útil. Primero debemos definir qué tipo de memoria queremos implementar.

Tipos de Memoria

La memoria en agentes tienes bases en la psicología cognitiva, específicamente en El modelo Atkinson–Shiffrin

• Corto plazo: El notepad 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 estado es simplemente un API call.

Un llamado al API de un LLM es una operación sin estado. 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 si 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 entenderse como la ventana de contexto o modelarse como un notepad en el estado de la aplicación.
• Persistente: sobrevive reinicios y múltiples conversaciones; imprescindible cuando quieres personalización a largo plazo o trazabilidad. Sistemas recientes y papers (p. ej. Mem0) muestran mejoras claras en coherencia y costo al usar memorias persistentes estructuradas. (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 coste 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, coste y auditoría. Patrón común y robusto:

Memoria de trabajo, scratchpad:

• Redis o in-memory store para los N ultimos turnos (rápido, barato, se borra al reinicio).
• O podemos simplemente guardar esto en el estado de la aplicación

Memoria semántica y de hechos:

• Document store / relational store para facts (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 engineering time y cost-to-serve en producción. (mem0.ai, arXiv)

Cuándo guardarla

• Inmediato: cuando ocurre un evento crítico (ej. cambio de preferencias, compra), el agente de forma autonoma 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 background 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 cross-session 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)

Herramientas, lecturas y recursos recomendados

• Mem0 — memoria como capa (repositorio y docs). Recomendado si buscas una solución product-ready con control y trazabilidad. (GitHub, docs.mem0.ai)
• Mem0 (paper/arXiv) — evaluación sistemática y resultados sobre latencia y token-cost. Útil para justificar decisiones arquitectónicas. (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 episodic/semantic/procedural memory 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)