MemEx: Un'area di lavoro temporanea programmabile per agenti LLM

Nel 1945, Vannevar Bush immaginò una macchina delle dimensioni di una scrivania che avrebbe esteso la memoria di uno scienziato memorizzando ogni documento, annotazione e percorso di pensiero per il richiamo su richiesta. La chiamò MemEx. Bush stava risolvendo un problema umano: menti sopraffatte da informazioni che non potevano tenere a portata di mano. Otto decenni dopo, gli agenti LLM stanno incontrando un ostacolo notevolmente simile.

Nell'attuale paradigma di Agentic Tool Calling, la finestra di contesto è l'unico substrato persistente su cui il modello può operare. È uno spazio condiviso che contiene il prompt di sistema, la query dell'utente, il ragionamento del modello, le chiamate agli strumenti e gli output grezzi degli strumenti. Gli output degli strumenti sono i peggiori colpevoli: una singola query SQL potrebbe restituire milioni di righe, e negli attuali sistemi quelle righe vengono trasportate in ogni turno successivo anche se solo una cella fosse rilevante. L'agente non ha modo di sezionare, riassumere o archiviare il risultato prima che inondi la finestra.

Incontriamo costantemente questo ostacolo in Databricks. I nostri agenti di produzione, da Genie ad Agent Bricks, a un certo punto si imbattono nelle stesse limitazioni di contesto. Genie fornisce un esempio chiaro: una singola query cerca nell'intero workspace di un cliente, richiamando molti strumenti per estrarre dati da tabelle, indici vettoriali e dashboard. Per risolvere questo problema, abbiamo costruito un nostro MemEx e lo abbiamo convalidato all'interno di più agenti di produzione e interni.

Su compiti difficili di recupero strutturato aziendale, la Figura 1 mostra che MemEx spinge la frontiera costo-vs-accuratezza per ogni modello. Modelli all'avanguardia come Opus 4.6 e Sonnet 4.6 guadagnano 2-5 punti percentuali con un costo di token inferiore del 25-30%. Modelli a pesi aperti come Qwen3.5-122B (18% → 36%) e Qwen3.5-397B (20% → 38%) quasi raddoppiano la loro accuratezza con un costo di token inferiore del 40-50%. Poiché MemEx può operare su input arbitrariamente lunghi, sblocca anche due ulteriori applicazioni: l'audit delle traiettorie degli agenti, inclusa quella di MemEx, che normalmente non rientrerebbero in una singola finestra di contesto e il pensiero parallelo su più traiettorie.

Come funziona MemEx

">

MemEx offre all'LLM un blocco note programmabile: un kernel Python tipizzato che contiene gli output degli strumenti, li trasforma con il codice e materializza solo le istruzioni di stampa come token nel contesto. All'interno di questo ambiente, il rollout diventa un programma Python auto-estendente. Durante ogni turno, l'agente crea un nuovo blocco, il kernel mantiene lo stato attivo e il blocco successivo si basa su ciò che è venuto prima. Gli strumenti sono esposti come funzioni Python tipizzate con parametri tipizzati e valori di ritorno tipizzati. Gli output degli strumenti arrivano come oggetti Python nello scope di MemEx, dove persistono tra i turni. L'agente li compone con il codice, definisce funzioni di supporto quando un pattern si ripete e genera sotto-agenti come chiamate di funzione asincrone sullo stesso scope.

MemEx fa parte della famiglia "code-as-action" introdotta da CodeAct (Wang et al., 2024), con varianti di produzione in Programmatic Tool Calling di Anthropic e Cloudflare Code Mode. MemEx si distingue per l'integrazione in un framework agentico esistente in stile ReAct (Yao et al., 2022), con scope persistente, primitive per sotto-agenti e ritorni tipizzati integrati. Insieme, questi sbloccano capacità che il paradigma di chiamata degli strumenti JSON/XML non possiede:

• Gestione di input arbitrariamente grandi: documenti, dataset e altri oggetti di grandi dimensioni possono essere mantenuti nello scope Python come variabili.
• Restituzione di oggetti tipizzati: gli output degli strumenti sono oggetti Python tipizzati mantenuti in memoria, non stringhe che il modello deve materializzare o ri-analizzare a ogni turno.
• Composizione di chiamate agli strumenti: l'output di una chiamata fluisce direttamente negli argomenti della chiamata successiva all'interno di una singola riga di codice. Gli output intermedi non devono essere materializzati nel contesto dell'agente.
• Sezionamento degli output degli strumenti: gli output possono essere pre-elaborati, filtrati o riassunti nel codice prima che il modello li veda.
• Generazione di sotto-agenti asincroni: gli agenti possono generare programmaticamente sotto-agenti che vengono eseguiti parallelamente al genitore e aggregare i loro risultati senza passare attraverso il modello principale.

Esempio di agente LLM con MemEx

Prendiamo un compito aziendale concreto come il confronto dei funnel di iscrizione-attivazione per tre segmenti di clienti e l'identificazione del calo maggiore (Figura 1). Il flusso di lavoro ha quattro passaggi:

1. recuperare gli eventi di iscrizione e attivazione dal data warehouse
2. unirli per utente
3. calcolare i tassi di conversione per segmento in ogni fase
4. classificare i cali tra i segmenti.

Un agente Tool Calling equipaggiato con python_exec lavora un passo alla volta. Ogni query SQL e ogni calcolo programmatico è una chiamata a strumento separata, con DataFrames intermedi serializzati in testo e re-incollati nei turni successivi. La traccia è pesante in termini di token, il che la rende dispendiosa, lenta, costosa e soggetta a piccoli errori a cascata nel compito a valle.

Un agente MemEx scrive lo stesso flusso di lavoro come un singolo blocco di codice: le query restituiscono DataFrames nativi nello scope, le funzioni di supporto li compongono e la risposta finale torna come un oggetto tipizzato e validato tramite submit(). Stesso pensiero, spazio d'azione diverso.

Per i compiti che si scompongono in sotto-problemi, l'agente può generare sotto-agenti dall'interno di un blocco. Quando genera sotto-agenti, l'agente genitore può passare l'accesso condiviso a qualsiasi oggetto. I sotto-agenti vengono eseguiti in parallelo con il genitore e possono restituire i risultati all'agente principale al completamento. Ad esempio:

La decomposizione ricorsiva diventa un'altra espressione nello stesso programma Python.

MemEx è sviluppato su aroll, il framework di rollout agentici di Databricks. Aroll alimenta già sistemi di produzione come Genie, Agent Bricks' Supervisor Agent e sforzi di ricerca come KARL. MemEx si collega allo stesso ciclo di agente e agli stessi strumenti che aroll già utilizza per Tool Calling.

Come si comporta MemEx nei compiti agentici aziendali?

Abbiamo eseguito valutazioni dirette su 9 modelli all'avanguardia confrontando chiamate a strumenti strutturate parallele (Tool Calling) vs. blocchi di codice Python (MemEx). Nessuna ottimizzazione del prompt, nessuna adattamento per compito. Confrontiamo due tipi di lavoro agentico aziendale: lettura basata su un ampio corpus di testo (OfficeQA) e recupero strutturato su un ampio workspace di dati relazionali diversi (Enterprise Structured Retrieval).

In entrambi i compiti, MemEx Agent è migliore e più economico di Tool Calling Agent!

">

OfficeQA Pro chiede all'agente di rispondere a domande di ragionamento fondato sul corpus dei Bollettini del Tesoro degli Stati Uniti, circa 89.000 pagine dal 1939 ad oggi. Una domanda tipica richiede di localizzare prove in più documenti, navigare tabelle con gerarchie annidate e celle unite, ed eseguire calcoli sui dati recuperati. Le risposte sono valutate per corrispondenza esatta. Quattro dei cinque punti sulla frontiera di Pareto costo-vs-accuratezza sono configurazioni MemEx. Gemini 3.1 Pro MemEx è il punto di frontiera più economico a $0.62 per rollout (52.9% di accuratezza), e Sonnet 4.6 MemEx si avvicina all'accuratezza di GPT-5.5 Tool Calling a circa il 70% del costo. Su nove modelli, MemEx pareggia o vince su ogni modello. La parte centrale del gruppo si muove di più, con Qwen 3.6 27B e Gemini 3.1 Pro che guadagnano circa 10 punti percentuali.

">

Il Recupero Strutturato Aziendale chiede all'agente di rispondere a domande in linguaggio naturale su dati relazionali aziendali. All'agente vengono forniti strumenti relativi alla scoperta dello schema e all'esecuzione di query SQL, e deve usarli per eseguire il compito di analisi dei dati richiesto dall'utente, solitamente con poche informazioni su dove nell'ampio spazio di lavoro trovare le informazioni pertinenti. Le risposte dell'agente sono valutate rispetto alle risposte di verità usando sia la validazione deterministica dei dati che LLM-as-a-judge. Come mostrato nelle Figure 1 e 6, ogni modello mostra un forte guadagno con MemEx, escluso GPT 5.5 che mostra prestazioni alla pari. In termini di costi, la situazione è altrettanto positiva. Qwen 122B scende da 56 a 28 chiamate di tool per rollout raddoppiando il suo punteggio; Sonnet da 28 a 17; Opus da 33 a 21.¹ Ciò si traduce in un dimezzamento approssimativo dei costi nella maggior parte dei modelli. Il modello riecheggia OfficeQA Pro: più difficile è il compito, più gli oggetti nativi e lo stato persistente si rivelano utili.

Ogni confronto è stato eseguito senza ottimizzazione dei prompt, senza adattamento per compito e senza modifiche specifiche del modello. Il ciclo dell'agente, i prompt di sistema e gli strumenti sono identici in entrambi i contesti. L'unica differenza è lo spazio di azione, chiamate di tool strutturate JSON/XML versus i blocchi di codice Python di MemEx.

MemEx in Funzione su Tracce Agenti

Le traiettorie agenti sono di per sé oggetti voluminosi. Nel paradigma Tool Calling, l'analisi delle traiettorie richiede generalmente di appiattirle in testo, il che comporta perdita di informazioni e un carico di contesto elevato, e analizzarne diverse contemporaneamente è spesso impraticabile. Le traiettorie possono anche estendersi su più finestre di contesto, con compressione intermedia; come può un LLM analizzare una traccia che, per definizione, non rientra nel suo contesto? Ma una traiettoria è solo un altro oggetto Python, quindi MemEx può caricarla direttamente nello scope e ragionare su di essa. Mostriamo due applicazioni: primo, un agente di audit basato su MemEx che analizza le traiettorie di Qwen 3.6-27B su OfficeQA-Pro per spiegare perché MemEx supera Tool Calling; secondo, lo scaling in fase di test su OfficeQA-Pro, con un agente MemEx che batte un agente Tool Calling equivalente.

MemEx verifica MemEx: Analisi delle Tracce Agenti

Per analizzare perché il passaggio a MemEx ha portato a un aumento delle prestazioni per i modelli open-source, come Qwen 3.6-27B, ci rivolgiamo a MemEx per una spiegazione. In particolare, istanziamo un agente di audit che prende una domanda OfficeQA, la sua risposta di verità, e sei traiettorie di risoluzione (3 da un agente MemEx e 3 da un agente Tool Calling) direttamente nel suo scope Python, e chiede a un agente Sonnet 4.6 basato su MemEx di classificare ogni traiettoria errata lungo una tassonomia a quattro assi di modalità di fallimento.

La nostra analisi si concentra su 66 domande di OfficeQA Pro in cui non tutti i sei tentativi erano corretti o errati, producendo 173 traiettorie. I quattro assi si dividono in due grandi gruppi:

- Errori di fondamento (~83%): Casi in cui il modello recupera un valore preliminare invece di una cifra rivista, interpreta erroneamente terminologia ambigua (ad esempio, varianza campionaria vs. di popolazione, o precisione di arrotondamento per "centesimi"), o estrae la colonna errata da una tabella valida.

- Errori di Strategia di Ricerca ed Esecuzione: Errore nella pianificazione della sequenza di recupero o fallimento nell'integrare correttamente i dati recuperati nei calcoli finali.

Per gli errori di Strategia di Ricerca ed Esecuzione, MemEx rileva che l'agente MemEx ha avuto una riduzione degli errori di 2 volte rispetto a Tool Calling. Questo perché, per MemEx, il recupero può avvenire direttamente nelle variabili Python, quindi il modello può evitare di copiare valori dall'output di un tool alla chiamata del tool successivo, e più chiamate di tool possono essere raggruppate in un singolo turno. Tool Calling non ha una scorciatoia simile e deve sempre trascrivere i valori tra le chiamate, il che a volte porta a errori. Ad esempio, in una traiettoria, un valore di 3.501 da un documento recuperato è stato ridigitato nella chiamata successiva come 3531.

Pensiero Parallelo Agente con MemEx

Un approccio comune per scalare il calcolo in fase di test è il pensiero parallelo, dove più rollout indipendenti di un compito sono aggregati in una risposta finale. Nel pensiero parallelo agente, come l'approccio utilizzato in KARL, i riassunti dei tentativi indipendenti vengono passati a un agente aggregatore. Questo passaggio di riassunto comporta una perdita di informazioni ma è inevitabile nella configurazione standard, poiché inserire più traiettorie complete nella finestra di contesto di un modello è impraticabile. Con MemEx, possiamo invece caricare queste traiettorie come variabili di scope, aggirando completamente la rappresentazione con perdita.

">

Nel risultato mostrato nella Figura 7, utilizziamo Claude Sonnet 4.6 come aggregatore su otto traiettorie Qwen-3.6-27B generate indipendentemente. Per garantire che l'aggregatore non si limiti a risolvere il problema da solo, abbiamo rimosso i suoi strumenti di ricerca file, limitandolo alla verifica e alla selezione. L'agente basato su MemEx, che riceve le traiettorie complete come input, supera l'equivalente agente Tool Calling che riceve solo i loro riassunti. In un caso, l'aggregatore di traiettorie ha rilevato un errore di duplicazione in un bollettino precedente leggendo gli output grezzi degli strumenti dalle traiettorie di input; l'aggregatore Tool Calling non è riuscito a verificare l'affermazione sui dati duplicati a causa del suo input limitato ai riassunti, e ha ripiegato sul voto di maggioranza sulla fonte corrotta.

Architettura MemEx

Gli agenti Tool Calling emettono una o più chiamate a strumenti strutturate per turno (JSON o XML), ciascuna conforme a uno schema di strumento predefinito, nel ciclo azione-osservazione introdotto da ReAct (Yao et al., 2022). CodeAct (Wang et al., 2024) ha sostituito quel formato con un kernel Python persistente: l'agente emette codice Python arbitrario, e le definizioni di variabili e funzioni si mantengono tra i turni. Varianti di produzione dello stesso paradigma includono Programmatic Tool Calling (PTC) di Anthropic e Cloudflare Code Mode; PTC mantiene anche lo stato tra le richieste riutilizzando lo stesso container, mentre Code Mode no. MemEx estende questo paradigma con quattro aggiunte:

• Integrazione drop-in degli strumenti con schemi di parametri preservati.
• Scope Python live all'avvio del rollout.
• Typed submit() per ritorni strutturati.
• Non-blocking spawn_agent() per sub-agenti paralleli, generalizzando Recursive Language Models (Zhang et al., 2025).

L'implementazione si basa su tre scelte di design:

Codice come azione, in un REPL persistente

L'azione dell'agente è un blocco di codice Python arbitrario, eseguito in un namespace che persiste tra i turni. Strumenti, oggetti scope e risultati precedenti vivono tutti in quel namespace. L'agente legge le osservazioni (stdout, valori di ritorno, errori), quindi scrive altro codice. Lo stesso ciclo osserva-agisci che esegue Tool Calling esegue MemEx; solo lo spazio delle azioni cambia.

Drop-in per Tool Calling

Gli strumenti Tool Calling esistenti vengono auto-iniettati come funzioni Python, inclusi gli schemi dei parametri e i metadati del tipo di ritorno. Passare un agente esistente da Tool Calling a MemEx è una singola modifica di configurazione.

Esecuzione indipendente dal backend

Lo stesso codice agente viene eseguito in tre backend, scelti al momento della configurazione:

• In-process per iterazioni veloci durante la ricerca.
• Subprocess per l'isolamento durante la valutazione.
• Pool per la generazione batch ad alta produttività (dati di training, rollout su larga scala).

Per le implementazioni di produzione, il kernel può essere sostituito con una sandbox ospitata come Managed Agents di Anthropic. Lo stesso codice agente, con isolamento del filesystem, controlli di uscita di rete e limiti di risorse gestiti dall'host.

Cosa c'è dopo?

MemEx sta arrivando nelle mani del tuo agente. Lo stiamo implementando negli agenti first-party di Databricks e in Agent Bricks: se oggi costruisci su agenti Databricks, presto potrai usare MemEx.

Stiamo post-addestrando i nostri modelli per lo spazio delle azioni MemEx. MemEx stesso è il substrato: genera dati sintetici, esegue verificatori agentici e alimenta il ciclo di training.

Autori: 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

---

¹ In MemEx, le chiamate agli strumenti sono blocchi di codice python che possono avere strumenti di analisi dati o altri strumenti chiamati come funzioni asincrone.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale