La keyword principal es memoria de agentes de IA; la intención es práctica: un equipo busca hacer que un agente recuerde lo útil entre conversaciones sin crear un historial infinito, compartido o imposible de borrar.
TL;DR
Separa tres cosas. El estado de sesión mantiene una tarea en curso; la memoria persistente conserva datos seleccionados entre sesiones; RAG recupera conocimiento documental externo. Parecen similares porque los tres aportan contexto, pero tienen propietarios, ciclos de vida y fallos distintos.
Mi postura: no empieces por una base vectorial ni por un extractor automático de preferencias. Empieza por una tabla de memoria con ámbito de tenant, dueño, tipo, procedencia, caducidad y borrado. Si no puedes responder quién escribió un dato, por qué se recuperó y cómo se elimina, todavía no tienes memoria de producción.
Qué es memoria de un agente — y qué no
La memoria de un agente es información conservada para cambiar de forma útil una decisión futura. Una preferencia explícita como ‘responde en español’, una restricción de cuenta o el resumen de un ticket abierto pueden ahorrar repetición. Un transcript completo, un log de tool calls o una copia del manual interno no se convierten automáticamente en memoria solo por persistirlos.
El estado corto vive dentro de una conversación, thread o ejecución. LangGraph lo modela como estado persistido por thread; un store de largo plazo cruza threads mediante namespaces. RAG tampoco es memoria de usuario: responde ‘qué dice el corpus permitido’, mientras la memoria responde ‘qué dato estable y autorizado tengo sobre este actor o tarea’.
La memoria útil entra por una puerta de extracción, se recupera con filtros y conserva una salida explícita: caducidad o borrado.
El modelo de datos mínimo
Una memoria durable necesita más que
texty un embedding. Guardatenant_id,actor_id,memory_id,kind,content,source,confidence,created_at,expires_at,deleted_aty una versión de extracción. Así puedes restringir la query antes de la similitud, explicar el origen y cambiar el extractor sin fingir que todas las notas son equivalentes.
kindevita mezclar hechos, preferencias, resúmenes y reglas operativas. Una preferencia explícita puede entrar con alta confianza; una inferencia de un modelo debería tener vida corta, fuente y una revisión más estricta. La procedencia no es burocracia: el agente debe poder mostrar, corregir o ignorar una memoria.
Código: contrato de escritura y recuperación
memory_contract.py
ALLOWED_SOURCES = {"explicit_user", "trusted_system"}<br>def can_persist(m):<br> return (m.source in ALLOWED_SOURCES and m.kind in {"preference", "fact", "task_summary"} and len(m.content) <= 500)<br><br>def retrieval_scope(identity):<br> # identity comes from authentication, never from prompt text<br> return {"tenant_id": identity.tenant_id, "actor_id": identity.actor_id, "not_expired": True, "limit": 4}<br><br># Apply this scope BEFORE vector similarity or model context injection.
El modelo puede proponer una candidata, pero identidad, tipos permitidos, tamaño, retención y filtros los decide el runtime autenticado. El tenant_id no se extrae del prompt ni se acepta como argumento de una tool generalista.
Aísla antes de buscar
La similitud vectorial debe ocurrir dentro de un ámbito ya autorizado. Primero filtra tenant, actor, clase de memoria y vigencia; después calcula similitud; por último limita la cantidad de contexto. Hacerlo al revés convierte una búsqueda ‘inteligente’ en una fuga entre clientes.
¿Te está sirviendo? Hay una dosis cada semana
Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Lo que conviene comprobar
En una base relacional, Row-Level Security puede ser una segunda barrera para que una consulta mal construida no lea filas de otro tenant. No sustituye la autorización de aplicación, pero evita depender de que cada developer recuerde el WHERE tenant_id = ... correcto.
Los namespaces de LangGraph y los filtros de metadata de AgentCore expresan el mismo principio: la memoria no es una colección global. Diseña la clave de aislamiento antes de escoger el motor.
Extrae poco, consolida con reglas
Hay dos momentos para crear memoria. En el hot path, el agente propone o guarda un dato antes de responder: es inmediato, pero añade latencia y riesgo. En segundo plano, un job revisa eventos cerrados y consolida candidatos: permite mejores reglas, aunque el recuerdo llega después. Para preferencias o acciones sensibles, prefiero confirmación explícita.
Consolidar significa decidir entre añadir, actualizar, ignorar o expirar. AgentCore documenta estrategias distintas para semántica, preferencias, resúmenes y episodios; incluso si no usas AWS, cada tipo necesita reglas de extracción y de conflicto distintas.
Da fecha de caducidad a lo que puede quedar obsoleto: estado de un incidente, proyecto activo, configuración temporal o inferencias. Una memoria sin expires_at suele vivir más que su verdad. Para datos de alto impacto, ‘olvidar’ debe eliminar texto, embedding e índices derivados.
La memoria es input no confiable
Una memoria recuperada se parece a una tool response: puede contener instrucciones hostiles, datos equivocados o una preferencia revocada. No la concatentes como si fuera una orden del sistema. Etiquétala como contexto, conserva procedencia y no permitas que una frase almacenada habilite pagos, despliegues o acceso a datos.
El riesgo no se limita a un atacante. Un extractor puede convertir ‘estoy de viaje esta semana’ en una preferencia permanente; un tool puede incorporar texto de una web; una migración puede duplicar registros. La defensa es la misma: allowlist de tipos, confianza limitada, auditoría de escritura y evaluación de conflictos.
Añade casos de memoria en tus evals: dato correcto, dato caducado, dato de otro tenant, instrucción adversarial persistida, corrección explícita y borrado. Mide no solo si el agente recuerda, sino si ignora un recuerdo cuando su procedencia, ámbito o fecha no permiten usarlo.
Privacidad, retención y coste
Persistir memoria en tu base de datos no elimina los datos que envías al proveedor de modelo. Si reinyectas una preferencia en cada prompt, ese contenido sigue sujeto a los controles de datos y retención del proveedor. OpenAI, por ejemplo, distingue logs de abuse monitoring de application state y documenta opciones por endpoint; revisa el contrato del proveedor que realmente usas.
Minimiza antes de cifrar. No guardes secretos, identificadores completos, transcripciones crudas ni atributos sensibles si el caso de uso funciona con una preferencia breve y controlada. Cifrado, acceso mínimo y auditoría son necesarios; no justifican coleccionar datos que el agente no necesita.
El coste tiene tres partes: extracción, embeddings/almacenamiento y tokens al recuperar. Recuperar ocho recuerdos vagos puede empeorar una respuesta y subir coste. Empieza con tres o cuatro registros muy relevantes y mide si cambian la decisión.
Observabilidad y evals
Registra para cada turno: memoria candidata, decisión de persistencia, versión de extractor, namespace, filtros aplicados, IDs recuperados, score, caducidad, tokens añadidos y si la respuesta la usó. Redacta contenido sensible en los logs; los IDs y metadatos suelen bastar para depurar.
Una métrica útil es la tasa de recuperación accionable: de las memorias inyectadas, cuántas cambiaron una respuesta o tool call de forma correcta. Otra es la tasa de corrección o borrado. Si hay muchas correcciones, el extractor está promoviendo ruido o las reglas son demasiado amplias.
Conecta esos eventos a tus trazas. La observabilidad GenAI explica la ejecución; aquí debes poder responder otra pregunta: ‘¿qué recuerdo entró y por qué este agente lo creyó?’. Sin esa relación, una personalización errónea no se puede reproducir.
Plan de adopción en una semana
Día 1: elige un único caso de bajo riesgo, como idioma, formato de salida o resumen de ticket. Escribe qué dato puede guardar y qué queda prohibido.
Día 2: modela tenant, actor, tipo, origen, caducidad y borrado; obliga a que identidad venga de autenticación, no del prompt.
Día 3: implementa lectura filtrada y limitada con un test de aislamiento cruzado y otro de expiración.
Día 4: permite candidatos de escritura con allowlist y confirmación para preferencias; rechaza tool output y texto web por defecto.
Día 5: crea listar, corregir y borrar, incluyendo embeddings e índices derivados; deja evidencia auditable sin conservar contenido eliminado.
Día 6: ejecuta evals con memoria correcta, falsa, caducada, revocada y adversarial; mide utilidad, latencia y tokens.
Día 7: activa para una cohorte pequeña y revisa recuperaciones, correcciones y costes antes de ampliar tipos de memoria o usuarios.
Errores que no aceptaría en producción
- Usar todo el historial del chat como memoria de largo plazo.
- Dejar que el modelo elija tenant, usuario o namespace desde lenguaje natural.
- Buscar por embedding antes de aplicar filtros obligatorios.
- Persistir tool output, páginas web o texto de usuario sin tipo, fuente y política de promoción.
- No tener
expires_at, borrado verificable ni gestión de correcciones. - Inyectar recuerdos recuperados como instrucciones privilegiadas.
- Medir solo recall y no fugas, correcciones, coste ni decisiones erróneas.
Preguntas frecuentes
¿Qué es la memoria de un agente de IA?
Es un conjunto selectivo de datos persistentes que puede cambiar una decisión en una sesión futura. No es el historial completo ni un RAG documental; debe llevar ámbito, procedencia, tipo y ciclo de vida.
¿Cuál es la diferencia entre estado y memoria a largo plazo?
El estado pertenece a una conversación o ejecución y suele recuperarse por thread. La memoria a largo plazo cruza sesiones y debe aislarse por tenant, usuario o aplicación con namespaces y controles explícitos.
¿Necesito una base vectorial para memoria de agentes?
No siempre. Preferencias y claves estructuradas se resuelven mejor con consultas exactas. Usa búsqueda semántica solo cuando el tipo de recuerdo y el volumen justifican recuperar por significado, siempre después de filtrar ámbito y vigencia.
¿Cómo evito que un agente recuerde datos de otro cliente?
Obtén identidad desde autenticación, filtra tenant y actor antes de la similitud, limita resultados y añade una barrera de datos. Prueba explícitamente la fuga cruzada en CI.
¿Cuánto tiempo debe vivir una memoria?
Lo mínimo que haga útil el caso. Preferencias estables pueden durar más con control de corrección; contexto de tareas e inferencias necesitan expiración o revisión.
¿La memoria persistente es segura frente a prompt injection?
No por sí sola. Todo recuerdo recuperado es input no confiable: conserva fuente, etiqueta contexto, evita que habilite acciones y evalúa instrucciones adversariales o datos envenenados.
Cómo añadir memoria segura a un agente de IA
- Acotar el caso. Elige una preferencia o resumen de bajo riesgo y define qué datos nunca se guardan.
- Definir el ámbito. Obtén tenant y actor desde la identidad autenticada, no desde texto libre ni argumentos de una tool.
- Modelar procedencia. Guarda tipo, fuente, confianza, fecha, caducidad y versión del extractor junto al contenido.
- Filtrar antes de recuperar. Aplica tenant, actor, tipo y vigencia antes de búsqueda semántica; devuelve pocos resultados.
- Controlar escritura. Permite solo fuentes y tipos en allowlist; confirma preferencias importantes y procesa candidatos inciertos en segundo plano.
- Dar salida al dato. Implementa listar, corregir, expirar y borrar eliminando también índices y embeddings derivados.
- Evaluar adversarialmente. Prueba recuerdos caducados, cruzados, falsos, revocados y hostiles; mide utilidad, fugas y coste.
- Desplegar con trazas. Registra decisiones e IDs redactados, revisa una cohorte pequeña y amplía solo cuando los datos sean defendibles.
Fuentes y referencias
- LangChain: conceptos de memoria
- LangChain: memoria a largo plazo
- LangGraph: añadir memoria
- Amazon Bedrock AgentCore Memory
- AgentCore: filtros de metadata
- PostgreSQL: Row-Level Security
- OpenAI API: controles de datos
- OWASP: prompt injection
También te puede interesar
- LangGraph: agentes Python con estado y checkpoints
- Búsqueda híbrida RAG: BM25, vectores y reranking
- Prompt injection en agentes: prevención y evals
- OpenTelemetry GenAI para observar agentes
- OpenAI Responses API y function calling fiable
Recibe una lectura semanal de herramientas IA para devs
Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.
Top comments (0)