MemEx: Um Bloco de Rascunho Programável para Agentes LLM

Em 1945, Vannevar Bush imaginou uma máquina do tamanho de uma mesa que estenderia a memória de um cientista, armazenando cada documento, anotação e linha de pensamento para recuperação sob demanda. Ele a chamou de MemEx. Bush estava resolvendo um problema humano: mentes sobrecarregadas por informações que não conseguiam manter à mão. Oito décadas depois, os agentes LLM estão encontrando uma barreira notavelmente semelhante.

No paradigma atual de Chamada de Ferramentas Agênticas (Agentic Tool Calling), a janela de contexto é o único substrato persistente sobre o qual o modelo pode operar. É um espaço compartilhado que contém o prompt do sistema, a consulta do usuário, o raciocínio do modelo, as chamadas de ferramentas e as saídas brutas das ferramentas. As saídas das ferramentas são as piores infratoras: uma única consulta SQL pode retornar milhões de linhas, e nos sistemas atuais, essas linhas são transportadas em cada turno subsequente, mesmo que apenas uma célula tenha sido relevante. O agente não tem como fatiar, resumir ou armazenar o resultado antes que ele inunde a janela.

Nós nos deparamos com essa barreira constantemente na Databricks. Nossos agentes de produção, de Genie a Agent Bricks, encontram as mesmas limitações de contexto em algum momento. Genie oferece um exemplo claro: uma única consulta pesquisa todo o espaço de trabalho de um cliente, chamando muitas ferramentas para extrair dados de tabelas, índices de vetores e painéis. Para resolver isso, construímos nosso próprio MemEx e o validamos em vários agentes de produção e internos.

Em tarefas difíceis de recuperação estruturada empresarial, a Figura 1 mostra que o MemEx impulsiona a fronteira de custo vs. precisão para cada modelo. Modelos de fronteira como Opus 4.6 e Sonnet 4.6 ganham de 2 a 5 pontos percentuais com 25 a 30% menos custo de token. Modelos de pesos abertos como Qwen3.5-122B (18% → 36%) e Qwen3.5-397B (20% → 38%) quase dobram sua precisão com 40 a 50% menos custo de token. Como o MemEx pode operar sobre entradas arbitrariamente longas, ele também desbloqueia duas aplicações adicionais: auditoria de trajetórias de agentes, incluindo as do próprio MemEx, que normalmente não caberiam em uma única janela de contexto, e pensamento paralelo em múltiplas trajetórias.

Como o MemEx funciona

">

O MemEx oferece ao LLM um bloco de rascunho programável: um kernel Python tipado que mantém as saídas das ferramentas, as transforma com código e materializa apenas as instruções de impressão como tokens no contexto. Dentro desse ambiente, o "rollout" se torna um programa Python autoextensível. A cada turno, o agente cria um novo bloco, o kernel mantém o estado ativo e o próximo bloco se baseia no que veio antes. As ferramentas são expostas como funções Python tipadas com parâmetros tipados e valores de retorno tipados. As saídas das ferramentas chegam como objetos Python no escopo do MemEx, onde persistem entre os turnos. O agente as compõe com código, define funções auxiliares quando um padrão se repete e gera subagentes como chamadas de função assíncronas sobre o mesmo escopo.

O MemEx pertence à família "código como ação" introduzida por CodeAct (Wang et al., 2024), com variantes de produção em Programmatic Tool Calling da Anthropic e Cloudflare Code Mode. O MemEx se destaca por se integrar a um framework agêntico existente no estilo ReAct (Yao et al., 2022), com escopo persistente, primitivas de subagentes e retornos tipados incorporados. Juntos, eles desbloqueiam capacidades que o paradigma de chamada de ferramentas JSON/XML não possui:

• Lidando com entradas arbitrariamente grandes: Documentos, conjuntos de dados e outros objetos grandes podem ser mantidos no escopo Python como variáveis.
• Retornando objetos tipados: As saídas das ferramentas são objetos Python tipados mantidos na memória, não strings que o modelo precisa materializar ou reanalisar a cada turno.
• Compondo chamadas de ferramentas: A saída de uma chamada flui diretamente para os argumentos da próxima chamada em uma única linha de código. Saídas intermediárias não precisam ser materializadas no contexto do agente.
• Fatiando saídas de ferramentas: As saídas podem ser pré-processadas, filtradas ou resumidas em código antes que o modelo as veja.
• Gerando subagentes assíncronos: Os agentes podem gerar programaticamente subagentes que executam em paralelo com o pai e agregam seus resultados sem a necessidade de um "round-trip" através do modelo principal.

Exemplo de Agente LLM com MemEx

Considere uma tarefa empresarial concreta, como comparar funis de inscrição para ativação para três segmentos de clientes e identificar a maior queda (Figura 1). O fluxo de trabalho tem quatro etapas:

1. recuperar eventos de inscrição e ativação do data warehouse
2. uni-los por usuário
3. calcular as taxas de conversão por segmento em cada etapa
4. classificar as quedas entre os segmentos.

Um agente de Chamada de Ferramentas (Tool Calling) equipado com python_exec funciona uma etapa por vez. Cada consulta SQL e cada computação programática é uma chamada de ferramenta separada, com DataFrames intermediários serializados para texto e repassados em turnos subsequentes. O rastreamento é pesado em tokens, o que o torna propenso a perdas, lento, caro e sujeito a pequenos erros em cascata na tarefa subsequente.

Um agente MemEx escreve o mesmo fluxo de trabalho como um único bloco de código: as consultas retornam DataFrames nativos no escopo, funções auxiliares os compõem, e a resposta final retorna como um objeto tipado e validado via submit(). Mesmo pensamento, espaço de ação diferente.

Para tarefas que se decompõem em subproblemas, o agente pode gerar subagentes de dentro de um bloco. Ao gerar subagentes, o agente pai pode passar acesso compartilhado a qualquer objeto. Os subagentes executam ansiosamente em paralelo com o pai e podem retornar resultados ao agente principal após a conclusão. Por exemplo:

A decomposição recursiva se torna outra expressão no mesmo programa Python.

O MemEx é desenvolvido sobre o aroll, o framework de "rollouts" agênticos da Databricks. O aroll já alimenta sistemas de produção como Genie, o Supervisor Agent do Agent Bricks e esforços de pesquisa como KARL. O MemEx se conecta ao mesmo loop de agente e ferramentas que o aroll já usa para Chamada de Ferramentas (Tool Calling).

Como o MemEx se comporta em tarefas agênticas empresariais?

Realizamos avaliações diretas em 9 modelos de fronteira, onde comparamos chamadas de ferramentas estruturadas paralelas (Tool Calling) vs. blocos de código Python (MemEx). Sem ajuste de prompt, sem adaptação por tarefa. Comparamos em duas formas de trabalho agêntico empresarial: leitura fundamentada sobre um grande corpus de texto (OfficeQA) e recuperação estruturada sobre um grande espaço de trabalho de dados relacionais diversos (Recuperação Estruturada Empresarial).

Em ambas as tarefas, o Agente MemEx é melhor e mais barato que o Agente de Chamada de Ferramentas!

">

O OfficeQA Pro pede ao agente para responder a perguntas de raciocínio fundamentado sobre o corpus dos Boletins do Tesouro dos EUA, aproximadamente 89.000 páginas de 1939 até o presente. Uma pergunta típica exige a localização de evidências em vários documentos, a navegação em tabelas com hierarquias aninhadas e células mescladas, e a execução de cálculos nos dados recuperados. As respostas são classificadas por correspondência exata. Quatro dos cinco pontos na fronteira de Pareto de custo vs. precisão são configurações MemEx. O Gemini 3.1 Pro MemEx é o ponto de fronteira mais barato, a US$ 0,62 por execução (52,9% de precisão), e o Sonnet 4.6 MemEx se aproxima da precisão do GPT-5.5 Tool Calling com aproximadamente 70% do custo. Em nove modelos, o MemEx empata ou vence em todos os modelos. O meio do grupo é o que mais se move, com Qwen 3.6 27B e Gemini 3.1 Pro ganhando cerca de 10 pontos percentuais.

">

A Recuperação Estruturada Empresarial pede ao agente para responder a perguntas em linguagem natural sobre dados relacionais empresariais. O agente recebe ferramentas relacionadas à descoberta de esquemas e à execução de consultas SQL, e deve usá-las para realizar a tarefa de análise de dados solicitada pelo usuário, geralmente com pouca informação sobre onde no espaço de trabalho diversificado encontrar as informações relevantes. As respostas do agente são avaliadas em relação a respostas de verdade fundamental usando validação de dados determinística e LLM-como-juiz. Como visto nas Figuras 1 e 6, todos os modelos mostram um forte ganho com MemEx, excluindo o GPT 5.5, que mostra desempenho de paridade. Em termos de custo, a história é igualmente forte. O Qwen 122B cai de 56 para 28 chamadas de ferramentas por execução, enquanto dobra sua pontuação; o Sonnet de 28 para 17; o Opus de 33 para 21.¹ Isso resulta em uma redução de aproximadamente metade do custo na maioria dos modelos. O padrão ecoa o OfficeQA Pro: quanto mais difícil a tarefa, mais os objetos nativos e o estado persistente se justificam.

Cada comparação foi executada sem ajuste de prompt, sem adaptação por tarefa e sem ajustes específicos do modelo. O loop do agente, os prompts do sistema e as ferramentas são idênticos em ambos os sistemas. A única diferença é o espaço de ação, chamadas de ferramentas estruturadas JSON/XML versus blocos de código Python do MemEx.

MemEx Operando em Traços Agênticos

As trajetórias agênticas são, por si só, objetos volumosos. No paradigma de Chamada de Ferramentas, analisar trajetórias geralmente exige achatá-las em texto, o que é propenso a perdas e pesado em contexto, e analisar várias de uma vez é frequentemente inviável. As trajetórias podem até abranger várias janelas de contexto, com compressão intermediária; como um LLM pode analisar um traço que, por definição, não cabe em seu contexto? Mas uma trajetória é apenas outro objeto Python, então o MemEx pode carregá-la diretamente no escopo e raciocinar sobre ela. Mostramos duas aplicações: primeiro, um agente de auditoria baseado em MemEx que analisa trajetórias do Qwen 3.6-27B no OfficeQA-Pro para explicar por que o MemEx supera o Tool Calling; segundo, escalonamento em tempo de teste no OfficeQA-Pro, com um agente MemEx que vence um agente de Chamada de Ferramentas equivalente.

MemEx audita MemEx: Análise de Traços Agênticos

Para analisar por que a mudança para MemEx resultou em um aumento de desempenho para modelos de código aberto, como o Qwen 3.6-27B, recorremos ao MemEx para explicar. Em particular, instanciamos um agente de auditoria que leva uma pergunta do OfficeQA, sua resposta de verdade fundamental e seis trajetórias de solução (3 de um agente MemEx e 3 de um agente de Chamada de Ferramentas) diretamente para seu escopo Python, e pede a um agente Sonnet 4.6 baseado em MemEx para classificar cada trajetória errada ao longo de uma taxonomia de quatro eixos de modos de falha.

Nossa análise foca em 66 perguntas do OfficeQA Pro onde nem todas as seis tentativas estavam corretas ou incorretas, resultando em 173 trajetórias. Os quatro eixos se dividem em dois grandes grupos:

- Erros de Fundamentação (~83%): Casos em que o modelo recupera um valor preliminar em vez de um valor revisado, interpreta mal terminologia ambígua (por exemplo, variância amostral vs. populacional, ou precisão de arredondamento para "centésimos"), ou extrai a coluna incorreta de uma tabela válida.

- Erros de Estratégia de Busca e Execução: Erro no planejamento da sequência de recuperação ou falha na integração correta dos dados recuperados em cálculos finais.

Para erros de Estratégia de Busca e Execução, o MemEx constata que o agente MemEx teve uma redução de erro de 2x em comparação com o Tool Calling. Isso ocorre porque, para o MemEx, a recuperação pode ser feita diretamente em variáveis Python, então o modelo pode evitar copiar valores da saída de uma ferramenta para a próxima chamada de ferramenta, e múltiplas chamadas de ferramenta podem ser processadas em lote em uma única vez. O Tool Calling não possui tal atalho e deve sempre transcrever valores entre as chamadas, o que às vezes causa erros. Por exemplo, em uma trajetória, um valor de 3.501 de um documento recuperado foi redigitado na próxima chamada como 3531.

Pensamento Paralelo Agêntico com MemEx

Uma abordagem comum para escalar a computação em tempo de teste é o pensamento paralelo, onde múltiplas execuções independentes de uma tarefa são agregadas em uma resposta final. No pensamento paralelo agêntico, como a abordagem usada no KARL, resumos das tentativas independentes são passados para um agente agregador. Esta etapa de sumarização é propenso a perdas, mas inevitável na configuração padrão, já que encaixar múltiplas trajetórias completas na janela de contexto de um modelo é impraticável. Com o MemEx, podemos, em vez disso, carregar essas trajetórias como variáveis de escopo, contornando completamente a representação com perdas.

">

No resultado mostrado na Figura 7, usamos Claude Sonnet 4.6 como um agregador sobre oito trajetórias Qwen-3.6-27B geradas independentemente. Para garantir que o agregador não esteja simplesmente resolvendo o problema por conta própria, removemos suas ferramentas de busca de arquivos, restringindo-o à verificação e seleção. O agente baseado em MemEx, que recebe as trajetórias completas como entrada, supera o agente de Tool Calling equivalente que recebe apenas seus resumos. Em um caso, o agregador de trajetórias detectou um erro de duplicação em um boletim anterior lendo as saídas brutas da ferramenta das trajetórias de entrada; o agregador de Tool Calling não conseguiu verificar a alegação de dados duplicados devido à sua entrada ser limitada aos resumos, e recorreu à votação majoritária na fonte corrompida.

Arquitetura MemEx

Agentes de Tool Calling emitem uma ou mais chamadas de ferramentas estruturadas por turno (JSON ou XML), cada uma em conformidade com um esquema de ferramenta predefinido, no loop de ação-observação introduzido por ReAct (Yao et al., 2022). CodeAct (Wang et al., 2024) substituiu esse formato por um kernel Python persistente: o agente emite código Python arbitrário, e variáveis e definições de função são mantidas entre os turnos. Variantes de produção do mesmo paradigma incluem Programmatic Tool Calling (PTC) da Anthropic e Cloudflare Code Mode; o PTC também mantém o estado entre as requisições reutilizando o mesmo contêiner, enquanto o Code Mode não. O MemEx estende este paradigma com quatro adições:

• Integração de ferramentas "drop-in" com esquemas de parâmetros preservados.
• Escopo Python ativo no início da implantação.
• submit() tipado para retornos estruturados.
• spawn_agent() não bloqueante para subagentes paralelos, generalizando Modelos de Linguagem Recursivos (Zhang et al., 2025).

A implementação se baseia em três escolhas de design:

Código como ação, em um REPL persistente

A ação do agente é um bloco de código Python arbitrário, executado em um namespace que persiste entre os turnos. Ferramentas, objetos de escopo e resultados anteriores residem nesse namespace. O agente lê observações (stdout, valores de retorno, erros) e, em seguida, escreve mais código. O mesmo loop de observação-ação que executa o Tool Calling executa o MemEx; apenas o espaço de ação muda.

"Drop-in" para Tool Calling

As ferramentas de Tool Calling existentes são auto-injetadas como funções Python, incluindo esquemas de parâmetros e metadados de tipo de retorno. Mudar um agente existente de Tool Calling para MemEx é uma única mudança de configuração.

Execução agnóstica de backend

O mesmo código de agente é executado em três backends, selecionados no momento da configuração:

• Em processo para iteração rápida durante a pesquisa.
• Subprocesso para isolamento durante a avaliação.
• Pool para geração de lotes de alta vazão (dados de treinamento, implantações em larga escala).

Para implantações de produção, o kernel pode ser trocado por um sandbox hospedado como os Managed Agents da Anthropic. O mesmo código de agente, com isolamento do sistema de arquivos, controles de saída de rede e limites de recursos gerenciados pelo host.

O que vem a seguir?

MemEx está chegando às mãos do seu agente. Estamos implementando-o em todos os agentes proprietários da Databricks e no Agent Bricks: se você desenvolve com agentes Databricks hoje, em breve poderá usar o MemEx.

Estamos pós-treinando nossos modelos para o espaço de ação do MemEx. O próprio MemEx é o substrato: ele gera dados sintéticos, executa verificadores agênticos e alimenta o loop de treinamento.

Autores: Ashutosh Baheti, Shubham Toshniwal, Arnav Singhvi, Krista Opsahl-Ong, Sean Kulinski, Sam Havens, Jonathan Li, Marco Cusumano-Towner, Jonathan Chang, Wen Sun, Alexander Trott, Jonathan Frankle, Xing Chen, Matei Zaharia

---

¹ No MemEx, as chamadas de ferramentas são blocos de código Python que podem ter análise de dados ou outras ferramentas chamadas como funções assíncronas.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original