El matter es el benchmark

Que revelan 425 runs de workflow y 6,685 outputs completos de herramientas sobre ejecucion AI-native de M&A en una transaccion real

Una transaccion no avanza porque un abogado recibe una buena respuesta de IA.

Avanza cuando cientos de pequenas piezas de contexto del matter se convierten en work product revisado en el momento correcto: un markup antes de una llamada con el cliente, una lista de anexos antes de firma, un paquete de leases antes de cierre, una adenda final antes de que bloquee el closing.

Por eso los benchmarks aislados de IA legal capturan solo parte de la pregunta. Pueden medir si un agente completa una tarea. Un matter de M&A vivo mide si los agentes ayudan a mover el deal.

Analizamos la traza operativa de una transaccion espanola de M&A soportada por Firmwork. La traza publica incluye:

• 1,619 emails y comunicaciones del matter;
• 99 hilos formales de email;
• 121 adjuntos del matter;
• 425 runs de workflow vinculados al proyecto durante una ventana de matter de aproximadamente ocho semanas;
• 6,685 outputs completos de herramientas en la base de datos refrescada, alineados con el parser normalizado de 6,648 llamadas;
• 755 change sets del periodo vivo;
• 2,402 archivos de workspace;
• 5,760 eventos de workspace;
• outputs documentales agrupados en 41 paquetes entregados.

El resultado no fue una historia de "la IA redacto un SPA". Firmwork apoyo trabajo en SPA, APA, leases, firma, cierre, anexos, side letters, libros corporativos, investigacion, revision VDR/DD y adendas finales.

Mas importante: la traza permite medir algo mas cercano a leverage operativo: con que frecuencia las peticiones se convirtieron en work product, donde se concentro el trabajo, que artefactos se produjeron, cuanto sobrevivio la revision y donde el sistema todavia fallo.

La unidad de analisis no es el prompt. Es el matter.

En este articulo, un paquete entregado significa un cluster de uno o mas outputs documentales devueltos juntos en respuesta a una peticion practica del matter. Un paquete puede ser un markup de SPA, una agenda de cierre, un paquete de revision de leases o un conjunto de documentos de cesion entregados como una unidad de work product. Usamos paquetes porque el trabajo de M&A suele entregarse en bundles, y contar archivos individuales puede inflar el volumen.

Por que M&A es dificil para agentes

El trabajo de M&A no es una tarea documental larga. Es un sistema en movimiento.

En cualquier punto de una transaccion, el contexto relevante puede vivir en:

• un markup de SPA;
• un email de abogados de contraparte;
• un anexo en Excel;
• una instruccion informal del equipo legal;
• una carpeta de materiales VDR;
• una issue list anterior;
• una instruccion del cliente de hace tres dias;
• una agenda de cierre que cambio dos veces desde ayer.

La dificultad no es solo razonar sobre documentos largos. Es saber que importa ahora.

Hay otro problema aun mas importante en la practica: llevar los issues hacia adelante. Un riesgo identificado en diligence puede reaparecer en el SPA, despues en un side letter, despues en una condicion de cierre y despues en un email de ultimo minuto. Si el sistema trata cada peticion como un prompt nuevo, el issue se redescubre en vez de gestionarse. Un agente util de M&A debe recordar los puntos abiertos, entender como evolucionan y mantenerlos unidos al matter hasta que se resuelvan o se descarten deliberadamente.

Al principio del deal, el trabajo suele consistir en construir contexto: revisar materiales de diligence, entender el perimetro, identificar puntos abiertos y convertir documentos fuente en estado util del matter.

En el medio, el trabajo se vuelve coordinacion: integrar comentarios, producir markups, preparar documentos de firma, organizar anexos y traducir posiciones negociadas en work product.

Cerca del cierre, el trabajo se vuelve compresion: leases, waivers, libros corporativos, certificados, adendas, firmas, adjuntos faltantes, versiones de contraparte y correcciones factuales de ultimo minuto.

Aqui es donde un sistema de agentes a nivel matter se diferencia de una interfaz de drafting. Una interfaz de drafting empieza con un documento. Un sistema de matter empieza con el expediente, los canales, el estado y el deadline.

Dataset

Estudiamos una transaccion real a traves de cuatro capas de evidencia.

La capa de comunicacion contiene 1,619 emails y comunicaciones del matter durante la ventana viva del matter, incluyendo 99 hilos formales, 121 adjuntos y 16 prompts o instrucciones de comunicacion revisadas como contexto cualitativo. Tratamos esto como la superficie de intake del matter: peticiones, updates, follow-ups, documentos fuente y contexto factual que normalmente mueve a un equipo transaccional.

La capa de ejecucion de Firmwork contiene 425 runs de workflow vinculados al proyecto durante una ventana de matter de aproximadamente ocho semanas. La base de datos refrescada registra 6,685 outputs completos de herramientas, alineados con el parser normalizado de 6,648 llamadas, con una mediana de profundidad no-cero de 12 tool calls y un maximo observado de 110. Esto importa porque el sistema no funcionaba como un wrapper de chat. Leia, buscaba, escribia, editaba, validaba, enrutaba modelos y empaquetaba trabajo contra el matter file.

La capa del sistema-matter contiene 2,402 archivos de workspace, 1,771 documentos de proyecto, 5,760 eventos de workspace, 898 change proposals, 755 change sets y 1,392 entradas VFS. Esta es la superficie de infraestructura: no solo lo que dijo el modelo, sino lo que el sistema toco, versiono, propuso, enruto y reviso.

La capa de work product contiene outputs documentales agrupados en 41 paquetes entregados. Esta es la superficie revisable del matter: artefactos y cambios propuestos que los abogados pudieron inspeccionar, aceptar, rechazar, supersedear o usar en trabajo posterior del deal.

No es un benchmark controlado. Es una traza observacional. Eso la hace mas imperfecta, pero tambien mas util para entender trabajo legal en produccion.

Los benchmarks nos dicen si los agentes pasan tareas. Las trazas de matters nos dicen si los agentes encajan en como ocurre realmente el trabajo legal.

Metodo

No contamos cada respuesta del modelo como valor.

Reconstruimos el matter alrededor de ocho metricas operativas.

1. Traza del sistema-matter.

Medimos la superficie operativa: workflow runs, outputs completos de herramientas, archivos de workspace, eventos, ramas VFS, propuestas de cambio y change sets.

1. Profundidad de ejecucion.

Medimos tool calls por run para distinguir chat superficial de trabajo multi-step sobre archivos, documentos, emails y validacion.

1. Routing de modelos.

Agrupamos filas del ledger de uso de IA por episodio transaccional y tier de modelo para ver que trabajo requirio modelos frontier, que trabajo uso modelos frontier-standard y que trabajo se desplazo hacia modelos rapidos, de menor coste o alternativos.

El export actual registra uso observado, coste y volumen de tokens. No distingue de forma auditada seleccion por auto-router frente a seleccion directa, asi que tratamos el routing como economia observada del model mix, no como atribucion auditada de politica.

1. Presion por fase y factory.

Dividimos el matter en fases y medimos runs, outputs completos, change sets, versiones de workspace y coste IA por fase.

1. Conversion request-to-artifact.

Agrupamos outputs documentales en paquetes entregados y los conectamos con senales previas de peticion en las comunicaciones del matter. Un paquete entregado es la unidad transaccional de work product: una devolucion coherente al equipo legal, contenga uno o varios archivos.

El ledger de paquetes es un proxy de trazabilidad, no prueba causal. Pero permite auditar el matter al nivel que viven los abogados: peticion, episodio de trabajo, artefacto revisado, entrega.

1. Cobertura por workstream.

Clasificamos paquetes entregados y etiquetas de runs en SPA, APA, leases, firma, cierre, anexos, libros corporativos, side letters y workstreams relacionados.

1. Review survival.

Medimos si los change sets de Firmwork fueron aceptados, autoaceptados, rechazados, superseded o pendientes.

1. Medicion economica y asignacion de capital.

Medimos coste IA, uso de tokens y Return on Token contribution-adjusted para preguntar cuanto movimiento revisado del matter compro cada unidad de consumo de IA.

La pregunta era simple:

Instalo Firmwork un production loop alrededor del matter?

Resultado 1: El trabajo se concentro en firma y cierre, no solo en drafting inicial

La suposicion obvia seria que el valor de IA se concentra alrededor del primer borrador o markup de SPA.

La traza no muestra eso.

El trabajo se concentro en la parte operativa media y final del deal, donde los equipos transaccionales normalmente pelean con version drift, control de anexos, documentos de cierre, leases, cambios de contraparte y correcciones factuales.

La fase de arquitectura de firma, side letter y anexos en las semanas intermedias del matter tuvo 119 runs, 1,548 outputs completos, 164 change sets y 434 entradas VFS. La fase de pico de firma, APA y appendices sumo 83 runs y 1,335 outputs completos. La fase de leases, waivers y ejecucion de cierre en las semanas finales de closing tuvo 92 runs, 1,797 outputs completos, 278 change sets, 250 versiones de workspace y 411 entradas VFS.

Esto importa para producto. El agente de M&A mas valioso no es solo un mejor generador de first drafts. Tiene que soportar la parte media y final de una transaccion, donde muchos artefactos pequenos y cambios factuales deben converger rapido.

Resultado 2: El loop del agente tuvo profundidad real

La metrica importante no es cuanto duro un run. Es cuanto trabajo operativo ocurrio dentro del run.

En la ventana del matter, el run mediano con herramientas tuvo 12 tool calls. El p75 tuvo 28. El p90 tuvo 52. El run mas profundo observado tuvo 110 tool calls.

Ese patron es distinto a un chatbot de drafting. Muchos runs hacian trabajo de un junior transaccional: leer archivos, buscar emails, extraer hechos, escribir borradores, editar DOCX, comprobar outputs, actualizar estado y producir paquetes.

Los runs mas densos no fueron demos abstractas. Fueron tareas reales del deal: completar placeholders de leases con VDR y fuentes web, preparar un side letter desde findings de diligence, leer cuentas societarias, investigar issues de subleases, adaptar contratos de lease y construir documentos de cierre.

Un matter vivo no premia razonamiento aislado. Premia ejecucion repetible contra fuentes que cambian.

Resultado 3: El acto final importa

La base de datos refrescada cambio la forma del articulo.

El export local anterior hacia que los paquetes finales de adendas y cesiones parecieran debilmente vinculados a runs de Firmwork porque el export se quedaba antes de terminar el matter. La base viva muestra 32 workflow runs, 44 filas de uso de IA, 40 change sets, 22 change sets aceptados o autoaceptados y 670 outputs completos en los ultimos dias de cierre.

Eso no prueba causalidad para cada archivo entregado. Si muestra que la ventana de cierre siguio siendo un periodo activo de ejecucion, no una cola puramente humana despues de terminar la traza de agentes.

Resultado 4: El routing de modelos cambio con el trabajo

La traza de modelos muestra algo mas interesante que un proveedor ganando el matter.

El matter no se comporto como un benchmark de un solo modelo. Los modelos frontier cargaron trabajo de alto juicio: drafting, negociacion y revision. Los modelos mas rapidos o de menor coste ganaron peso durante ejecucion de volumen, especialmente cuando el sistema ya tenia mas estado del matter y contexto de revision.

En el ledger completado de uso de IA, una semana temprana intensiva en modelos frontier fue casi toda gasto frontier y reasoning: USD 193.13 sobre 172.5M tokens raw. Para una semana posterior de ejecucion de volumen, los modelos rapidos o de menor coste movieron 100.1M tokens raw por USD 45.48, mientras los modelos frontier manejaron 14.0M tokens raw por USD 29.32. En la semana final de cierre, el gasto frontier subio otra vez para adendas finales y trabajo de cierre de mayor juicio.

Es un analisis temprano de routing, no una politica auditada de modelos. Pero apunta a un benchmark mas importante que calidad bruta del modelo: que partes de una transaccion necesitan razonamiento frontier y que partes necesitan ejecucion fiable a escala.

Resultado 5: La closing factory fue la senal operativa mas fuerte

La parte mas impresionante de la traza es el workstream de leases de cierre y notificaciones laborales.

La comparacion es inusualmente limpia. La fase de SPA, side letter y agenda de cierre y la closing lease factory tuvieron 56 runs cada una. Pero la closing factory produjo 1,421 tool calls frente a 891, 216 change sets frente a 77 y 240 versiones de workspace frente a 119, con menor coste atribuido.

Ahi Firmwork se parece menos a un asistente de drafting y mas a una capa de ejecucion M&A. El trabajo incluyo generacion de modelos de lease, checks factuales repetidos, un paquete multi-contrato de lease, indices, cartas de notificacion laboral, agenda de cierre, discovery de subleases, reclasificacion de contratos accesorios y loops finales de correccion.

Ese patron es exactamente lo que un equipo de deal necesita cerca de cierre: muchos artefactos relacionados, hechos fuente repetidos, errores pequenos pero peligrosos y necesidad de converger rapido bajo revision.

La traza de entrega mas amplia tambien importa. Firmwork produjo outputs documentales agrupados en 41 paquetes entregados. Pero el request-linkage es una metrica de soporte. El claim publico mas fuerte es que Firmwork creo un loop repetible de ejecucion cuando el matter se volvio operacionalmente denso.

Resultado 6: Review survival fue mas fuerte en artefactos legales

El trabajo de agentes legales no debe juzgarse por si un modelo produjo texto. Debe juzgarse por si el sistema produjo work product revisable bajo control humano.

En la ventana viva del matter, la base registra 755 change sets. De ellos, 573 fueron aceptados o autoaceptados, 93 rechazados, 66 superseded y 23 quedaron pendientes. La supervivencia total fue 75.9 por ciento.

El corte mas interesante es por tipo de archivo. DOCX es la superficie central de artefacto legal: 299 de 336 change sets DOCX fueron aceptados o autoaceptados, o 89.0 por ciento.

Esto no afirma que el 89.0 por ciento del trabajo legal DOCX fuera independientemente correcto. Es una metrica de workflow: los cambios propuestos sobre artefactos legales sobrevivieron el proceso de revision de la plataforma.

En trabajo legal, esa distincion importa. El producto no es output autonomo. El producto es un loop controlado donde los agentes producen, los abogados revisan y el matter avanza.

Resultado 7: Return on Token es el medidor de asignacion de capital

Return on Token es la cantidad de work product legal ponderado por fee producido por unidad de consumo de IA. Tiene dos formas utiles:

1. Valor por dolar de IA: EUR de work product ponderado por fee por USD de coste IA.
2. Valor por token: EUR de work product ponderado por fee por 1M token-equivalent units.

La analogia financiera mas cercana es Return on Invested Capital. ROIC es util porque no pregunta solo si una compania genera beneficio. Pregunta si la siguiente unidad de capital desplegada en el sistema operativo produce suficiente retorno para justificar la inversion.

Return on Token deberia hacer lo mismo para trabajo legal agentico. La pregunta no es si un matter uso muchos tokens, ni si los tokens fueron baratos. Es si la siguiente unidad de consumo IA se convierte en work product revisable, menor carga para abogados, cierre mas rapido o mejor control del matter.

El ROT bruto es intencionalmente simple, pero es demasiado generoso como claim aislado porque atribuye todo el valor del matter a la IA. Un modelo mas conservador contribution-adjusted asigna solo una parte de valor ponderado por fee a Firmwork y mantiene visible la intervencion humana legal.

En el matter completado, el ROT bruto fue EUR 53.88 por USD de coste IA y EUR 53.34 por 1M token-equivalent units. Bajo escenarios de contribucion Firmwork del 60 por ciento, 75 por ciento y 90 por ciento, el ROT contribution-adjusted va de EUR 32.33 a EUR 48.49 por USD de coste IA, y de EUR 32.01 a EUR 48.01 por 1M token-equivalent units.

Return on Token debe entenderse como una capa de medicion economica encima del throughput del matter, no como sustituto de calidad ni de revision legal.

La metrica sigue siendo temprana. Necesita mejor atribucion run-level de tokens, asignacion mas limpia por workstream, un modelo mas fino de contribucion humana y pesos de valor ajustados por revision. Pero es direccionalmente importante porque conecta tres cosas que normalmente viven separadas: valor del matter, consumo de agentes y work product revisable.

La mejor pregunta no es "pueden los tokens producir valor legal?" Es: cuando un matter se vuelve ejecutable, cuanto work product legal mueve cada unidad de consumo IA a traves del sistema?

Para operadores, la version mas util sera el ROT marginal. Si el sistema gasta el siguiente 1M de token-equivalent units en un workstream, crea suficiente output revisado adicional para superar el hurdle rate? Mejora el razonamiento frontier la supervivencia de revision o reduce suficiente tiempo senior para justificar su coste? O deberia enrutarse el trabajo hacia modelos mas rapidos y baratos porque el estado del matter y el loop de revision ya son fuertes?

Ahi ROT deja de ser un grafico retrospectivo y se convierte en metrica de gestion. Da a un sistema legal AI-native una forma de rankear token spend por workstream, modelo y fase del deal.

Como se veia el buen trabajo de agente

Los mejores runs no fueron simples runs de drafting.

Se parecian mas al trabajo de un associate bajo presion:

• reunir contexto relevante del matter;
• inspeccionar documentos fuente;
• producir un borrador o markup;
• validar contra el record;
• revisar despues de checks;
• empaquetar el artefacto;
• devolverlo por el canal donde ya estaba trabajando el equipo legal.

El patron de alto valor en este matter no fue "un prompt, una respuesta". Fue un loop de herramientas alrededor del matter file.

La leccion de producto es clara: Firmwork debe hacer explicito el loop.

Failure modes

La traza tambien muestra donde el sistema no fue suficientemente bueno.

Los problemas principales no fueron inteligencia abstracta de modelos. Fueron problemas de workflow y sistema documental: fidelidad DOCX y de markup, resolucion de latest version, completitud de anexos y carpetas, plumbing de entrega de adjuntos, source provenance, visibilidad VFS y atribucion audit-grade de spend.

En M&A, eso no es periferico. Es el trabajo.

Si el agente redacta bien pero se usa la version equivocada, el matter no avanza. Si la lista de anexos esta incompleta, el equipo no puede apoyarse en ella. Si un documento existe en workspace pero no llega al hilo de email, la entrega fallo.

Por eso el matter operating system importa tanto como el modelo.

Lo que cambia

La primera generacion de IA legal se organizo alrededor de asistencia: preguntar, resumir, redactar una clausula.

M&A necesita otra cosa: un sistema donde el matter file sea persistente, los canales alimenten episodios de trabajo estructurados, los agentes operen contra estado del matter, el work product sea versionado y revisable, los outputs vuelvan por workflows legales existentes y toda la traza pueda medirse.

La tesis central de Firmwork es esta:

Los agentes de M&A necesitan un matter operating system, no solo una interfaz de drafting.

Lo que viene

El siguiente paso no es solo otro research post. Es una mejor capa de aplicacion de M&A encima de agentes.

La capa de modelos mejorara. Ventanas de contexto mas grandes, mejor razonamiento, inference mas barata y modelos especializados mas fuertes ayudaran. Pero esta traza de matter sugiere que mucho leverage restante esta encima del modelo, en algoritmos y primitivas de producto que hacen utiles a los agentes dentro de una transaccion.

La primera primitiva es issue tracking. El trabajo de M&A depende de llevar issues hacia adelante: identificarlos, asignarlos a workstreams, conectarlos con documentos, notar cuando nueva evidencia los cambia y asegurarse de que reaparezcan cuando el equipo legal debe actuar. Un agente de matter no deberia solo contestar una pregunta sobre un issue. Debe mantenerlo vivo hasta cierre.

La segunda primitiva es memoria de matter. El sistema necesita un matter graph persistente: partes, documentos, clausulas, fechas, open points, materiales fuente, work product, decisiones y preguntas no resueltas. Ese graph debe alimentar retrieval, drafting, validation y review.

La tercera primitiva es routing. Distintas partes de un deal requieren comportamiento distinto. Diligence review no es SPA markup. Organizacion de anexos no es adaptacion de leases. Ejecucion de cierre no es investigacion legal. La traza ya muestra por que esto importa: modelos frontier cargaron mas trabajo de alto juicio, mientras la closing factory pudo mover mas volumen por modelos rapidos de menor coste cuando existian estado del matter y review loop.

La capa de routing tambien deberia tener un objetivo economico: maximizar el Return on Token marginal sujeto a review survival y riesgo legal. Eso significa que routing no es solo un problema de seleccion de modelo. Es asignacion de capital de compute dentro de un matter.

La cuarta primitiva es provenance. Cada output material debe llevar linaje de fuente: que documentos, comunicaciones, estado previo y supuestos lo sustentan. Sin provenance, el abogado tiene que reauditarlos manualmente.

La quinta primitiva es review memory. El sistema debe aprender de cambios aceptados, rechazados y superseded. La revision no debe ser solo un estado terminal de UI. Debe convertirse en senal para el matter y para la forma de trabajar de la firma.

Esa es la direccion de producto: no agentes en vez de workflow de M&A, sino agentes dentro de una capa operativa de M&A.

Notas de metodo

Es una traza observacional de un matter vivo, no un benchmark aleatorizado.

El matching request-to-delivery es un proxy de trazabilidad, no prueba de que cada run causara cada artefacto entregado.

Review survival es una metrica de workflow, no una puntuacion independiente de correccion legal.

El ledger actual distingue gasto completado de intentos fallidos o cancelados; la economia debe leerse como direccional hasta auditar por completo la asignacion run-level.

Conclusion

El matter es el benchmark.

En esta transaccion, Firmwork no se uso solo para producir documentos aislados. Opero dentro de un matter real de M&A: 1,619 emails y comunicaciones, 425 workflow runs, 6,685 outputs completos de herramientas, 2,402 archivos de workspace, 5,760 eventos de workspace, 41 paquetes entregados y 755 change sets.

La evidencia sugiere una nueva forma de medir agentes legales en trabajo transaccional.

No empieces con token ROI como metrica vanity. Empieza con movimiento del matter, y despues mide si cada unidad adicional de consumo IA se convierte en work product revisado con un Return on Token atractivo.

Puede el sistema convertir contexto disperso en work product revisado? Puede hacerlo a traves de workstreams? Puede sobrevivir presion de cierre? Pueden controlarlo los abogados? Puede medirse la traza?

Si si, el valor no es solo drafting mas rapido.

El valor es capacidad de ejecucion instalada.