MemEx: Un bloc de notas programable para agentes LLM

En 1945, Vannevar Bush imaginó una máquina del tamaño de un escritorio que extendería la memoria de un científico almacenando cada documento, anotación y rastro de pensamiento para su recuperación bajo demanda. La llamó MemEx. Bush estaba resolviendo un problema humano: mentes abrumadas por información que no podían tener a mano. Ocho décadas después, los agentes LLM están chocando contra un muro notablemente similar.

En el paradigma actual de Llamada a Herramientas Agéntica, la ventana de contexto es el único sustrato persistente sobre el que el modelo puede operar. Es un espacio compartido que contiene el prompt del sistema, la consulta del usuario, el razonamiento del modelo, las llamadas a herramientas y las salidas de herramientas en bruto. Las salidas de herramientas son las peores infractoras: una sola consulta SQL podría devolver millones de filas, y en los arneses actuales esas filas se transmiten en cada turno subsiguiente, incluso si solo una celda importó. El agente no tiene forma de segmentar, resumir o almacenar el resultado antes de que inunde la ventana.

En Databricks, nos encontramos constantemente con esta limitación. Nuestros agentes de producción, desde Genie hasta Agent Bricks, se topan con las mismas limitaciones de contexto en algún momento. Genie ofrece un ejemplo claro: una única consulta busca en todo el espacio de trabajo de un cliente, llamando a muchas herramientas para extraer datos de tablas, índices vectoriales y paneles. Para abordar esto, construimos nuestro propio MemEx y lo validamos dentro de múltiples agentes de producción e internos.

En tareas difíciles de recuperación estructurada empresarial, la Figura 1 muestra que MemEx impulsa la frontera de costo-vs-precisión para cada modelo. Modelos de vanguardia como Opus 4.6 y Sonnet 4.6 ganan entre 2 y 5 puntos porcentuales con un costo de token entre un 25 y un 30% menor. Modelos de código abierto como Qwen3.5-122B (18% → 36%) y Qwen3.5-397B (20% → 38%) casi duplican su precisión con un costo de token entre un 40 y un 50% menor. Dado que MemEx puede operar con entradas arbitrariamente largas, también desbloquea dos aplicaciones adicionales: la auditoría de trayectorias de agentes, incluyendo las propias de MemEx, que normalmente no cabrían en una sola ventana de contexto, y el pensamiento paralelo a través de múltiples trayectorias.

Cómo funciona MemEx

">

MemEx le da al LLM un bloc de notas programable: un kernel Python tipado que almacena las salidas de las herramientas, las transforma con código y materializa solo las sentencias `print` como tokens en el contexto. Dentro de este entorno, la ejecución se convierte en un programa Python autoextensible. Durante cada turno, el agente crea un nuevo bloque, el kernel mantiene el estado vivo y el siguiente bloque se basa en lo anterior. Las herramientas se exponen como funciones Python tipadas con parámetros tipados y valores de retorno tipados. Las salidas de las herramientas llegan como objetos Python al ámbito de MemEx, donde persisten a lo largo de los turnos. El agente las compone con código, define funciones auxiliares cuando un patrón se repite y genera subagentes como llamadas a funciones asíncronas sobre el mismo ámbito.

MemEx pertenece a la familia de "código como acción" introducida por CodeAct (Wang et al., 2024), con variantes de producción en Programmatic Tool Calling de Anthropic y Cloudflare Code Mode. MemEx se distingue por integrarse en un framework agéntico existente al estilo ReAct (Yao et al., 2022), con ámbito persistente, primitivas de subagente y retornos tipados incorporados. Juntos, estos desbloquean capacidades de las que carece el paradigma de llamada a herramientas JSON/XML:

• Manejo de entradas arbitrariamente grandes: Documentos, conjuntos de datos y otros objetos grandes pueden mantenerse en el ámbito de Python como variables.
• Devolución de objetos tipados: Las salidas de las herramientas son objetos Python tipados que se mantienen en memoria, no cadenas que el modelo tenga que materializar o volver a analizar en cada turno.
• Composición de llamadas a herramientas: La salida de una llamada fluye directamente a los argumentos de la siguiente llamada dentro de una sola línea de código. Las salidas intermedias no necesitan materializarse en el contexto del agente.
• Segmentación de salidas de herramientas: Las salidas pueden preprocesarse, filtrarse o resumirse en código antes de que el modelo las vea.
• Generación de subagentes asíncronos: Los agentes pueden generar programáticamente subagentes que se ejecutan junto con el padre y agregan sus resultados sin pasar por el modelo principal.

Ejemplo de Agente LLM con MemEx

Tomemos una tarea empresarial concreta, como comparar los embudos de registro a activación para tres segmentos de clientes e identificar la mayor caída (Figura 1). El flujo de trabajo tiene cuatro pasos:

1. recuperar eventos de registro y activación del almacén de datos
2. unirlos por usuario
3. calcular las tasas de conversión por segmento en cada etapa
4. clasificar las caídas entre segmentos.

Un agente de Llamada a Herramientas equipado con python_exec trabaja paso a paso. Cada consulta SQL y cada cálculo programático es una llamada a herramienta separada, con DataFrames intermedios serializados a texto y vueltos a pegar en turnos subsiguientes. El rastro es pesado en tokens, lo que lo hace propenso a pérdidas, lento, costoso y susceptible a pequeños errores en cascada en la tarea posterior.

Un agente MemEx escribe el mismo flujo de trabajo como un único bloque de código: las consultas devuelven DataFrames nativos en el ámbito, las funciones auxiliares los componen y la respuesta final se devuelve como un objeto tipado y validado a través de submit(). Mismo pensamiento, diferente espacio de acción.

Para tareas que se descomponen en subproblemas, el agente puede generar subagentes desde dentro de un bloque. Al generar subagentes, el agente padre puede pasar acceso compartido a cualquier objeto. Los subagentes se ejecutan ávidamente en paralelo con el padre y pueden devolver resultados al agente principal al finalizar. Por ejemplo:

La descomposición recursiva se convierte en otra expresión en el mismo programa Python.

MemEx se desarrolla sobre aroll, el framework de despliegues agénticos de Databricks. Aroll ya impulsa sistemas de producción como Genie, el Agente Supervisor de Agent Bricks, y esfuerzos de investigación como KARL. MemEx se conecta al mismo ciclo de agente y herramientas que aroll ya utiliza para la Llamada a Herramientas.

¿Cómo funciona MemEx en tareas agénticas empresariales?

Realizamos evaluaciones directas en 9 modelos de vanguardia donde comparamos llamadas a herramientas estructuradas paralelas (Llamada a Herramientas) frente a bloques de código Python (MemEx). Sin ajuste de prompt, sin adaptación por tarea. Comparamos dos tipos de trabajo agéntico empresarial: lectura fundamentada sobre un gran corpus de texto (OfficeQA) y recuperación estructurada sobre un gran espacio de trabajo de datos relacionales diversos (Recuperación Estructurada Empresarial).

En ambas tareas, ¡el Agente MemEx es mejor y más económico que el Agente de Llamada a Herramientas!

">

OfficeQA Pro pide al agente que responda preguntas de razonamiento fundamentado sobre el corpus de los Boletines del Tesoro de EE. UU., aproximadamente 89.000 páginas que abarcan desde 1939 hasta la actualidad. Una pregunta típica requiere localizar evidencia en múltiples documentos, navegar tablas con jerarquías anidadas y celdas fusionadas, y realizar cálculos sobre los datos recuperados. Las respuestas se califican por coincidencia estricta. Cuatro de los cinco puntos en la frontera de Pareto de coste vs. precisión son configuraciones de MemEx. Gemini 3.1 Pro MemEx es el punto de frontera más económico con $0.62 por ejecución (52.9% de precisión), y Sonnet 4.6 MemEx se acerca a la precisión de la Llamada a Herramientas de GPT-5.5 con aproximadamente el 70% del coste. En nueve modelos, MemEx empata o gana en cada modelo. El centro del grupo es el que más se mueve, con Qwen 3.6 27B y Gemini 3.1 Pro ganando alrededor de 10 puntos porcentuales.

">

La Recuperación Estructurada Empresarial pide al agente que responda preguntas en lenguaje natural sobre datos relacionales empresariales. El agente recibe herramientas relacionadas con el descubrimiento de esquemas y la ejecución de consultas SQL, y debe utilizarlas para realizar la tarea de análisis de datos solicitada por el usuario, generalmente con poca información sobre dónde en el diverso espacio de trabajo encontrar la información relevante. Las respuestas del agente se califican con respecto a las respuestas de verdad fundamental utilizando tanto la validación de datos determinista como un LLM como juez. Como se ve en las Figuras 1 y 6, cada modelo muestra una fuerte ganancia con MemEx, excluyendo GPT 5.5 que muestra un rendimiento a la par. En cuanto al coste, la situación es igual de sólida. Qwen 122B baja de 56 a 28 llamadas a herramientas por ejecución mientras duplica su puntuación; Sonnet de 28 a 17; Opus de 33 a 21.¹ Esto resulta en una reducción de aproximadamente la mitad del coste en la mayoría de los modelos. El patrón se hace eco de OfficeQA Pro: cuanto más difícil es la tarea, más valor demuestran los objetos nativos y el estado persistente.

Cada comparación se ejecutó sin ajuste de prompts, sin adaptación por tarea y sin ajustes específicos del modelo. El bucle del agente, los prompts del sistema y las herramientas son idénticos en ambos entornos. La única diferencia es el espacio de acción, llamadas a herramientas estructuradas JSON/XML frente a bloques de código Python de MemEx.

MemEx operando en trazas agénticas

Las trayectorias agénticas son en sí mismas objetos voluminosos. En el paradigma de Llamada a Herramientas, analizar trayectorias generalmente requiere aplanarlas en texto, lo cual es propenso a pérdidas y consume mucho contexto, y analizar varias a la vez a menudo es inviable. Las trayectorias pueden incluso abarcar múltiples ventanas de contexto, con compresión intermedia; ¿cómo puede un LLM analizar una traza que, por definición, no cabe en su contexto? Pero una trayectoria es solo otro objeto Python, por lo que MemEx puede cargarla directamente en el ámbito y razonar sobre ella. Mostramos dos aplicaciones: primero, un agente de auditoría basado en MemEx que analiza las trayectorias de Qwen 3.6-27B en OfficeQA-Pro para explicar por qué MemEx supera a la Llamada a Herramientas; segundo, escalado en tiempo de prueba en OfficeQA-Pro, con un agente MemEx que supera a un agente de Llamada a Herramientas equivalente.

MemEx audita MemEx: Análisis de trazas agénticas

Para analizar por qué el cambio a MemEx resultó en una mejora del rendimiento para modelos de código abierto, como Qwen 3.6-27B, recurrimos a MemEx para obtener una explicación. En particular, instanciamos un agente de auditoría que toma una pregunta de OfficeQA, su respuesta de verdad fundamental y seis trayectorias de solución (3 de un agente MemEx y 3 de un agente de Llamada a Herramientas) directamente en su ámbito Python, y pide a un agente Sonnet 4.6 basado en MemEx que clasifique cada trayectoria incorrecta según una taxonomía de modos de fallo de cuatro ejes.

Nuestro análisis se centra en 66 preguntas de OfficeQA Pro donde no todos los seis intentos fueron correctos o incorrectos, lo que resultó en 173 trayectorias. Los cuatro ejes se dividen en dos grandes grupos:

- Errores de fundamentación (~83%): Casos en los que el modelo recupera un valor preliminar en lugar de una cifra revisada, malinterpreta terminología ambigua (por ejemplo, varianza de muestra vs. población, o precisión de redondeo para "centésimas"), o extrae la columna incorrecta de una tabla válida.

- Errores de estrategia y ejecución de búsqueda: Error en la planificación de la secuencia de recuperación o fallo al integrar correctamente los datos recuperados en los cálculos finales.

Para los errores de Estrategia y Ejecución de Búsqueda, MemEx encuentra que el agente MemEx tuvo una reducción de error de 2x en comparación con la Llamada a Herramientas. Esto se debe a que, para MemEx, la recuperación puede aterrizar directamente en variables de Python, por lo que el modelo puede evitar copiar valores de la salida de una herramienta a la siguiente llamada a herramienta, y múltiples llamadas a herramientas pueden agruparse en un solo turno. La Llamada a Herramientas no tiene tal atajo y siempre debe transcribir valores entre llamadas, lo que a veces provoca errores. Por ejemplo, en una trayectoria, un valor de 3.501 de un documento recuperado se volvió a escribir en la siguiente llamada como 3531.

Pensamiento paralelo agéntico con MemEx

Un enfoque común para escalar el cálculo en tiempo de prueba es el pensamiento paralelo, donde múltiples ejecuciones independientes de una tarea se agregan en una respuesta final. En el pensamiento paralelo agéntico, como el enfoque utilizado en KARL, los resúmenes de los intentos independientes se pasan a un agente agregador. Este paso de resumen es propenso a pérdidas, pero inevitable en la configuración estándar, ya que encajar múltiples trayectorias completas en la ventana de contexto de un modelo es poco práctico. Con MemEx, podemos cargar estas trayectorias como variables de ámbito, evitando por completo la representación con pérdidas.

">

En el resultado mostrado en la Figura 7, utilizamos Claude Sonnet 4.6 como un agregador sobre ocho trayectorias Qwen-3.6-27B generadas de forma independiente. Para asegurar que el agregador no esté simplemente resolviendo el problema por sí mismo, eliminamos sus herramientas de búsqueda de archivos, restringiéndolo a la verificación y selección. El agente basado en MemEx, que recibe las trayectorias completas como entrada, supera al agente equivalente de Tool Calling que recibe solo sus resúmenes. En un caso, el agregador de trayectorias detectó un error de duplicación en un boletín anterior al leer las salidas de herramientas en bruto de las trayectorias de entrada; el agregador de Tool Calling no pudo verificar la afirmación de datos duplicados debido a que su entrada estaba limitada a los resúmenes, y recurrió al voto mayoritario sobre la fuente corrupta.

Arquitectura de MemEx

Los agentes de Tool Calling emiten una o más llamadas a herramientas estructuradas por turno (JSON o XML), cada una conforme a un esquema de herramienta predefinido, en el bucle de acción-observación introducido por ReAct (Yao et al., 2022). CodeAct (Wang et al., 2024) reemplazó ese formato con un kernel de Python persistente: el agente emite código Python arbitrario, y las variables y definiciones de funciones se mantienen a lo largo de los turnos. Las variantes de producción del mismo paradigma incluyen Programmatic Tool Calling (PTC) de Anthropic y Cloudflare Code Mode; PTC también mantiene el estado entre solicitudes reutilizando el mismo contenedor, mientras que Code Mode no lo hace. MemEx extiende este paradigma con cuatro adiciones:

• Integración de herramientas "drop-in" con esquemas de parámetros preservados.
• Ámbito de Python en vivo al inicio del despliegue.
• Tipado submit() para retornos estructurados.
• No bloqueante spawn_agent() para subagentes paralelos, generalizando Modelos de Lenguaje Recursivos (Zhang et al., 2025).

La implementación se basa en tres decisiones de diseño:

Código como acción, en un REPL persistente

La acción del agente es un bloque de código Python arbitrario, ejecutado en un espacio de nombres que persiste a lo largo de los turnos. Herramientas, objetos de ámbito y resultados previos residen en ese espacio de nombres. El agente lee las observaciones (salida estándar, valores de retorno, errores) y luego escribe más código. El mismo bucle de observar-actuar que ejecuta Tool Calling también ejecuta MemEx; solo el espacio de acción cambia.

Integración "drop-in" para Tool Calling

Las herramientas de Tool Calling existentes se inyectan automáticamente como funciones de Python, incluyendo esquemas de parámetros y metadatos de tipo de retorno. Cambiar un agente existente de Tool Calling a MemEx es un único cambio de configuración.

Ejecución agnóstica del backend

El mismo código de agente se ejecuta en tres backends, seleccionados en el momento de la configuración:

• En proceso para una iteración rápida durante la investigación.
• Subproceso para aislamiento durante la evaluación.
• Pool para generación de lotes de alto rendimiento (datos de entrenamiento, despliegues a gran escala).

Para despliegues de producción, el kernel puede ser reemplazado por un sandbox alojado como Managed Agents de Anthropic. El mismo código de agente, con aislamiento del sistema de archivos, controles de salida de red y límites de recursos gestionados por el host.

¿Qué sigue?

MemEx está llegando a manos de sus agentes. Lo estamos implementando en los agentes de primera parte de Databricks y en Agent Bricks: si hoy construye sobre agentes de Databricks, pronto podrá usar MemEx.

Estamos post-entrenando nuestros modelos para el espacio de acción de MemEx. MemEx es el sustrato: genera datos sintéticos, ejecuta verificadores agénticos y alimenta el bucle de entrenamiento.

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

---

¹ En MemEx, las llamadas a herramientas son bloques de código Python que pueden tener análisis de datos u otras herramientas llamadas como funciones asíncronas.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original