MemEx: Ein programmierbarer Notizblock für LLM-Agenten

Im Jahr 1945 stellte sich Vannevar Bush eine schreibtischgroße Maschine vor, die das Gedächtnis eines Wissenschaftlers erweitern würde, indem sie jedes Dokument, jede Anmerkung und jeden Gedankengang zur jederzeitigen Abrufbarkeit speicherte. Er nannte sie MemEx. Bush löste ein menschliches Problem: Gehirne, die von Informationen überfordert waren, die sie nicht griffbereit halten konnten. Acht Jahrzehnte später stoßen LLM-Agenten an eine bemerkenswert ähnliche Grenze.

Im aktuellen Paradigma des Agentic Tool Calling ist das Kontextfenster das einzige persistente Substrat, über das das Modell operieren kann. Es ist ein gemeinsamer Bereich, der den System-Prompt, die Benutzeranfrage, die Modellbegründung, Tool-Aufrufe und rohe Tool-Ausgaben enthält. Tool-Ausgaben sind die schlimmsten Übeltäter: Eine einzelne SQL-Abfrage könnte Millionen von Zeilen zurückgeben, und in den heutigen Umgebungen werden diese Zeilen bei jeder nachfolgenden Runde mitgeführt, selbst wenn nur eine einzige Zelle jemals relevant war. Der Agent hat keine Möglichkeit, das Ergebnis zu zerlegen, zusammenzufassen oder zu speichern, bevor es das Fenster überflutet.

Bei Databricks stoßen wir ständig an diese Grenze. Unsere Produktionsagenten, von Genie bis Agent Bricks, stoßen irgendwann auf dieselben Kontextbeschränkungen. Genie liefert ein klares Beispiel: Eine einzelne Abfrage durchsucht den gesamten Arbeitsbereich eines Kunden und ruft viele Tools auf, um Daten aus Tabellen, Vektorindizes und Dashboards abzurufen. Um dies zu beheben, haben wir ein eigenes MemEx entwickelt und es in mehreren Produktions- und internen Agenten validiert.

Bei anspruchsvollen strukturierten Abrufaufgaben in Unternehmen zeigt Abbildung 1, dass MemEx die Kosten-vs.-Genauigkeits-Grenze für jedes Modell verschiebt. Frontier-Modelle wie Opus 4.6 und Sonnet 4.6 gewinnen 2–5 Prozentpunkte bei 25–30 % geringeren Token-Kosten. Open-Weights-Modelle wie Qwen3.5-122B (18 % → 36 %) und Qwen3.5-397B (20 % → 38 %) verdoppeln ihre Genauigkeit nahezu bei 40–50 % geringeren Token-Kosten. Da MemEx über beliebig lange Eingaben operieren kann, erschließt es auch zwei weitere Anwendungen: die Überprüfung von Agenten-Trajektorien, einschließlich der von MemEx selbst, die normalerweise nicht in ein einzelnes Kontextfenster passen würden, und paralleles Denken über mehrere Trajektorien hinweg.

Wie MemEx funktioniert

">

MemEx bietet dem LLM einen programmierbaren Notizblock: einen typisierten Python-Kernel, der Tool-Ausgaben speichert, sie mit Code transformiert und nur die Print-Anweisungen als Tokens im Kontext materialisiert. Innerhalb dieser Umgebung wird der Rollout zu einem sich selbst erweiternden Python-Programm. In jeder Runde erstellt der Agent einen neuen Block, der Kernel hält den Zustand am Leben, und der nächste Block baut auf dem Vorherigen auf. Tools werden als typisierte Python-Funktionen mit typisierten Parametern und typisierten Rückgabewerten bereitgestellt. Tool-Ausgaben landen als Python-Objekte im Bereich von MemEx, wo sie über mehrere Runden hinweg bestehen bleiben. Der Agent komponiert sie mit Code, definiert Hilfsfunktionen, wenn sich ein Muster wiederholt, und startet Sub-Agenten als asynchrone Funktionsaufrufe über denselben Bereich.

MemEx gehört zur Familie der Code-as-Action-Ansätze, die von CodeAct (Wang et al., 2024) eingeführt wurden, mit Produktionsvarianten in Anthropic's Programmatic Tool Calling und Cloudflare Code Mode. MemEx unterscheidet sich dadurch, dass es sich in ein bestehendes ReAct (Yao et al., 2022)-ähnliches Agenten-Framework einfügt, mit persistentem Geltungsbereich, Sub-Agent-Primitiven und verdrahteten typisierten Rückgabewerten. Zusammen erschließen diese Funktionen, die dem JSON/XML-Tool-Calling-Paradigma fehlen:

• Verarbeitung beliebig großer Eingaben: Dokumente, Datensätze und andere große Objekte können als Variablen im Python-Geltungsbereich gehalten werden.
• Rückgabe typisierter Objekte: Tool-Ausgaben sind typisierte Python-Objekte, die im Speicher gehalten werden, keine Strings, die das Modell bei jeder Runde materialisieren oder neu parsen muss.
• Zusammensetzen von Tool-Aufrufen: Die Ausgabe eines Aufrufs fließt direkt in die Argumente des nächsten Aufrufs innerhalb einer einzigen Codezeile. Zwischenergebnisse müssen nicht im Kontext des Agenten materialisiert werden.
• Zerlegen von Tool-Ausgaben: Ausgaben können im Code vorverarbeitet, gefiltert oder zusammengefasst werden, bevor das Modell sie sieht.
• Starten asynchroner Sub-Agenten: Agenten können programmatisch Sub-Agenten starten, die parallel zum übergeordneten Agenten laufen und ihre Ergebnisse aggregieren, ohne den Umweg über das Hauptmodell zu nehmen.

Beispiel eines LLM-Agenten mit MemEx

Betrachten Sie eine konkrete Unternehmensaufgabe, wie den Vergleich von Anmelde-zu-Aktivierungs-Funnels für drei Kundensegmente und die Identifizierung des größten Rückgangs (Abbildung 1). Der Workflow umfasst vier Schritte:

1. Anmelde- und Aktivierungsereignisse aus dem Data Warehouse abrufen
2. sie pro Benutzer zusammenführen
3. segmentweise Konversionsraten in jeder Phase berechnen
4. die Rückgänge über alle Segmente hinweg rangieren.

Ein Tool Calling Agent, ausgestattet mit python_exec, arbeitet Schritt für Schritt. Jede SQL-Abfrage und jede programmatische Berechnung ist ein separater Tool-Aufruf, wobei Zwischen-DataFrames in Text serialisiert und in nachfolgende Runden eingefügt werden. Die Ablaufverfolgung ist token-intensiv, was sie verlustbehaftet, langsam, teuer und anfällig für kleine Kaskadenfehler in der nachgelagerten Aufgabe macht.

Ein MemEx-Agent schreibt denselben Workflow als einen einzigen Codeblock: Abfragen geben native DataFrames im Geltungsbereich zurück, Hilfsfunktionen komponieren sie, und die endgültige Antwort kommt als typisiertes, validiertes Objekt über submit() zurück. Derselbe Gedanke, anderer Aktionsraum.

Für Aufgaben, die sich in Unterprobleme zerlegen lassen, kann der Agent Sub-Agenten innerhalb eines Blocks starten. Beim Starten von Sub-Agenten kann der übergeordnete Agent gemeinsamen Zugriff auf jedes Objekt übergeben. Sub-Agenten laufen eifrig parallel zum übergeordneten Agenten und können nach Abschluss Ergebnisse an den Hauptagenten zurückgeben. Zum Beispiel:

Rekursive Zerlegung wird zu einem weiteren Ausdruck im selben Python-Programm.

MemEx wird auf aroll, dem Agentic Rollouts Framework von Databricks, entwickelt. Aroll treibt bereits Produktionssysteme wie Genie, Agent Bricks' Supervisor Agent und Forschungsbemühungen wie KARL an. MemEx integriert sich in denselben Agenten-Loop und dieselben Tools, die aroll bereits für Tool Calling verwendet.

Wie schneidet MemEx bei agentenbasierten Unternehmensaufgaben ab?

Wir führten direkte Evaluierungen über 9 Frontier-Modelle durch, bei denen wir parallele strukturierte Tool-Aufrufe (Tool Calling) mit Python-Codeblöcken (MemEx) verglichen. Keine Prompt-Optimierung, keine aufgabenspezifische Anpassung. Wir vergleichen zwei Arten von agentenbasierten Unternehmensaufgaben: fundiertes Lesen über einen großen Textkorpus (OfficeQA) und strukturierten Abruf über einen großen Arbeitsbereich vielfältiger relationaler Daten (Enterprise Structured Retrieval).

Bei beiden Aufgaben ist der MemEx Agent besser und günstiger als der Tool Calling Agent!

">

OfficeQA Pro fordert den Agenten auf, fundierte Schlussfolgerungsfragen über das Korpus der U.S. Treasury Bulletins zu beantworten, das etwa 89.000 Seiten aus dem Zeitraum von 1939 bis heute umfasst. Eine typische Frage erfordert das Auffinden von Beweisen in mehreren Dokumenten, das Navigieren in Tabellen mit verschachtelten Hierarchien und zusammengeführten Zellen sowie das Durchführen von Berechnungen mit den abgerufenen Daten. Die Antworten werden nach exakter Übereinstimmung bewertet. Vier der fünf Punkte auf der Pareto-Grenze für Kosten-vs.-Genauigkeit sind MemEx-Konfigurationen. Gemini 3.1 Pro MemEx ist der günstigste Grenzpunkt mit 0,62 $ pro Rollout (52,9 % Genauigkeit), und Sonnet 4.6 MemEx erreicht die Genauigkeit von GPT-5.5 Tool Calling bei etwa 70 % der Kosten. Über neun Modelle hinweg liegt MemEx gleichauf oder gewinnt bei jedem Modell. Das Mittelfeld bewegt sich am stärksten, wobei Qwen 3.6 27B und Gemini 3.1 Pro rund 10 Prozentpunkte zulegen.

">

Enterprise Structured Retrieval fordert den Agenten auf, natürlichsprachliche Fragen über relationale Unternehmensdaten zu beantworten. Dem Agenten werden Tools zur Schema-Erkennung und SQL-Abfrageausführung zur Verfügung gestellt, die er nutzen muss, um die vom Benutzer angeforderte Datenanalyseaufgabe durchzuführen, meist mit wenig Informationen darüber, wo in der vielfältigen Arbeitsumgebung die relevanten Informationen zu finden sind. Die Antworten des Agenten werden anhand von Ground-Truth-Antworten bewertet, wobei sowohl deterministische Datenvalidierung als auch LLM-als-Richter zum Einsatz kommen. Wie in den Abbildungen 1 und 6 zu sehen ist, zeigt jedes Modell unter MemEx einen starken Zuwachs, mit Ausnahme von GPT 5.5, das eine Gleichstandsleistung aufweist. Kostenmäßig ist die Situation ebenso überzeugend. Qwen 122B sinkt von 56 auf 28 Tool-Aufrufe pro Rollout, während sich die Punktzahl verdoppelt; Sonnet von 28 auf 17; Opus von 33 auf 21.¹ Dies führt zu einer Kostenhalbierung bei den meisten Modellen. Das Muster spiegelt OfficeQA Pro wider: Je schwieriger die Aufgabe, desto mehr zahlen sich native Objekte und persistenter Zustand aus.

Jeder Vergleich wurde ohne Prompt-Tuning, ohne aufgabenspezifische Anpassung und ohne modellspezifische Optimierungen durchgeführt. Der Agenten-Loop, die System-Prompts und die Tools sind bei beiden Ansätzen identisch. Der einzige Unterschied liegt im Aktionsraum: JSON/XML-strukturierte Tool-Aufrufe versus MemEx' Python-Codeblöcke.

MemEx arbeitet mit Agenten-Traces

Agenten-Trajektorien sind selbst sperrige Objekte. Im Tool-Calling-Paradigma erfordert die Analyse von Trajektorien in der Regel deren Abflachung zu Text, was verlustbehaftet und kontextlastig ist, und die gleichzeitige Analyse mehrerer Trajektorien ist oft undurchführbar. Trajektorien können sogar mehrere Kontextfenster umfassen, mit Komprimierung dazwischen; wie kann ein LLM einen Trace analysieren, der per Definition nicht in seinen Kontext passt? Aber eine Trajektorie ist nur ein weiteres Python-Objekt, sodass MemEx sie direkt in den Gültigkeitsbereich laden und darüber nachdenken kann. Wir zeigen zwei Anwendungen: erstens einen MemEx-basierten Audit-Agenten, der Qwen 3.6-27B-Trajektorien auf OfficeQA-Pro analysiert, um zu erklären, warum MemEx Tool Calling übertrifft; zweitens die Skalierung zur Testzeit auf OfficeQA-Pro mit einem MemEx-Agenten, der einen äquivalenten Tool Calling-Agenten schlägt.

MemEx prüft MemEx: Analyse von Agenten-Traces

Um zu analysieren, warum der Wechsel zu MemEx zu einer Leistungssteigerung bei Open-Source-Modellen wie Qwen 3.6-27B führte, wenden wir uns an MemEx zur Erklärung. Insbesondere instanziieren wir einen Audit-Agenten, der eine OfficeQA-Frage, ihre Ground-Truth-Antwort und sechs Lösungs-Trajektorien (3 von einem MemEx-Agenten und 3 von einem Tool Calling-Agenten) direkt in seinen Python-Gültigkeitsbereich übernimmt und einen MemEx-basierten Sonnet 4.6-Agenten bittet, jede falsche Trajektorie entlang einer vierachsigen Taxonomie von Fehlermodi zu klassifizieren.

Unsere Analyse konzentriert sich auf 66 OfficeQA Pro-Fragen, bei denen nicht alle sechs Versuche korrekt oder inkorrekt waren, was 173 Trajektorien ergab. Die vier Achsen teilen sich in zwei große Gruppen auf:

- Grundierungsfehler (~83%): Fälle, in denen das Modell einen vorläufigen Wert anstelle einer überarbeiteten Zahl abruft, mehrdeutige Terminologie missinterpretiert (z. B. Stichproben- vs. Populationsvarianz oder Rundungsgenauigkeit für "Hundertstel") oder die falsche Spalte aus einer gültigen Tabelle extrahiert.

- Fehler bei Suchstrategie und Ausführung: Fehler bei der Planung der Abrufsequenz oder das Versäumnis, abgerufene Daten korrekt in die endgültigen Berechnungen zu integrieren.

Bei Fehlern in der Suchstrategie und Ausführung stellt MemEx fest, dass der MemEx-Agent eine 2-fache Fehlerreduzierung im Vergleich zu Tool Calling aufwies. Dies liegt daran, dass bei MemEx der Abruf direkt in Python-Variablen erfolgen kann, sodass das Modell das Kopieren von Werten aus der Ausgabe eines Tools in den nächsten Tool-Aufruf vermeiden kann und mehrere Tool-Aufrufe in einem einzigen Durchgang gebündelt werden können. Tool Calling hat keine solche Abkürzung und muss Werte immer zwischen den Aufrufen transkribieren, was manchmal zu Fehlern führt. Zum Beispiel wurde in einer Trajektorie ein Wert von 3.501 aus einem abgerufenen Dokument im nächsten Aufruf als 3531 neu eingegeben.

Agentisches Parallel-Denken mit MemEx

Ein gängiger Ansatz zur Skalierung der Testzeitberechnung ist das parallele Denken, bei dem mehrere unabhängige Durchläufe einer Aufgabe zu einer endgültigen Antwort aggregiert werden. Beim agentischen Parallel-Denken, wie es beispielsweise im KARL-Ansatz verwendet wird, werden Zusammenfassungen der unabhängigen Versuche an einen Aggregator-Agenten übergeben. Dieser Zusammenfassungsschritt ist verlustbehaftet, aber im Standard-Setup unvermeidlich, da es unpraktisch ist, mehrere vollständige Trajektorien in das Kontextfenster eines Modells einzupassen. Mit MemEx können wir diese Trajektorien stattdessen als Bereichsvariablen laden und die verlustbehaftete Darstellung vollständig umgehen.

">

Im in Abbildung 7 gezeigten Ergebnis verwenden wir Claude Sonnet 4.6 als Aggregator über acht unabhängig generierte Qwen-3.6-27B-Trajektorien. Um sicherzustellen, dass der Aggregator das Problem nicht einfach selbst neu löst, entfernen wir seine Dateisuchwerkzeuge und beschränken ihn auf Verifizierung und Auswahl. Der MemEx-basierte Agent, der die vollständigen Trajektorien als Eingabe erhält, übertrifft den äquivalenten Tool-Calling-Agenten, der nur deren Zusammenfassungen erhält. In einem Fall entdeckte der Trajektorien-Aggregator einen Duplikationsfehler in einem früheren Bulletin, indem er rohe Tool-Ausgaben aus den Eingabetrajektorien las; der Tool-Calling-Aggregator konnte den Anspruch auf doppelte Daten aufgrund seiner auf die Zusammenfassungen beschränkten Eingabe nicht verifizieren und griff auf eine Mehrheitsentscheidung der korrumpierten Quelle zurück.

MemEx-Architektur

Tool-Calling-Agenten geben pro Runde einen oder mehrere strukturierte Tool-Aufrufe (JSON oder XML) aus, die jeweils einem vordefinierten Tool-Schema entsprechen, in der Aktions-Beobachtungs-Schleife, die von ReAct (Yao et al., 2022) eingeführt wurde. CodeAct (Wang et al., 2024) ersetzte dieses Format durch einen persistenten Python-Kernel: Der Agent gibt beliebigen Python-Code aus, und Variablen- sowie Funktionsdefinitionen werden über Runden hinweg beibehalten. Produktionsvarianten desselben Paradigmas umfassen Anthropic's Programmatic Tool Calling (PTC) und Cloudflare Code Mode; PTC behält auch den Zustand über Anfragen hinweg bei, indem derselbe Container wiederverwendet wird, während Code Mode dies nicht tut. MemEx erweitert dieses Paradigma um vier zusätzliche Punkte:

• Drop-in-Tool-Integration mit beibehaltenen Parameterschemata.
• Live-Python-Scope beim Rollout-Start.
• Typisierte submit() für strukturierte Rückgaben.
• Nicht-blockierende spawn_agent() für parallele Sub-Agenten, die Recursive Language Models (Zhang et al., 2025) verallgemeinern.

Die Implementierung basiert auf drei Designentscheidungen:

Code als Aktion, in einem persistenten REPL

Die Aktion des Agenten ist ein beliebiger Python-Codeblock, der in einem Namespace ausgeführt wird, der über Runden hinweg persistent ist. Tools, Scope-Objekte und frühere Ergebnisse leben alle in diesem Namespace. Der Agent liest Beobachtungen (stdout, Rückgabewerte, Fehler) und schreibt dann weiteren Code. Dieselbe Beobachtungs-Aktions-Schleife, die Tool Calling ausführt, führt auch MemEx aus; nur der Aktionsraum ändert sich.

Drop-in für Tool Calling

Bestehende Tool-Calling-Tools werden automatisch als Python-Funktionen injiziert, einschließlich Parameterschemata und Metadaten für den Rückgabetyp. Das Umschalten eines bestehenden Agenten von Tool Calling auf MemEx ist eine einzige Konfigurationsänderung.

Backend-agnostische Ausführung

Derselbe Agenten-Code läuft in drei Backends, die zur Konfigurationszeit ausgewählt werden:

• In-Process für schnelle Iteration während der Forschung.
• Subprozess zur Isolation während der Evaluierung.
• Pool für Batch-Generierung mit hohem Durchsatz (Trainingsdaten, groß angelegte Rollouts).

Für Produktionsbereitstellungen kann der Kernel durch eine gehostete Sandbox wie Anthropic's Managed Agents ersetzt werden. Derselbe Agenten-Code, mit Dateisystemisolation, Netzwerk-Egress-Kontrollen und Ressourcenbeschränkungen, die vom Host verwaltet werden.

Was kommt als Nächstes?

MemEx kommt in die Hände Ihrer Agenten. Wir rollen es bei den Erstanbieter-Agenten von Databricks und Agent Bricks aus: Wenn Sie heute auf Databricks-Agenten aufbauen, werden Sie MemEx bald nutzen können.

Wir trainieren unsere Modelle für den MemEx-Aktionsraum nach. MemEx selbst ist das Substrat: Es generiert synthetische Daten, führt agentische Verifizierer aus und speist die Trainingsschleife.

Autoren: 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 sind Tool-Aufrufe Python-Codeblöcke, die Datenanalyse- oder andere Tools als asynchrone Funktionen aufrufen können.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag