Problema
Muchos agentes no fallan porque el modelo sea malo. Fallan porque recuerdan mal.
Mezclan historial de chat, preferencias, datos de negocio, instrucciones, errores antiguos, resultados parciales y decisiones aprobadas dentro del mismo contexto. Al principio parece funcionar. Luego aparece el drift: el agente empieza a recuperar cosas irrelevantes, repite criterios caducados, confunde preferencias con políticas y trata un fallo pasado como si fuera una regla.
Eso no es memoria. Es acumulación.
Un agente enterprise necesita distinguir qué está pensando ahora, qué ocurrió antes, qué sabe que es verdad, cómo debe hacer una tarea, qué tiene pendiente, qué comparte con otros agentes y qué debe olvidar.
Tesis
La memoria de agentes no es una feature. Es un sistema de estado.
El stack correcto no intenta que el agente “recuerde más”. Intenta que recuerde con semántica: cada tipo de memoria tiene fuente, caducidad, permisos, forma de recuperación y criterio de actualización distintos.
Cuando todo vive en una bolsa de contexto, el agente se degrada. Cuando cada memoria vive en su capa, el sistema puede auditar, corregir y escalar.
Framework
Un stack de memoria enterprise tiene siete capas.
| Capa | Qué guarda | Riesgo si se mezcla |
|---|---|---|
| Working memory | Lo necesario para la tarea actual | Saturar la ventana con ruido |
| Episodic memory | Qué pasó, cuándo y con qué resultado | Repetir errores como si fueran aprendizaje |
| Semantic memory | Hechos, entidades, relaciones y estado estable | Convertir rumores o outputs en verdad |
| Procedural memory | Cómo hacer una tarea, workflow o skill | Ejecutar procedimientos viejos |
| Hierarchical memory | Qué vive caliente, templado, frío o archivado | Recuperar demasiado o demasiado poco |
| Prospective memory | Qué debe recordarse o ejecutarse después | Olvidar seguimientos, deadlines y compromisos |
| Shared memory | Qué deben compartir varios agentes | Crear versiones incompatibles de la realidad |
La diferencia clave no es técnica. Es operativa.
Un dato de CRM no debe entrar por la misma puerta que una preferencia de tono. Una lección aprendida de un fallo no debe tener el mismo peso que una política aprobada. Un procedimiento usado por ventas no debe actualizarse automáticamente porque un agente lo improvisó una vez.
La memoria buena no es más larga. Es más gobernable.
Por que importa ahora
Los frameworks ya están separando estas capas. LangGraph distingue memoria de corto plazo ligada al thread y memoria de largo plazo mediante stores. OpenAI Agents SDK documenta sesiones para mantener historial entre runs y permite custom sessions con políticas de retención, cifrado o metadatos. Letta trabaja memoria como parte explícita de la arquitectura del agente, con memoria editable y capas inspiradas en MemGPT.
La investigación va en la misma dirección. MemGPT planteó una arquitectura inspirada en sistemas operativos para gestionar distintos niveles de memoria más allá de la ventana de contexto. CoALA describió agentes con componentes modulares de memoria, espacio de acciones y procesos de decisión.
Traducción práctica: la memoria ya no es “añade vector database”. Es una pieza de runtime, gobernanza, seguridad y diseño operativo.
Para empresa, esto cambia tres cosas:
- Coste: recuperar memoria irrelevante aumenta tokens, latencia y retrabajo.
- Riesgo: memoria sin permisos puede filtrar datos o reactivar instrucciones no confiables.
- Calidad: memoria sin caducidad convierte decisiones antiguas en criterio vigente.
Anti-ejemplo
El anti-ejemplo típico es construir “memoria” con una tabla de embeddings sobre todo el historial.
Cada conversación, ticket, documento, decisión, error y preferencia se trocea, se vectoriza y se recupera por similitud. Parece sofisticado. En producción genera problemas muy concretos:
- similitud no significa relevancia
- recuerdo no significa autoridad
- historial no significa verdad
- experiencia no significa procedimiento
- dato antiguo no significa dato válido
El agente no necesita recuperar lo parecido. Necesita recuperar lo que tiene permiso, vigencia, fuente y utilidad para la decisión actual.
Protocolo (3 pasos)
-
Define tipos de memoria antes de elegir tecnología. Working, episodic, semantic, procedural, prospective y shared no deberían compartir la misma política de escritura.
-
Añade metadatos de autoridad. Cada memoria persistente necesita fuente, owner, fecha, permiso, caducidad y razón de uso. Sin eso, no puedes distinguir aprendizaje de contaminación.
-
Diseña el write-path, no solo el retrieval. Lo importante no es solo qué recuerda el agente. Es quién puede escribir memoria, cuándo se consolida, cómo se corrige y cómo se borra.
| Decisión | Pregunta | Señal sana |
|---|---|---|
| Guardar | Esto debe sobrevivir al run actual | Memoria con fuente y owner |
| Consolidar | Esto cambia una regla o procedimiento | Revisión humana o criterio automático trazable |
| Recuperar | Esto ayuda a la decisión actual | Ranking por utilidad, vigencia y permiso |
| Caducar | Esto ya no debería influir | TTL, versionado o archivo |
| Compartir | Otros agentes deben usarlo | Estado común con control de acceso |
La regla simple: si no puedes explicar por qué una memoria está ahí, el agente tampoco debería usarla.
Relacionado
- Agent Memory from Trace: la memoria útil no vive en el chat, vive en la operación
- Context Budgeting: la arquitectura de contexto que ahorra tokens sin cegar al agente
- Context Supply Chain: la cadena de suministro invisible de la IA corporativa
- AI Traces: la capa que convierte agentes en sistemas auditables
- Tool Registry: el mapa de riesgos que necesitan los agentes enterprise
Fuentes consultadas
- LangGraph: Memory overview
- OpenAI Agents SDK: Sessions
- Letta Docs: Memory overview
- MemGPT: Towards LLMs as Operating Systems
- CoALA: Cognitive Architectures for Language Agents
Proximo paso
Audita un agente real con una pregunta incómoda: qué memoria puede escribir, qué memoria puede leer y qué memoria puede compartir.
Si la respuesta es “depende del prompt”, no tienes memoria. Tienes contexto acumulado. El siguiente paso es diseñar el stack de estado: capas, permisos, caducidad, trazas y criterios de consolidación.