Un agente de IA que no te recuerda está limitado de raíz. Cada conversación comienza desde cero. Tienes que volver a presentarte, explicar de nuevo tus preferencias y aclarar otra vez el trabajo en curso. La fricción se acumula y la confianza disminuye.
Este es el problema de la memoria. Las ventanas de contexto gestionan la conversación actual. La memoria a largo plazo —entre sesiones y a lo largo de días o meses— necesita una arquitectura propia. Y es más difícil de lo que parece.
Este artículo explica cómo funciona la memoria real de un agente en producción: las capas, las opciones de almacenamiento, los patrones de recuperación y los compromisos que distinguen una memoria útil de otra que alucina.
¿Qué significa “memoria”?
Una visión simplista: memoria = “el modelo recuerda cosas entre conversaciones”. La realidad es más sutil. La ciencia cognitiva distingue tipos de memoria, y la memoria de los agentes de IA también se beneficia de una distinción similar:
Memoria de trabajo. La conversación actual. Almacenada en la ventana de contexto. Se pierde cuando termina la conversación (a menos que se persista).
Memoria episódica. Eventos específicos del pasado. “La semana pasada, hablamos de X”. “Hace tres meses, decidiste Y”.
Memoria semántica. Hechos generales. “Tu nombre es Alice”. “Prefieres respuestas concisas”. “Tu empresa está en Tallinn”.
Memoria procedimental. Cómo hacer las cosas. “Cuando el usuario pida una reunión, usa esta plantilla”. “Cuando el cliente esté en el nivel X, sigue el proceso Y”.
Diferentes tipos de memoria cumplen funciones distintas. Un sistema completo de memoria de un agente cubre todos ellos.
Lo que la memoria debe lograr
Antes de la arquitectura, los objetivos:
Continuidad. El agente retoma donde lo dejó. No hay que reintroducirte en cada sesión.
Personalización. El agente aplica tus preferencias sin que se lo pida. Escribe en tu estilo, usa tus herramientas, menciona a tu equipo.
Preservación del contexto. Decisiones de conversaciones pasadas informan las actuales. “Decidimos X el mes pasado” debe recordarse.
Acumulación de habilidades. El agente aprende tus patrones y los aplica. Después de 10 conversaciones sobre programación en Python, debería elegir Python por defecto.
Privacidad y olvido. Qué se recuerda, qué no, qué se elimina. Tanto para la confianza del usuario como para el cumplimiento legal.
Estos objetivos a veces entran en conflicto. La continuidad busca recordarlo todo; la privacidad, no recordar nada. La arquitectura debe equilibrar estos compromisos.
La arquitectura
Una arquitectura típica en capas:
┌─────────────────────────────────────┐
│ Working memory (in-context) │ Current conversation
├─────────────────────────────────────┤
│ Session memory (recent) │ Last N conversations
├─────────────────────────────────────┤
│ Episodic memory (long-term) │ Specific past events
├─────────────────────────────────────┤
│ Semantic memory (facts) │ Stable user facts
├─────────────────────────────────────┤
│ Procedural memory (preferences) │ How to behave for this user
└─────────────────────────────────────┘
Cada capa tiene su propia lógica de almacenamiento, recuperación y pérdida de relevancia.
Revisaremos cada una.
Capa 1: Memoria de trabajo
Ya se explicó en el artículo sobre ingeniería de contexto: es la conversación actual dentro del contexto. En conversaciones de varios turnos, se usa un contexto por niveles que conserva literalmente los turnos recientes y resume los anteriores.
La transferencia a la memoria a largo plazo se produce al final de la sesión. Se extrae y almacena la información clave de la conversación.
Capa 2: Memoria de sesión
Las sesiones recientes —por ejemplo, las últimas 10 conversaciones— se conservan con un nivel de detalle reducido y quedan disponibles para el agente en la sesión siguiente.
Implementación: un resumen por sesión, almacenado con marca de tiempo y tema. Cuando el usuario regresa, el agente tiene una referencia rápida de lo que ha estado sucediendo recientemente.
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Drafting proposal for Acme Corp",
"summary": "Drafted v1 of the Acme proposal. Decided to lead with the cost-savings angle. Alice will review and send Friday.",
"facts_learned": ["Acme is a current customer", "Alice's deadline is Friday"],
"open_items": ["Alice to review v1 by Thursday"]
}
Al iniciar una sesión nueva, se pueden cargar automáticamente los resúmenes de las 3-5 sesiones más recientes. Así, el agente conoce lo que ha ocurrido últimamente.
Esta es la forma más accesible de memoria entre sesiones: resulta fácil de implementar y aporta valor de inmediato.
Capa 3: Memoria episódica
Eventos específicos del pasado que vale la pena recordar a largo plazo. Decisiones, hitos, conversaciones importantes.
Estos episodios se extraen de las sesiones cuando son relevantes y se almacenan con metadatos detallados.
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice decided to migrate from Postgres to ClickHouse for the analytics workload, citing query performance.",
"context_summary": "After 3 weeks of evaluation including performance tests and cost analysis.",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
Recuperación: cuando resulta pertinente para la conversación actual, el agente recupera episodios relacionados mediante búsqueda semántica (genera el embedding de la consulta actual y localiza episodios coincidentes), coincidencia temática o consultas temporales (“¿qué pasó el mes pasado?”).
El desafío consiste en decidir qué se considera “un episodio digno de recordar”. No todas las conversaciones lo son. Un patrón habitual es que, al final de la sesión, un LLM extraiga los eventos relevantes: se almacenan decisiones, compromisos e hitos, pero no las conversaciones intrascendentes.
Capa 4: Memoria semántica
Hechos estables sobre el usuario que siempre deben estar disponibles. “Alice es la CEO de Acme. Su estilo preferido de comunicación es conciso. Trabaja en el huso horario de Tallinn.”
Su volumen es menor que el de los episodios, pero se recuperan con más frecuencia. En conjunto forman el “modelo del usuario” que mantiene el agente.
Implementación: un perfil estructurado.
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "CEO at Acme Corp",
"location": "Tallinn, Estonia",
"timezone": "Europe/Tallinn",
"preferred_language": "English",
"communication_style": "concise, direct, no preamble",
"expertise_areas": ["product strategy", "go-to-market"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
Las actualizaciones se producen cuando el agente aprende hechos nuevos. Después de una sesión, un LLM identifica y propone los que parecen estables; estos se incorporan automáticamente o se ponen en cola para revisión.
Es importante que los hechos semánticos sean fiables y estables. Un comentario casual durante una conversación (“tal vez pruebe Python”) no debe convertirse en un hecho semántico (“Alice prefiere Python”). El criterio de aceptación debe ser más estricto.
Un enfoque basado en confianza:
- Mencionado una vez: hecho candidato, todavía sin almacenar.
- Mencionado dos veces o de forma explícita: almacenado con confianza media.
- Confirmado explícitamente o referenciado con frecuencia: almacenado con alta confianza.
Esto evita que el agente “aprenda” hechos incorrectos de comentarios casuales.
Capa 5: Memoria procedimental
Cómo debe comportarse el agente para este usuario. Flujos de trabajo, plantillas, preferencias para acciones específicas.
Ejemplos:
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "always offer 3 time slots, never schedule before 9am",
"code_style": "Python, type hints required, dataclasses over dicts",
"tone_for_clients": "warm, direct, with explicit next steps",
"approval_process": "all customer-facing communications need Alice's review before sending"
}
}
Son patrones que el agente aplica cuando surgen tareas pertinentes.
Las actualizaciones se producen de forma explícita (“Alice, por favor siempre haz X de esta manera”) o mediante el reconocimiento de patrones (después de gestionar del mismo modo 5 solicitudes similares, se añade el patrón).
Opciones de almacenamiento
¿Dónde vive la memoria?
Base de datos SQL. Fiable, consultable y bien conocida. Cada tipo de memoria ocupa una tabla; las uniones permiten recuperarla. Es adecuada para patrones de acceso estructurados.
Base de datos vectorial. Sirve para la recuperación semántica de episodios (“encuentra recuerdos relacionados con este tema”). Se generan embeddings de los episodios y se recuperan por similitud.
Combinación. Suele ser la mejor opción: SQL para consultas estructuradas y una base vectorial para búsqueda semántica. Los elementos de memoria residen en ambas, con IDs coherentes.
Herramientas de memoria especializadas. Mem0, Letta (antes MemGPT) y Zep son capas de memoria específicas para agentes. Conviene evaluarlas si necesitas una abstracción de nivel superior.
Para la mayoría de los equipos basta con un enfoque sencillo de SQL + vector. Las herramientas especializadas son útiles, pero añaden una dependencia.
Patrones de recuperación
¿Cómo obtiene el agente la memoria en contexto?
Patrón 1: Carga automática al inicio de la sesión
Cuando comienza una nueva sesión, se carga automáticamente:
- El perfil semántico del usuario.
- Los resúmenes de las N sesiones más recientes.
- Cualquier compromiso pendiente o seguimiento.
Este es el contexto de partida del agente cuando llega el usuario.
Patrón 2: Recuperación impulsada por consultas
Cuando el mensaje del usuario sugiere temas pasados, se recuperan episodios relevantes.
Ejemplo: el usuario pregunta “¿cuál fue la conclusión de nuestra discusión sobre bases de datos?” El agente busca episodios con “bases de datos” y recupera el relevante.
Implementación: genera el embedding del mensaje del usuario, busca episodios similares e incorpóralos al contexto.
Patrón 3: Herramientas de memoria explícitas
El agente tiene herramientas para consultar la memoria:
search_episodes(query): encontrar eventos pasados específicos.get_user_profile(): extraer el perfil semántico.list_open_items(): compromisos pendientes.
El agente decide cuándo llamar a estas herramientas según la conversación.
Patrón 4: Enriquecimiento de memoria en segundo plano
Un proceso en segundo plano revisa periódicamente la memoria y:
- Consolida episodios relacionados en temas.
- Actualiza la confianza en hechos.
- Reduce la prioridad de memorias antiguas que no se han consultado.
Este es el “mantenimiento de la memoria”: conservar su utilidad a lo largo del tiempo.
Escritura de la memoria
¿Cuándo se escribe la memoria?
Extracción al finalizar la sesión
Es el patrón más fiable. Cuando termina una sesión:
- Un LLM analiza la conversación.
- Extrae:
- Resumen de la sesión.
- Eventos notables (para memoria episódica).
- Nuevos hechos (para memoria semántica).
- Señales de preferencia (para memoria procedimental).
- Actualiza y almacena.
Este procesamiento por lotes mantiene ágil la experiencia durante la sesión, porque no escribe en memoria mientras transcurre la conversación.
Prompt para extracción:
Analyze this conversation. Output JSON with:
1. summary: 2-3 sentence summary of what happened.
2. notable_events: array of significant events worth remembering (decisions made, milestones, important context).
3. new_facts: array of stable facts learned about the user (only include if you have high confidence).
4. preference_signals: array of preferences observed (only if expressed clearly or repeated).
5. open_items: array of unresolved items the user might want to revisit.
Be conservative. Only include items with high confidence. Better to miss something than to hallucinate.
Actualizaciones en tiempo real para hechos de alto valor
Para algunos hechos, esperar hasta el final de la sesión es incorrecto. Si un usuario dice “en realidad, mi nombre es Alex, no Alice” — la corrección debe aplicarse inmediatamente.
Un patrón consiste en hacer que el agente detecte en tiempo real las correcciones explícitas o los hechos importantes y actualice la memoria de inmediato.
Esto requiere un diseño cuidadoso — el LLM podría “aprender” hechos incorrectos. Algunos equipos requieren confirmación del usuario antes de aplicar actualizaciones en tiempo real.
Actualizaciones iniciadas por el usuario
El usuario puede decir explícitamente al agente qué recordar:
- “Por favor recuerda que prefiero X”.
- “Olvida lo que dije sobre Y”.
- “Siempre haz Z”.
Estas instrucciones deben tratarse como operaciones de primer nivel y aplicarse de inmediato. Son las señales de mayor confianza.
Una herramienta específica que el agente puede ofrecer:
remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()
Dar este control a los usuarios genera confianza.
Olvido y pérdida de relevancia
La memoria que crece sin límite se convierte en ruido. La pérdida gradual de relevancia es esencial.
Pérdida de relevancia basada en el tiempo
Es menos probable que se recuperen las memorias más antiguas. Implementación:
- Puntúa la recuperación por
relevance * recency_decay. - En la práctica, las memorias antiguas desaparecen salvo que se mencionen de forma explícita.
Retención basada en importancia
Los episodios importantes se conservan durante más tiempo; los triviales pierden relevancia con mayor rapidez.
- Etiqueta los episodios según su importancia en el momento de escribirlos.
- Eventos críticos: retención indefinida.
- Eventos rutinarios: pérdida gradual de prioridad a lo largo de meses.
Olvido iniciado por el usuario
El usuario puede solicitar que se eliminen memorias específicas.
- Hechos específicos.
- Períodos de tiempo específicos.
- Temas específicos.
Implementación: una operación de eliminación que elimina (o marca como eliminada) los elementos relevantes.
Eliminación impulsada por cumplimiento
Algunos requisitos legales (el derecho al olvido del RGPD o las leyes de conservación de datos) exigen la eliminación.
- Eliminación de cuenta de usuario → todas las memorias eliminadas.
- Eliminación de datos previa solicitud → memorias específicas eliminadas.
- Límites de conservación → eliminación automática después de N meses.
Estas capacidades deben incorporarse desde el principio. Añadirlas a posteriori resulta costoso.
Consideraciones de privacidad
La memoria contiene datos sensibles: el agente sabe mucho sobre el usuario. Deben contemplarse los siguientes aspectos:
Cifrado en reposo
Los datos de memoria deben estar cifrados. Es una práctica estándar.
Control de acceso
¿Quién puede ver la memoria de un usuario? ¿Solo el propio usuario, solo el sistema o también el personal de soporte bajo ciertas condiciones? Debe definirse con claridad y auditarse cada acceso.
Manejo de PII
La información de identificación personal (nombres reales, direcciones o datos financieros) debe etiquetarse y tratarse con cuidado. Requiere controles de acceso y procedimientos de eliminación específicos.
Visibilidad del usuario
Los usuarios deben poder ver qué recuerda el agente sobre ellos. Es lo correcto desde el punto de vista ético y también ofrece una buena experiencia de usuario. Proporciona un “panel de memoria”.
What the agent remembers about you:
Profile:
- Name: Alice Tamm
- Role: CEO at Acme Corp
- Communication style: concise, direct
Recent sessions:
- 2026-05-14: Drafted proposal for Acme
- 2026-05-12: Reviewed Q1 results
- ...
Preferences:
- Prefers concise responses
- Uses Notion, Slack, Linear
[Edit] [Delete specific items] [Delete all]
Esta transparencia genera confianza. Una memoria oculta resulta inquietante.
Compartir entre contextos
Si el usuario tiene varios “modos” (agente de trabajo y agente personal), quizá quiera mantener separadas sus memorias. No deben compartirse automáticamente entre modos salvo que el usuario lo solicite.
Modos de fallo comunes
Algunos patrones:
Fallo 1: Memorias alucinadas
El agente afirma recordar cosas que no sucedieron. “La semana pasada acordamos X” — pero X nunca se discutió.
Causa: el LLM “rellena” memorias que suenan plausibles durante la extracción o recuperación.
Solución: fundamentar las operaciones de memoria en datos reales de la conversación. El LLM extrae la información y esta se verifica contra la transcripción original. Las memorias alucinadas deben marcarse.
Fallo 2: Aprendizaje de hechos incorrectos
El agente afirma con confianza hechos incorrectos. “Dijiste que prefieres Python” cuando en realidad dijiste que te obligaron a usar Python en el trabajo.
Causa: malinterpretación durante la extracción.
Solución: umbrales de confianza. Solo aprender de declaraciones explícitas, repetidas o confirmadas. El usuario puede corregir.
Fallo 3: Fugas de privacidad
Los recuerdos de un usuario aparecen en la conversación de otro. Es catastrófico.
Causa: errores en la lógica de aislamiento por usuario.
Solución: imponer el aislamiento por usuario en las capas de almacenamiento y recuperación, y auditarlo. Nunca se debe confiar en que el LLM haga el filtrado.
Fallo 4: Saturación de la memoria
Después de un año, la memoria ocupa megabytes por usuario. La recuperación se ralentiza y los costes aumentan.
Causa: no hay reducción gradual de relevancia ni poda.
Solución: reducir agresivamente la prioridad. Después de unos meses, la mayor parte de la memoria queda prácticamente inaccesible por su baja prioridad de recuperación. Debe compactarse periódicamente.
Fallo 5: Hechos obsoletos
El usuario cambió de rol hace 6 meses. El agente aún menciona el rol antiguo.
Causa: los hechos no se actualizan cuando se superan.
Solución: detectar contradicciones. Cuando un hecho nuevo contradice a uno anterior, prevalece el nuevo, con confirmación si existe incertidumbre.
Fallo 6: Consolidación que distorsiona la memoria
La consolidación de memoria en segundo plano a veces reescribe memorias de manera que se pierde información.
Causa: resumen agresivo sin preservar hechos clave.
Solución: la consolidación debe preservar los hechos de forma explícita. Hay que probarla con transcripciones reales de memoria.
Ejemplo práctico: asistente personal con memoria
Un caso real: un asistente personal de IA para usuarios individuales.
Capas de memoria:
- Trabajo: conversación actual.
- Sesión: últimas 7 sesiones en forma resumida.
- Episódica: los 100 eventos relevantes más recientes, con búsqueda semántica.
- Semántica: perfil del usuario (nombre, rol, preferencias, herramientas).
- Procedimental: flujos de trabajo explícitos que el usuario ha establecido.
Almacenamiento:
- SQL (Postgres): perfil estructurado, sesiones, episodios, procedimientos.
- Base de datos vectorial (pgvector): búsqueda semántica episódica.
Operaciones:
- Inicio de sesión: carga automática del perfil semántico + últimas 3 sesiones + elementos pendientes.
- Durante la sesión: recuperación episódica activada por pertinencia temática.
- Fin de sesión: extracción basada en LLM; el usuario puede revisar lo que se aprendió.
- En segundo plano: consolidación semanal (combinar episodios relacionados y reducir la prioridad de los obsoletos).
Controles del usuario:
- Panel de memoria que muestra lo que se recuerda.
- Editar/eliminar elementos individuales.
- Botón “Olvida la última hora”.
- Eliminación completa de cuenta (borra todo).
Resultados:
- Continuidad: los usuarios indican que el agente “mantiene el hilo” entre sesiones.
- Personalización: el estilo de respuesta se ajusta a las preferencias del usuario sin que tenga que volver a indicarlas.
- Privacidad: controles explícitos dan confianza a los usuarios.
- Coste: la memoria representa ~5-15% del uso de tokens por sesión. Compensa.
Modos de fallo abordados:
- Memorias alucinadas detectadas durante la verificación de extracción.
- Hechos incorrectos detectados mediante umbrales de confianza.
- Privacidad garantizada en cada punto de almacenamiento y recuperación.
- Saturación controlada mediante pérdida gradual de relevancia y consolidación.
Este es un sistema de memoria apto para producción. No es trivial, pero está al alcance de un equipo centrado en el objetivo.
Herramientas especializadas
Una nota sobre las opciones de memoria como servicio:
Mem0. De código abierto y bien diseñado. Gestiona muchos de los patrones anteriores. Conviene evaluarlo si no quieres construir desde cero.
Letta (MemGPT). Sigue un paradigma distinto: el propio LLM gestiona la memoria mediante llamadas a herramientas. Es potente, pero más complejo.
Zep. Capa de memoria alojada, fácil de integrar.
Cognee. Una opción más reciente, con memoria basada en grafos de conocimiento.
Estas herramientas ahorran tiempo de desarrollo. También añaden una dependencia y limitan la personalización. En sistemas de producción maduros suele tener sentido construir la memoria; para prototipos o equipos pequeños, utilizar una herramienta es razonable.
El mensaje clave
La memoria a largo plazo hace que los agentes parezcan inteligentes y mantengan la continuidad, en lugar de comportarse como si fueran amnésicos. También es una de las funciones más difíciles de implementar correctamente.
La arquitectura está en capas:
- Memoria de trabajo (en contexto).
- Memoria de sesión (sesiones recientes).
- Memoria episódica (eventos específicos).
- Memoria semántica (hechos estables).
- Memoria procedimental (preferencias y flujos de trabajo).
Cada capa tiene su propia lógica de almacenamiento, recuperación y pérdida de relevancia. Todas contribuyen a que el agente siga siendo útil a lo largo del tiempo.
Los patrones que importan:
- Extracción conservadora (no inventar hechos).
- Aprendizaje basado en confianza (no aprender de comentarios casuales).
- Olvido activo (pérdida gradual de relevancia y poda).
- Control del usuario (transparencia y posibilidad de edición).
- Protección de la privacidad (en cada capa).
Bien implementada, la memoria transforma la IA de “un desconocido nuevo en cada conversación” en “un colaborador útil y constante”. Esa es la diferencia entre la IA como herramienta y la IA como colega.
Para los agentes que deben acompañarte a largo plazo —durante días, semanas o meses—, la memoria no es opcional, sino fundamental. Constrúyela de forma deliberada, con las capas y la disciplina que necesita.
