Elasticsearch como camada de memória persistente para agentes: arquitetura multi-índice com isolamento de tenants

Elasticsearch não é só um motor de busca: virou uma infraestrutura de memória agentic com semântica de engenharia de software. A arquitetura multi-índice (episódico, semântico, procedural) não é só uma analogia cognitiva, é um contrato de API entre o agente e a camada de persistência. Cada índice tem regras explícitas de escrita, envelhecimento e supersessão, com campos como success_count, superseded_by e supporting_episode_ids que transformam documentos em objetos com comportamento, não apenas dados. Isso muda o jogo para DX: não há mais necessidade de orquestrar vetores, grafos e audit logs em três serviços distintos. Tudo roda sob um único DLS (Document Level Security), com recall híbrido RRF + cross-encoder já pré-configurado no pipeline nativo do Elasticsearch.

O verdadeiro salto técnico está na operacionalização da memória como código. O Agent Builder, agora em GA desde janeiro de 2026, não é um wrapper, é uma extensão da engine de busca. Ele converte chamadas de ferramentas em queries Elasticsearch com escopo de tenant embutido, aplica decay automático por timestamp nos índices episódicos e injeta pre-recall com a mensagem original do usuário para evitar perda de termos literais (versões, códigos de erro). E isso tudo sem depender de LLMs intermediários para filtragem ou deduplicação, o sistema usa BM25 + Jina v5 + Jina v2 num fluxo otimizado para latência sub-15ms, mesmo com quantização BBQ ativa.

A CEVIU já havia coberto alternativas como ApertureDB (abr/2026), RushDB 2.0 (mai/2026) e Redis Iris (mai/2026), mas todas exigiam composição de camadas: gráfico + vetor + auth + auditoria. O que mudou agora é a consolidação técnica: Elasticsearch entrega memória persistente com isolamento de tenant, supersessão com rastreamento de cadeias e recall híbrido nativo, tudo em uma única stack. Antes, a memória era um padrão conceitual (files, memory blocks, skills); agora é um contrato executável. O Agent Builder não só implementa os três tipos de memória descritos em nosso artigo de 28/abr, mas os torna observáveis, testáveis e integráveis com Elastic Workflows, algo que nenhum dos sistemas anteriores oferecia com essa granularidade de controle sobre o ciclo de vida do dado.

Para devs, isso significa menos infraestrutura para manter e mais tempo para construir lógica de negócio. Não é só sobre performance: é sobre garantir que um agente de suporte saiba que o reset do hub falhou duas vezes, e que o cabo foi roído pelo cachorro, sem que esses fatos sejam perdidos no contexto ou apagados por overwriting acidental. A arquitetura resolve problemas reais de produção: esquecimento progressivo (via decay), contradições (via supersessão com classificação natural/harsh), e vazamento entre tenants (via DLS nativo, não via middleware). E faz isso com custo previsível: DiskBBQ reduz uso de RAM em 95%, permitindo escalar memória semântica para petabytes sem triplicar o orçamento de infraestrutura.