Problema
Cuando se habla de memoria en agentes, muchas demos muestran lo mismo: el agente recuerda preferencias, conversaciones o detalles personales. Eso puede ser util en producto consumer, pero es insuficiente para empresa.
Una organizacion no necesita que el agente “recuerde el chat”. Necesita que recuerde que decision tomo, con que fuentes, que herramienta ejecuto, que fallo, quien aprobo, que resultado produjo y que aprendizaje debe cambiar el siguiente ciclo.
La memoria util no nace en la nostalgia conversacional. Nace en la operacion.
Tesis
La siguiente frontera de agent memory sera memory from trace.
Un agente enterprise deberia construir memoria desde sus propias trazas: pasos, tool calls, inputs, outputs, recuperaciones, errores, escalados, costes y outcomes. Esa memoria no es un diario. Es una capa de aprendizaje gobernable.
Si no hay trace, no hay memoria fiable. Solo hay resumen.
Framework
Una memoria operativa necesita cuatro registros:
- Decision: que eligio el agente y por que.
- Ejecucion: que herramientas llamo, con que parametros y que devolvieron.
- Resultado: que paso despues, si hubo aprobacion, fallo o retrabajo.
- Aprendizaje: que regla, excepcion o patron debe sobrevivir al siguiente run.
Mini-caso: un agente de customer success prepara QBRs. Si solo recuerda chats, puede personalizar tono. Si recuerda trazas, sabe que datos de CRM fueron fiables, que dashboard fallo, que objecion aparecio, que slide se descarto y que decision tomo el owner. La segunda memoria mejora el proceso; la primera solo mejora la conversacion.
Senal medible: porcentaje de memorias persistentes que pueden vincularse a una traza, fuente, owner o outcome.
Postura: la memoria sin lineage es una nueva superficie de alucinacion.
Por que importa ahora
LangGraph documenta persistencia de estado mediante checkpointers y memoria cross-thread mediante stores. Para produccion recomienda stores persistentes como Postgres, MongoDB o Redis. OpenTelemetry mantiene convenciones semanticas para sistemas GenAI, incluyendo spans de modelo, agentes, herramientas, retrieval, eventos y metricas.
Esto muestra una separacion importante. Persistir memoria no basta. Tambien hay que observar de donde viene esa memoria, que datos sensibles toca, que tool call la genero y si puede reutilizarse con seguridad.
En agentes enterprise, memoria, observabilidad y compliance son el mismo problema visto desde tres angulos.
Anti-ejemplo
“Guarda un resumen de cada conversacion y usalo despues.”
Eso parece memoria, pero puede convertir errores en contexto permanente. Un resumen no captura permisos, fuente, owner, estado de aprobacion ni resultado. Peor: puede reintroducir instrucciones no confiables en sesiones futuras.
Protocolo (3 pasos)
- Distingue memoria de cache. No todo lo que se reutiliza merece sobrevivir.
- Exige lineage por entrada. Cada memoria persistente debe apuntar a evento, fuente o decision.
- Caduca lo operativo. Reglas duraderas y datos temporales no deben vivir en la misma capa.
| Tipo de memoria | Fuente correcta | Riesgo |
|---|---|---|
| preferencia | usuario o owner | personalizacion falsa |
| decision | traza y aprobacion | repetir criterio viejo |
| dato operativo | sistema fuente | obsolescencia |
| error | log y resultado | aprender el patron equivocado |
| regla | decision governance | memoria sin autoridad |
Relacionado
- AI Decision Ledger: el registro que separa aprendizaje de opinion
- Agent Reliability Score: como saber si un agente merece autonomia
- Rollback Design for AI Workflows: como apagar automatizaciones sin romper la operacion
Fuentes consultadas
- LangGraph Persistence
- OpenTelemetry: Semantic conventions for generative AI systems
- OpenTelemetry: Semantic conventions for generative client AI spans
Proximo paso
Elige un agente que ya uses. Antes de darle memoria, imprime una traza de una ejecucion completa. Si no puedes explicar que paso, que fuente uso y que resultado produjo, no esta listo para recordar.