Databricks quer que agentes lembrem o que aprenderam ontem. O problema difícil é o que devem esquecer

Dê a um agente tudo o que ele já viu e ele não fica muito melhor. Nos benchmarks abertos da nova pesquisa de memória da Databricks, um agente alimentado com todo o histórico de conversa marcou 87,8%. O mesmo agente com uma memória curada marcou 88,1%, lendo cerca de 8.400 tokens de entrada por pergunta em vez de 103.000. Nos benchmarks com os históricos mais longos, o contexto completo saiu pior: o material extra o confundiu.

Esse resultado é a coisa mais útil no lançamento de 20 de outubro do Agent Memory da Databricks, agora em beta para agentes construídos em sua plataforma. Lembrar é fácil. O trabalho de design está em decidir o que manter, o que reescrever e o que descartar.

O que a Databricks lançou

O Agent Memory armazena três coisas no Lakebase, o Postgres serverless da Databricks, provisionado no workspace do cliente e operado pela Databricks:

• Sessões gerenciadas: o histórico ordenado de mensagens, tool calls e resultados.
• Memória gerenciada: fatos de longo prazo sobre o perfil e as preferências de um usuário, conhecimento de domínio e workflows que funcionaram.
• Pipelines de memória: jobs em segundo plano, sob demanda ou agendados, que destilam sessões em memória. Eles extraem fatos duráveis, removem duplicatas e substituem fatos que conversas mais novas contradizem.

As memórias pessoais têm escopo por usuário. Desenvolvedores podem ler, exportar e excluir o que um agente guarda sobre cada usuário, e podem instruir os pipelines sobre o que reter.

A pesquisa por trás dele, o MemCurrent, separa a memória episódica (traços brutos de sessão, somente anexados) da memória derivada (aprendizados destilados guardados como arquivos em uma base de conhecimento hierárquica, com um índice carregado no início de cada sessão). Um pipeline de consolidação offline, que a Databricks chama de “dreaming”, funde duplicatas e resolve conflitos.

Os números, com seu escopo

Em um benchmark interno construído a partir de conversas reais com o agente de dados Genie da Databricks (114 casos de teste, 29 usuários, 2.233 sessões históricas), o MemCurrent alcançou uma taxa de aprovação de 68,4%. Sem memória, o agente passou em 22,3%; com o Mem0, um backend de memória popular, 43,9%; com as memórias corretas injetadas à mão, o teto era 78,6%. Contra a ausência de memória, o MemCurrent triplicou a taxa de aprovação e rodou 1,35 vez mais rápido com custo 1,44 vez menor.

Duas ressalvas. O benchmark vem de um workspace e de um agente, e é da própria Databricks. E a ablação mais interessante é fácil de perder: só a memória derivada marcou 66,1%, só a episódica 35,8%. Quase todo o valor veio da camada curada, não de guardar o histórico bruto.

Três tipos de estado de agente, três donos diferentes

Histórico episódico

• Traços brutos de sessão
• Tool calls e resultados
• Somente anexado

Evidência do que aconteceu

Memória derivada

• Perfil e preferências
• Conhecimento de domínio
• Workflows que funcionaram

Reescrita por um pipeline; pode estar errada

Sistema de registro

• Cadastro mestre de clientes
• Procedimentos aprovados
• Transações

Nunca substituído pela memória

O problema do esquecimento

A memória persistente transforma um agente em um armazenamento de dados, como argumentamos quando descrevemos a memória de agente como armazenamento de dados enterprise. O Agent Memory torna isso concreto e levanta quatro questões que o anúncio não responde por completo.

Obsolescência. Um pipeline de consolidação que substitui fatos contraditos lida com o caso em que um usuário diz algo novo. Não lida com o caso em que o mundo muda e ninguém avisa o agente: uma reorganização, uma nova regra de preços, um fornecedor descartado. A memória derivada precisa de uma regra de expiração ou de revalidação, não só de uma regra de conflito.

Erros de consolidação. Um pipeline que reescreve memória também pode errar, fundindo dois fatos distintos ou mantendo uma exceção como regra. A Databricks descreve o que o pipeline faz, não como seus erros são detectados. Os times devem amostrar entradas consolidadas como amostram qualquer saída automatizada.

Retenção da camada bruta. A memória episódica é somente anexada, e nenhum dos posts descreve um cronograma de retenção para ela. Sob uma solicitação de privacidade, excluir uma preferência destilada não basta se a transcrição que a produziu ainda está lá. No Brasil, a LGPD (art. 18) dá aos titulares o direito de pedir a eliminação de dados pessoais tratados com seu consentimento e de saber quais dados estão sendo tratados; para a memória de agente, isso alcança tanto as transcrições brutas quanto as entradas destiladas, então é uma questão legal, não de tuning.

Escopo. A memória com escopo por usuário é clara. Conhecimento de domínio e workflows compartilhados não são: quem aprova que um workflow que um usuário ensinou ao agente vire a forma como ele funciona para todos? O time de vendas da Anthropic, em sua configuração de seis agentes, compartilhou memória de propósito e manteve credenciais separadas. Essa separação deveria ser uma decisão de design, não um padrão.

A memória também torna um agente mais difícil de mover. O que ele aprendeu agora mora no armazenamento de um fornecedor, e é por isso que o estado acumulado é o novo custo de troca. A função de exportação importa; teste antes que a memória valha alguma coisa.