MemEx : Un bloc-notes programmable pour les agents LLM

En 1945, Vannevar Bush a imaginé une machine de la taille d'un bureau qui étendrait la mémoire d'un scientifique en stockant chaque document, annotation et fil de pensée pour un rappel à la demande. Il l'a appelée le MemEx. Bush résolvait un problème humain : des esprits submergés par des informations qu'ils ne pouvaient pas garder à portée de main. Huit décennies plus tard, les agents LLM se heurtent à un obstacle remarquablement similaire.

Dans le paradigme actuel d'appel d'outils agentique (Agentic Tool Calling), la fenêtre contextuelle est le seul substrat persistant sur lequel le modèle peut opérer. C'est un espace partagé qui contient l'invite système, la requête de l'utilisateur, le raisonnement du modèle, les appels d'outils et les sorties brutes des outils. Les sorties d'outils sont les pires coupables : une seule requête SQL peut renvoyer des millions de lignes, et dans les systèmes actuels, ces lignes sont transmises à chaque tour suivant, même si une seule cellule était pertinente. L'agent n'a aucun moyen de découper, de résumer ou de stocker le résultat avant qu'il n'inonde la fenêtre.

Nous nous heurtons constamment à cet obstacle chez Databricks. Nos agents de production, de Genie à Agent Bricks, rencontrent les mêmes limitations de contexte à un moment donné. Genie en fournit un exemple clair : une seule requête recherche l'intégralité de l'espace de travail d'un client, appelant de nombreux outils pour extraire des données de tables, d'indices vectoriels et de tableaux de bord. Pour y remédier, nous avons construit notre propre MemEx et l'avons validé au sein de plusieurs agents de production et internes.

Sur les tâches difficiles de récupération structurée d'entreprise, la Figure 1 montre que MemEx repousse la frontière coût-précision pour chaque modèle. Les modèles de pointe comme Opus 4.6 et Sonnet 4.6 gagnent 2 à 5 points de pourcentage avec 25 à 30 % de coût de jetons en moins. Les modèles à poids ouverts comme Qwen3.5-122B (18 % → 36 %) et Qwen3.5-397B (20 % → 38 %) doublent presque leur précision avec 40 à 50 % de coût de jetons en moins. Parce que MemEx peut opérer sur des entrées de longueur arbitraire, il débloque également deux autres applications : l'audit des trajectoires d'agents, y compris celles de MemEx, qui ne tiendraient normalement pas dans une seule fenêtre contextuelle, et la pensée parallèle sur plusieurs trajectoires.

Comment fonctionne MemEx

">

MemEx donne au LLM un bloc-notes programmable : un noyau Python typé qui contient les sorties d'outils, les transforme avec du code et matérialise uniquement les instructions d'impression (print statements) sous forme de jetons dans le contexte. Dans cet environnement, le déroulement devient un programme Python auto-extensible. À chaque tour, l'agent rédige un nouveau bloc, le noyau maintient l'état actif, et le bloc suivant s'appuie sur ce qui a précédé. Les outils sont exposés sous forme de fonctions Python typées avec des paramètres typés et des valeurs de retour typées. Les sorties d'outils arrivent sous forme d'objets Python dans la portée de MemEx, où elles persistent d'un tour à l'autre. L'agent les compose avec du code, définit des fonctions d'aide lorsqu'un modèle se répète, et génère des sous-agents sous forme d'appels de fonctions asynchrones sur la même portée.

MemEx fait partie de la famille "code-as-action" introduite par CodeAct (Wang et al., 2024), avec des variantes de production dans le Programmatic Tool Calling d'Anthropic et le Cloudflare Code Mode. MemEx se distingue en s'intégrant dans un cadre agentique existant de style ReAct (Yao et al., 2022), avec une portée persistante, des primitives de sous-agents et des retours typés intégrés. Ensemble, ces éléments débloquent des capacités que le paradigme d'appel d'outils JSON/XML ne possède pas :

• Gestion d'entrées arbitrairement grandes : Les documents, les ensembles de données et d'autres objets volumineux peuvent être conservés dans la portée Python en tant que variables.
• Retour d'objets typés : Les sorties d'outils sont des objets Python typés conservés en mémoire, et non des chaînes que le modèle doit matérialiser ou ré-analyser à chaque tour.
• Composition d'appels d'outils : La sortie d'un appel s'écoule directement dans les arguments de l'appel suivant en une seule ligne de code. Les sorties intermédiaires n'ont pas besoin d'être matérialisées dans le contexte de l'agent.
• Découpage des sorties d'outils : Les sorties peuvent être prétraitées, filtrées ou résumées dans le code avant que le modèle ne les voie.
• Génération de sous-agents asynchrones : Les agents peuvent générer par programme des sous-agents qui s'exécutent en parallèle avec le parent et agréger leurs résultats sans passer par le modèle principal.

Exemple d'agent LLM avec MemEx

Prenons une tâche d'entreprise concrète comme la comparaison des entonnoirs d'inscription à l'activation pour trois segments de clients et l'identification de la plus grande perte (Figure 1). Le flux de travail comporte quatre étapes :

1. récupérer les événements d'inscription et d'activation de l'entrepôt de données
2. les joindre par utilisateur
3. calculer les taux de conversion par segment à chaque étape
4. classer les pertes par segments.

Un agent d'appel d'outils (Tool Calling agent) équipé de python_exec fonctionne étape par étape. Chaque requête SQL et chaque calcul programmatique est un appel d'outil distinct, avec des DataFrames intermédiaires sérialisés en texte et recollés dans les tours suivants. La trace est lourde en jetons, ce qui la rend sujette à des pertes, lente, coûteuse et propice à de petites erreurs en cascade dans la tâche en aval.

Un agent MemEx écrit le même flux de travail comme un seul bloc de code : les requêtes renvoient des DataFrames natifs dans la portée, les fonctions d'aide les composent, et la réponse finale est renvoyée sous forme d'objet typé et validé via submit(). Même pensée, espace d'action différent.

Pour les tâches qui se décomposent en sous-problèmes, l'agent peut générer des sous-agents à l'intérieur d'un bloc. Lors de la génération de sous-agents, l'agent parent peut leur transmettre un accès partagé à n'importe quel objet. Les sous-agents s'exécutent de manière anticipée en parallèle avec le parent et peuvent renvoyer des résultats à l'agent principal une fois terminés. Par exemple :

La décomposition récursive devient une autre expression dans le même programme Python.

MemEx est développé sur aroll, le cadre de déploiement agentique de Databricks. Aroll alimente déjà des systèmes de production comme Genie, Agent Bricks' Supervisor Agent, et des efforts de recherche comme KARL. MemEx s'intègre dans la même boucle d'agent et les mêmes outils qu'aroll utilise déjà pour l'appel d'outils (Tool Calling).

Comment MemEx se comporte-t-il dans les tâches agentiques d'entreprise ?

Nous avons effectué des évaluations comparatives sur 9 modèles de pointe où nous avons comparé les appels d'outils structurés parallèles (Tool Calling) aux blocs de code Python (MemEx). Pas de réglage d'invite, pas d'adaptation par tâche. Nous comparons deux types de travail agentique d'entreprise : la lecture ancrée sur un grand corpus de texte (OfficeQA), et la récupération structurée sur un grand espace de travail de données relationnelles diverses (Enterprise Structured Retrieval).

Sur les deux tâches, MemEx Agent est meilleur et moins cher que Tool Calling Agent !

">

OfficeQA Pro demande à l'agent de répondre à des questions de raisonnement fondées sur le corpus des Bulletins du Trésor américain, soit environ 89 000 pages couvrant la période de 1939 à nos jours. Une question typique nécessite de localiser des preuves dans plusieurs documents, de naviguer dans des tableaux avec des hiérarchies imbriquées et des cellules fusionnées, et d'effectuer des calculs sur les données récupérées. Les réponses sont évaluées par correspondance exacte. Quatre des cinq points sur la frontière de Pareto coût-précision sont des configurations MemEx. Gemini 3.1 Pro MemEx est le point de frontière le moins cher à 0,62 $ par déploiement (52,9 % de précision), et Sonnet 4.6 MemEx approche la précision de GPT-5.5 Tool Calling à environ 70 % du coût. Sur neuf modèles, MemEx égale ou surpasse tous les modèles. Le milieu du peloton progresse le plus, avec Qwen 3.6 27B et Gemini 3.1 Pro gagnant environ 10 points de pourcentage.

">

La récupération structurée en entreprise (Enterprise Structured Retrieval) demande à l'agent de répondre à des questions en langage naturel sur des données relationnelles d'entreprise. L'agent dispose d'outils liés à la découverte de schémas et à l'exécution de requêtes SQL, et doit les utiliser pour effectuer la tâche d'analyse de données demandée par l'utilisateur, généralement avec peu d'informations sur où trouver les informations pertinentes dans l'espace de travail diversifié. Les réponses de l'agent sont évaluées par rapport aux réponses de référence en utilisant à la fois la validation déterministe des données et un LLM-as-a-judge. Comme le montrent les figures 1 et 6, chaque modèle montre un gain important avec MemEx, à l'exception de GPT 5.5 qui affiche des performances de parité. En termes de coût, le constat est tout aussi probant. Qwen 122B passe de 56 à 28 appels d'outils par déploiement tout en doublant son score ; Sonnet de 28 à 17 ; Opus de 33 à 21.¹ Cela se traduit par une réduction de moitié des coûts pour la plupart des modèles. Le schéma fait écho à OfficeQA Pro : plus la tâche est difficile, plus les objets natifs et l'état persistant prouvent leur utilité.

Chaque comparaison a été exécutée sans ajustement de prompt, sans adaptation par tâche et sans modifications spécifiques au modèle. La boucle de l'agent, les prompts système et les outils sont identiques pour les deux systèmes. La seule différence réside dans l'espace d'action : appels d'outils structurés JSON/XML versus blocs de code Python de MemEx.

MemEx opérant sur des traces agentiques

Les trajectoires agentiques sont elles-mêmes des objets volumineux. Dans le paradigme Tool Calling, l'analyse des trajectoires nécessite généralement de les aplatir en texte, ce qui entraîne une perte d'informations et une lourdeur contextuelle, et l'analyse de plusieurs trajectoires simultanément est souvent irréalisable. Les trajectoires peuvent même s'étendre sur plusieurs fenêtres de contexte, avec une compression entre les deux ; comment un LLM peut-il analyser une trace qui, par définition, ne tient pas dans son contexte ? Mais une trajectoire n'est qu'un autre objet Python, donc MemEx peut la charger directement dans sa portée et raisonner dessus. Nous présentons deux applications : premièrement, un agent d'audit basé sur MemEx qui analyse les trajectoires de Qwen 3.6-27B sur OfficeQA-Pro pour expliquer pourquoi MemEx surpasse Tool Calling ; deuxièmement, la mise à l'échelle au moment du test sur OfficeQA-Pro, avec un agent MemEx qui bat un agent Tool Calling équivalent.

MemEx audite MemEx : Analyse des traces agentiques

Pour analyser pourquoi le passage à MemEx a entraîné une amélioration des performances pour les modèles open source, tels que Qwen 3.6-27B, nous nous tournons vers MemEx pour l'expliquer. En particulier, nous instancions un agent d'audit qui prend une question OfficeQA, sa réponse de référence et six trajectoires de résolution (3 d'un agent MemEx et 3 d'un agent Tool Calling) directement dans sa portée Python, et demande à un agent Sonnet 4.6 basé sur MemEx de classer chaque trajectoire erronée selon une taxonomie à quatre axes de modes de défaillance.

Notre analyse porte sur 66 questions OfficeQA Pro où les six tentatives n'étaient pas toutes correctes ou incorrectes, ce qui a donné 173 trajectoires. Les quatre axes se divisent en deux grands groupes :

- Erreurs de fondation (~83 %) : Cas où le modèle récupère une valeur préliminaire au lieu d'un chiffre révisé, interprète mal une terminologie ambiguë (par exemple, variance d'échantillon vs. de population, ou précision d'arrondi pour les "centièmes"), ou extrait la mauvaise colonne d'un tableau valide.

- Erreurs de stratégie de recherche et d'exécution : Erreur dans la planification de la séquence de récupération ou échec de l'intégration correcte des données récupérées dans les calculs finaux.

Pour les erreurs de stratégie de recherche et d'exécution, MemEx constate que l'agent MemEx a réduit les erreurs d'un facteur 2 par rapport à Tool Calling. Cela s'explique par le fait que, pour MemEx, la récupération peut se faire directement dans des variables Python, ce qui permet au modèle d'éviter de copier des valeurs de la sortie d'un outil vers l'appel d'outil suivant, et plusieurs appels d'outils peuvent être regroupés en un seul tour. Tool Calling n'a pas un tel raccourci et doit toujours transcrire les valeurs entre les appels, ce qui peut parfois entraîner des erreurs. Par exemple, dans une trajectoire, une valeur de 3 501 provenant d'un document récupéré a été retapée dans l'appel suivant comme 3531.

Pensée parallèle agentique avec MemEx

Une approche courante pour la mise à l'échelle du calcul au moment du test est la pensée parallèle, où plusieurs exécutions indépendantes d'une tâche sont agrégées en une réponse finale. Dans la pensée parallèle agentique, comme l'approche utilisée dans KARL, des résumés des tentatives indépendantes sont transmis à un agent agrégateur. Cette étape de résumé est sujette à perte d'informations mais inévitable dans la configuration standard, car il est peu pratique d'intégrer plusieurs trajectoires complètes dans la fenêtre de contexte d'un modèle. Avec MemEx, nous pouvons plutôt charger ces trajectoires comme variables de portée, contournant entièrement la représentation sujette à perte.

">

Dans le résultat présenté à la Figure 7, nous utilisons Claude Sonnet 4.6 comme agrégateur sur huit trajectoires Qwen-3.6-27B générées indépendamment. Pour nous assurer que l'agrégateur ne résout pas simplement le problème par lui-même, nous supprimons ses outils de recherche de fichiers, le limitant à la vérification et à la sélection. L'agent basé sur MemEx, qui reçoit les trajectoires complètes en entrée, surpasse l'agent Tool Calling équivalent qui ne reçoit que leurs résumés. Dans un cas, l'agrégateur de trajectoires a détecté une erreur de duplication dans un bulletin précédent en lisant les sorties brutes des outils des trajectoires d'entrée ; l'agrégateur Tool Calling n'a pas pu vérifier l'affirmation de données dupliquées, son entrée étant limitée aux résumés, et s'est rabattu sur le vote majoritaire sur la source corrompue.

Architecture MemEx

Les agents Tool Calling émettent un ou plusieurs appels d'outils structurés par tour (JSON ou XML), chacun conforme à un schéma d'outil prédéfini, dans la boucle action-observation introduite par ReAct (Yao et al., 2022). CodeAct (Wang et al., 2024) a remplacé ce format par un noyau Python persistant : l'agent émet du code Python arbitraire, et les variables et définitions de fonctions sont conservées d'un tour à l'autre. Les variantes de production du même paradigme incluent Anthropic's Programmatic Tool Calling (PTC) et Cloudflare Code Mode ; PTC conserve également l'état entre les requêtes en réutilisant le même conteneur, tandis que Code Mode ne le fait pas. MemEx étend ce paradigme avec quatre ajouts supplémentaires :

• Intégration transparente d'outils avec schémas de paramètres préservés.
• Portée Python en direct au début du déploiement.
• Typé submit() pour les retours structurés.
• Non bloquant spawn_agent() pour les sous-agents parallèles, généralisant les Recursive Language Models (Zhang et al., 2025).

L'implémentation repose sur trois choix de conception :

Le code comme action, dans un REPL persistant

L'action de l'agent est un bloc de code Python arbitraire, exécuté dans un espace de noms qui persiste d'un tour à l'autre. Les outils, les objets de portée et les résultats précédents vivent tous dans cet espace de noms. L'agent lit les observations (stdout, valeurs de retour, erreurs), puis écrit plus de code. La même boucle d'observation-action qui exécute Tool Calling exécute MemEx ; seul l'espace d'action change.

Intégration transparente pour Tool Calling

Les outils Tool Calling existants sont automatiquement injectés comme fonctions Python, y compris les schémas de paramètres et les métadonnées de type de retour. Passer un agent existant de Tool Calling à MemEx est un simple changement de configuration.

Exécution agnostique du backend

Le même code d'agent s'exécute dans trois backends, choisis au moment de la configuration :

• En processus pour une itération rapide pendant la recherche.
• En sous-processus pour l'isolation pendant l'évaluation.
• En pool pour la génération de lots à haut débit (données d'entraînement, déploiements à grande échelle).

Pour les déploiements en production, le noyau peut être remplacé par un bac à sable hébergé comme les Managed Agents d'Anthropic. Même code d'agent, avec isolation du système de fichiers, contrôles de sortie réseau et plafonds de ressources gérés par l'hôte.

Quelle est la prochaine étape ?

MemEx arrive entre les mains de vos agents. Nous le déployons sur les agents propriétaires de Databricks et Agent Bricks : si vous développez sur les agents Databricks aujourd'hui, vous pourrez bientôt utiliser MemEx.

Nous post-entraînons nos modèles pour l'espace d'action MemEx. MemEx lui-même est le substrat : il génère des données synthétiques, exécute des vérificateurs agentiques et alimente la boucle d'entraînement.

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

---

¹ Dans MemEx, les appels d'outils sont des blocs de code Python qui peuvent avoir des outils d'analyse de données ou d'autres outils appelés comme fonctions asynchrones.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original