Databricks quiere que los agentes recuerden lo de ayer. Lo difícil es qué deben olvidar

Si le da a un agente todo lo que ha visto, no mejora mucho. En los benchmarks abiertos de la nueva investigación de memoria de Databricks, un agente alimentado con su historial de conversación completo obtuvo un 87,8%. El mismo agente con una memoria curada obtuvo un 88,1%, leyendo unos 8.400 tokens de entrada por pregunta en lugar de 103.000. En los benchmarks con historiales más largos, el contexto completo rindió peor: el material extra lo confundía.

Ese resultado es lo más útil del lanzamiento de Agent Memory que Databricks hizo el 20 de octubre, ahora en beta para agentes construidos sobre su plataforma. Recordar es fácil. El trabajo de diseño está en decidir qué conservar, qué reescribir y qué descartar.

Qué lanzó Databricks

Agent Memory guarda tres cosas en Lakebase, el Postgres serverless de Databricks, aprovisionado en el workspace del cliente y operado por Databricks:

• Sesiones gestionadas: el historial ordenado de mensajes, llamadas a herramientas y resultados.
• Memoria gestionada: hechos de largo plazo sobre el perfil y las preferencias de un usuario, conocimiento de dominio y flujos de trabajo que funcionaron.
• Pipelines de memoria: trabajos en segundo plano, bajo demanda o según una programación, que destilan las sesiones en memoria. Extraen hechos duraderos, eliminan duplicados y reemplazan los hechos que contradicen conversaciones más recientes.

Las memorias personales tienen alcance por usuario. Los desarrolladores pueden leer, exportar y borrar lo que un agente guarda sobre cada usuario, y pueden indicar a los pipelines qué retener.

La investigación que lo sustenta, MemCurrent, separa la memoria episódica (trazas de sesión en bruto, que solo se añaden) de la memoria derivada (aprendizajes destilados que se guardan como archivos en una base de conocimiento jerárquica, con un índice que se carga al inicio de cada sesión). Un pipeline de consolidación offline, al que Databricks llama “dreaming”, fusiona duplicados y resuelve conflictos.

Los números, con su alcance

En un benchmark interno construido con conversaciones reales del agente de datos Genie de Databricks (114 casos de prueba, 29 usuarios, 2.233 sesiones históricas), MemCurrent alcanzó una tasa de éxito del 68,4%. Sin memoria, el agente acertó el 22,3%; con Mem0, un backend de memoria popular, el 43,9%; con las memorias correctas inyectadas a mano, el techo era del 78,6%. Frente a no tener memoria, MemCurrent triplicó la tasa de éxito y corrió 1,35 veces más rápido con un coste 1,44 veces menor.

Dos advertencias. El benchmark proviene de un solo workspace y un solo agente, y es de Databricks. Y la ablación más interesante es fácil de pasar por alto: la memoria derivada por sí sola obtuvo un 66,1%, la memoria episódica por sí sola un 35,8%. Casi todo el valor vino de la capa curada, no de conservar el historial en bruto.

Tres tipos de estado del agente, tres dueños distintos

Historial episódico

• Trazas de sesión en bruto
• Llamadas a herramientas y resultados
• Solo se añaden

Evidencia de lo que ocurrió

Memoria derivada

• Perfil y preferencias
• Conocimiento de dominio
• Flujos de trabajo que funcionaron

La reescribe un pipeline; puede estar mal

Sistema de registro

• Maestro de clientes
• Procedimientos aprobados
• Transacciones

La memoria nunca lo reemplaza

El problema de olvidar

La memoria persistente convierte a un agente en un almacén de datos, como argumentamos al describir la memoria de agentes como almacenamiento de datos empresarial. Agent Memory lo hace concreto y plantea cuatro preguntas que el anuncio no responde del todo.

Obsolescencia. Un pipeline de consolidación que reemplaza hechos contradichos resuelve el caso en que un usuario dice algo nuevo. No resuelve el caso en que el mundo cambia y nadie se lo cuenta al agente: una reorganización, una nueva regla de precios, un proveedor que se cae. La memoria derivada necesita una regla de caducidad o de revalidación, no solo una regla de conflicto.

Errores de consolidación. Un pipeline que reescribe la memoria también puede equivocarse, fusionando dos hechos distintos o conservando una excepción como regla. Databricks describe qué hace el pipeline, no cómo se detectan sus errores. Los equipos deberían muestrear las entradas consolidadas igual que muestrean cualquier salida automatizada.

Retención de la capa bruta. La memoria episódica solo se añade, y ninguno de los dos posts describe un calendario de retención para ella. Ante una solicitud de privacidad, borrar una preferencia destilada no basta si la transcripción que la produjo sigue ahí. En España y el resto de la UE se aplica el derecho de supresión del RGPD (artículo 17), y las leyes de protección de datos de América Latina suelen incluir un derecho de supresión similar; alcanza tanto a las transcripciones en bruto como a las entradas destiladas, así que es una cuestión legal, no de ajuste.

Alcance. La memoria con alcance por usuario está clara. El conocimiento de dominio compartido y los flujos de trabajo no: ¿quién aprueba que un flujo de trabajo que enseñó un usuario se convierta en la forma en que el agente trabaja para todos? El equipo de ventas de Anthropic, en su montaje de seis agentes, compartió memoria a propósito y mantuvo las credenciales separadas. Esa separación debería ser una decisión de diseño, no un valor por defecto.

La memoria también hace que un agente sea más difícil de mover. Lo que ha aprendido vive ahora en el almacén de un proveedor, y por eso el estado acumulado es el nuevo coste de cambio. La función de exportación importa; pruébela antes de que la memoria valga algo.