Zero Vazamento entre Tenants com 0,89 de Recall: Isolamento no Cluster

A Elastic Search Labs publicou em junho de 2026 uma implementação que move a conversa sobre memória de agentes da política para a medição. Uma camada de memória persistente e multi-tenant alcançou 0,89 de recall@10 em uma avaliação de 168 perguntas, com zero vazamentos entre tenants. O número de isolamento é o que importa. Não porque zero soa bem em material de marketing, mas por causa de onde o zero veio: o banco de dados o garantiu, não a aplicação e nem o prompt.

Essa única decisão de design é o argumento inteiro. A maioria dos times que constrói memória de agentes coloca os limites entre tenants na camada de recuperação e depois confia que o agente vai respeitá-los. A Elastic colocou o limite no Document-Level Security, expresso por descritores de papel da API key. O agente não consegue consultar outros tenants porque o motor de busca se recusa a retornar documentos fora do escopo da chave. O limite se mantém com um prompt comportado ou hostil.

Os Números de Recall, Lidos Corretamente

A manchete é 0,89 de recall@10 na média. A quebra diz mais do que a média.

A Elastic reporta memória semântica em 0,81, episódica em 0,98 e procedural em 1,0. A dispersão é o sinal. Memória procedural (como fazer algo, os passos e ferramentas) e memória episódica (o que aconteceu, quando, em que ordem) são altamente estruturadas e recuperam de forma quase perfeita. Memória semântica (fatos gerais e preferências aprendidas) é mais nebulosa e puxa a média para baixo. Um time que trata “memória de agente” como um único repositório indiferenciado nunca enxergaria isso. A arquitetura separa a memória em índices distintos justamente porque as características de recuperação diferem, e a avaliação confirma que a separação estava certa.

Três índices de memória mais um catálogo. Refresh de escrita abaixo de 100 milissegundos, então um fato que o agente acabou de aprender fica consultável quase imediatamente. Esses parâmetros decidem se o agente lembra o que você disse dez segundos atrás ou se já esqueceu.

Uma frase do texto merece ser citada exatamente, porque reformula uma suposição confortável: “Uma janela de contexto de 1M de tokens é um rascunho. Não é um sistema de memória.” Empilhar histórico em um contexto longo é recall na força bruta. Não sobrevive à sessão, não isola por tenant e não permite auditar o que o agente sabia no momento da decisão.

Isolamento como Propriedade do Banco de Dados

O Document-Level Security é o mecanismo que vale copiar. As memórias de cada tenant carregam metadados de acesso. Cada agente opera sob uma API key cujo descritor de papel o restringe a exatamente um tenant. A recuperação passa por essa chave. O filtro não é uma cláusula WHERE tenant_id = ? que a aplicação acrescenta e pode esquecer. É garantido pelo motor em toda consulta, inclusive nas que um agente comprometido ou confuso possa tentar rodar.

É aqui que a indústria erra de novo. Quando o isolamento vive no código da aplicação, cada novo caminho de recuperação é uma nova chance de vazar. Um dev adiciona uma funcionalidade, escreve uma query, esquece o filtro de tenant, e o limite some. Quando o isolamento vive no cluster como propriedade da credencial, não existe caminho que o contorne. O agente poderia estar completamente sob injeção de prompt e ainda assim ver apenas os dados do próprio tenant. O vazamento que ele tenta causar é uma consulta que o motor se recusa a servir, e nenhuma instrução de prompt muda isso.

O design da avaliação da Elastic reflete isso. As 168 perguntas incluem sondagens entre tenants. Zero vazamentos nesse conjunto comprova a arquitetura em si. Uma garantia estrutural, presa à credencial, é o que torna o número crível.

Contradições Ganham Trilha de Auditoria, Não Exclusão

A segunda decisão de design é mais silenciosa e igualmente importante. Quando um novo fato contradiz um armazenado, o sistema não sobrescreve nem deleta o fato antigo. Ele o substitui e mantém a trilha.

Pense no custo de deletar. Um agente aprende o endereço de entrega de um cliente, depois aprende um novo. Delete o antigo e você ganha um repositório mais limpo e um ponto cego. Você não consegue mais responder “qual endereço o agente tinha quando enviou o pedido errado em março?”. A substituição mantém os dois fatos, marca qual é o atual e registra quando a mudança ocorreu e por quê. Integridade da memória e auditabilidade vêm do mesmo mecanismo.

Isso pesa para quem opera sob o olhar de um regulador. A conversa sobre direito ao esquecimento na memória de agentes costuma tratar a exclusão como objetivo. A substituição reformula isso: você consegue provar o que o agente sabia em qualquer ponto no tempo, que é exatamente o que uma auditoria ou a reconstrução de um incidente exige. A exclusão dos dados de um titular específico vira uma operação direcionada sobre registros identificáveis, não uma limpeza cega de um bloco comprimido.

Mais dois parâmetros do texto mostram o mesmo instinto de governança. A memória decai com offset de 180 dias e meia-vida de cinco anos, então fatos antigos perdem peso sem desaparecer. Um coeficiente de prioridade de fonte de 0,85 pondera de onde a memória veio, então um fato de fonte confiável supera um fato de fonte ruidosa. Ambos são botões que pertencem a um operador, definidos na infraestrutura, não improvisados pelo agente em tempo de execução.

Por Que Isso Reformula a Pergunta de Governança

Trabalhos anteriores sobre memória de agentes, incluindo os nossos, enquadraram o problema: memória persistente cria riscos para os quais os frameworks de governança de dados não foram construídos. Esse enquadramento estava correto e incompleto. Deixava a impressão de que governança é uma camada de política que você parafusa por cima.

Esta implementação mostra o oposto. As propriedades de governança mais fortes aqui são propriedades de infraestrutura. Isolamento entre tenants é o escopo de uma credencial. Auditabilidade é um registro de substituição. Retenção é uma curva de decaimento. Confiança na fonte é um coeficiente. Nenhuma delas é uma instrução de prompt, e nenhuma é lógica de aplicação que uma funcionalidade futura possa quebrar silenciosamente. Elas vivem abaixo da aplicação, onde o agente não alcança para enfraquecê-las.

Essa é a lição que vale internalizar. Uma propriedade de governança que um prompt esperto ou uma mudança de código desleixada consegue sobrepor é só uma esperança com nome melhor. As propriedades que se mantêm são as que o sistema garante estruturalmente, em toda operação, independente do que o agente pretende.

Trate os números absolutos com a cautela que qualquer benchmark de fornecedor próprio merece. A Elastic construiu o sistema e rodou a própria avaliação. O padrão sobrevive a essa ressalva. Quer o seu recall no mundo real fique em 0,89 ou em 0,79, é a arquitetura de onde você coloca o isolamento, como trata contradições e o que torna ajustável por operadores que determina se a memória do seu agente é governável.

Faça Isto Agora

Audite onde vive o isolamento da memória dos seus agentes. Se um dev consegue escrever uma query de recuperação que esquece o filtro de tenant, o seu limite está na camada errada. Mova-o para a credencial: restrinja o acesso de cada agente ao banco a exatamente um tenant, garantido pelo motor, e adicione uma sondagem entre tenants ao seu conjunto de avaliação para que uma regressão apareça como teste falho em vez de vazamento. Depois substitua a exclusão pela substituição em qualquer fato que um agente possa revisar, para reconstruir o que o agente sabia em qualquer momento que um regulador ou um cliente pergunte.

Fontes

Elastic Search Labs. “0.89 Recall and Zero Tenant Leaks.” Junho de 2026.

A Victorino ajuda organizações a construir arquiteturas de memória de agentes em que isolamento, auditoria e retenção são propriedades de infraestrutura, não esperanças no nível do prompt: contato@victorino.com.br | www.victorino.com.br