Memoria de agentes de IA: arquitectura, privacidad y borrado en producción

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.

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.

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.

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.

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.

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.