Legora ejecuta 2000 pruebas paralelas de su agente jurídico en sandboxes de Modal

Probar un asistente de chat es sencillo: haces una pregunta, recibes una respuesta y la comparas con la de referencia. Con un agente que pasa varias horas rebuscando entre miles de documentos, editando archivos y consultando bases de datos, eso no funciona. La plataforma jurídica Legora se topó con este problema a principios de 2026. Sustituyó su asistente por un agente completo y reconstruyó desde cero su sistema de evaluación.

Por qué el portátil ya no basta

Las antiguas evals estaban pensadas para tareas pequeñas: unos pocos documentos en el entorno y todo ejecutándose en local. El nuevo agente trabaja dentro de un proyecto realista con miles de documentos y gigabytes de datos. Un experimento típico ahora es así: 100 casos, 4 variantes de harness (la estructura que rodea al modelo y forma el agente) y 5 ejecuciones por cada una. En total, 2000 ejecuciones, y todas deben correr a la vez. El ingeniero de Legora Eirik Dræge Steen lo dice sin rodeos: 10–20 ejecuciones paralelas ya saturarían un portátil.

El segundo problema es más sutil: la fidelidad del entorno. El agente de Legora abarca todo el producto: un editor DOCX sin interfaz, instancias propias de Turbopuffer, conversión de PDF, Postgres y una base de datos de autorización, almacenamiento de blobs y sandboxes dinámicos para ejecutar código. Para medir el efecto de una migración de base de datos o de un cambio en el sandbox de código, cada ejecución necesita precisamente esa versión de toda la aplicación. Los mocks no sirven aquí.

Cómo funciona: un sandbox, una ejecución

Cada ejecución recibe su propia Modal Sandbox con una imagen y un sistema de archivos personalizados. Dentro se levanta toda la aplicación, fijada a un commit concreto. Los ingenieros lanzan los experimentos desde el portátil, pero todo el cómputo se hace en la nube. Legora comparó varios proveedores de sandboxes en la nube y eligió Modal por su escalado, su baja latencia de arranque y su soporte para entornos complejos: tanto la aplicación como la imagen son muy grandes.

Algunas técnicas que conviene recordar:

• El estado del mundo en Volumes. Las grandes colecciones de documentos están disponibles en todos los sandboxes. La instantánea incluye documentos, base de datos, permisos y blobs, de modo que las ejecuciones repetidas parten de los mismos datos y la parte común se deduplica.
• Calentamiento cada hora. La construcción de la enorme imagen frenaba al principio las ejecuciones. Ahora, una vez por hora, el pipeline construye la imagen y calienta los sandboxes, y el reinicio a un commit se reduce al delta respecto a la última construcción, en lugar de una compilación completa de la aplicación.
• Secretos. Una tarea aparte sincroniza cada hora los valores del almacén de claves con Modal Secrets. Además se usan rotación frecuente, permisos mínimos, requisitos de antigüedad de las dependencias y una lista blanca de dominios.

Capítulo aparte es el paso de gVisor a VM Sandboxes. La aplicación de Legora se compone de servicios Docker, y en gVisor había que montar rodeos: red en modo host con su propia resolución DNS y ejecución de los sandboxes de código como procesos sueltos, porque FUSE no se montaba. En una máquina virtual con un kernel de Linux real, Docker se comporta como en un host normal, y el equipo eliminó todos esos parches.

Qué aportó y dónde está la trampa

La plataforma se ha convertido en la herramienta principal para evaluar la calidad del agente. En ella se ejecuta el benchmark interno BAR, un conjunto de tareas jurídicas largas y realistas, y se comparan los modelos base por calidad, coste y latencia. De estos resultados dependen la elección del modelo en producción y el diseño del harness.

Lo más interesante es otra cosa: las evals se envolvieron en una CLI y una skill, y ahora los propios agentes crean casos, lanzan experimentos y analizan resultados. La mayoría de los ingenieros trabaja con las evals a través de agentes. Si le das a un agente una métrica, herramientas de experimentación y un presupuesto, irá ajustando el harness hasta que la métrica mejore. Así optimizó Legora la búsqueda de herramientas, la generación de PowerPoint y la reproducción de artículos científicos. Uno de los resultados es una reducción del 30 % en el coste del agente gracias a una compactación de contexto (compaction) más inteligente y a una implementación propia de la búsqueda de herramientas.

La trampa es que esto es un blog de Modal, es decir, un caso de un proveedor. No hay cifras sobre la latencia de arranque, el precio de 2000 ejecuciones ni la proporción de ejecuciones inestables. Del «30 %» no se dice en qué benchmark ni si fue sin pérdida de calidad. El enfoque en sí no está atado a una plataforma: se puede replicar en otra, si soporta imágenes pesadas y ofrece Docker de verdad.

Qué llevarse:

• Si el agente toca bases de datos, archivos y servicios externos, pruébalo en una copia completa del producto, no con mocks.
• Fija no solo el código, sino también los datos: una instantánea de documentos, permisos y estado de la BD hace comparables las ejecuciones.
• Calienta las imágenes de forma programada para que el reinicio a un commit no requiera una compilación completa.
• Lanza varias ejecuciones por caso: el agente es no determinista, y Legora usa 5.
• Envuelve las evals en una CLI para que los agentes puedan lanzar experimentos y mejorar el harness por sí mismos dentro de un presupuesto.