DELEGATE-52: por qué los LLMs frontera corrompen 25% de tu trabajo en cadenas largas, y qué hace falta para resolverlo

Si alguna vez le pediste a un asistente IA que ejecute una secuencia larga de ediciones sobre un documento y observaste cómo el daño silencioso se acumulaba en su output — una cláusula borrada acá, un coeficiente numérico equivocado allá, una firma de función sutilmente reescrita que recién notaste dos iteraciones después — ya tenés intuición de lo que Microsoft Research acaba de medir a escala. DELEGATE-52, publicado el 11 de mayo de 2026 por Philippe Laban, Tobias Schnabel y Jennifer Neville, sometió a 19 LLMs frontera a simulaciones de ida y vuelta (round-trip relay) en 52 dominios profesionales. Los modelos frontera corrompieron en promedio 25% del contenido del documento sobre 20 interacciones delegadas. Agregar uso agéntico de herramientas empeoró el problema, no lo mejoró. Solo Python programming superó el umbral del 98% de fiabilidad en todos los modelos evaluados. Este es el post que hay que leer antes de delegar cualquier workflow de horizonte largo a un agente autónomo.

Qué mide DELEGATE-52 en realidad

La premisa es engañosamente simple. Tomá un documento real de un dominio profesional — un archivo Python, un CIF de cristalografía, un archivo de notación musical, un libro contable, un guion de cine. Pedile al LLM que ejecute una edición estructural. Después pedile a una segunda llamada al LLM que revierta esa edición. Si el modelo es fiel, el output del round trip debería coincidir con el input. Componé múltiples de estos round trips y obtenés un workflow delegado que simula lo que pasa cuando un usuario terceriza una secuencia de ediciones a un agente y confía en que el agente mantenga el documento intacto.

Formalmente, el benchmark define un round trip como un par de instrucciones (σ, σ⁻¹). La instrucción forward mapea el documento semilla s a un estado intermedio t = LLM(s; σ). La instrucción backward intenta la inversa: ŝ = LLM(t; σ⁻¹). Múltiples round trips componen secuencialmente. El experimento principal usa N=10 round trips consecutivos — 20 interacciones LLM en total — con scheduling round-robin de tareas.

El Reconstruction Score es la métrica titular:

// RS@k = similitud entre el documento semilla s
// y la reconstrucción ŝ después de k interacciones LLM
// (k/2 round trips), medida con función de similitud específica por dominio

RS@k(s) = sim(s, ŝ_{k/2})

// Las funciones sim() específicas por dominio contemplan:
// - Equivalencia de AST (Python, Docker, JSON, DNS)
// - Tolerancia numérica (cristalografía, contabilidad, weather)
// - Equivalencia estructural (notación musical, screenplay, vector graphics)
// - Diff a nivel token con pesado semántico (ficción, emails, recetas)

Un score de 1.0 significa que el round trip fue sin pérdidas. Un score de 0.5 significa que aproximadamente la mitad del contenido del documento no sobrevivió las 20 interacciones. El equipo define readiness para un dominio como RS@20 ≥ 98%. El razonamiento: cualquier cosa por debajo de "casi sin pérdidas" es inseguro para delegación sin supervisión. Un 90% sobre una planilla financiera significa que uno de cada diez números está mal, lo cual es peor que no delegar.

Los 52 dominios

La selección de dominios fue la decisión más subestimada del paper. La mayoría de los benchmarks agénticos están dominados por software engineering, math, y una rebanada delgada de workflows de negocio. DELEGATE-52 cubrió deliberadamente el trabajo tal como existe en el mercado laboral, sobre cinco categorías:

Ciencia & Ingeniería (11 dominios): Circuit, Quantum, Robotics, Molecule, Star Catalog, Crystallography, Math Lean, Satellite, Weather, Aviation, Protein. Dominios donde los outputs están parcialmente estructurados (a menudo un formato custom como CIF o PDB) y donde un solo coeficiente corrompido invalida el artifact entero.

Código & Configuración (11 dominios): Python, Malware, Docker, Makefile, Database Schema, Infrastructure, Filesystem, JSON, Translation, DNS, Graphviz. Los dominios donde los modelos frontera actuales son más fuertes, en parte porque los datos de entrenamiento son densos y en parte porque los verificadores (parsers, compiladores, linters) entregan señal de reward implícita durante el fine-tuning.

Creativo & Media (11 dominios): Screenplay, Fiction, Font Engineering, Vector, Music, Slides, Subtitles, Weaving, LaTeX, Audio Synthesis, 3D Objects. Formatos estructurados con contenido semántico donde cambios superficiales pueden romper el artifact subyacente (un archivo de notación musical con un sostenido intercambiado, un archivo vectorial con un comando de path mal escrito).

Registros Estructurados (10 dominios): Library Catalog, Emails, Ham Radio, Treebank, EDIFACT, Geodata, Geotracking, Calendar, Accounting, Genealogy. Datos tabulares y de grafo donde las restricciones de integridad son externas — foreign keys, formatos RFC bien formados, timestamps con timezone correcto.

Cotidiano (9 dominios): Chess, Transit, Food Menu, Recipe, Landmarks, Earnings, Job Board, Playlist, Spreadsheet. Los dominios que un usuario no técnico es más probable que delegue a un asistente. También los dominios donde es menos probable que los usuarios noten cuando algo se rompió silenciosamente.

El dataset completo contiene 310 entornos de trabajo sobre los 52 dominios, cada entorno con documentos reales que promedian alrededor de 15K tokens, con cinco a diez tareas de edición por entorno que simulan el tipo de pedidos que un profesional real haría. No son datos sintéticos diseñados para romper modelos. Es el trabajo mismo.

Los números

Diecinueve LLMs fueron evaluados sobre seis familias: OpenAI, Anthropic, Google, Mistral, xAI y Moonshot. Los promedios titulares sobre 20 interacciones:

Reconstruction Score final (RS@20), modelos frontera:
  Gemini 3.1 Pro       80.9%
  Claude 4.6 Opus      73.1%
  GPT 5.4              71.5%

Promedio sobre los 19 modelos:
  RS@20                ~50%   // medio documento desaparecido

Economía de tokens en modo agéntico (con herramientas):
  Tokens input         2.1x – 4.6x   // vs chat-only
  Tokens output        0.6x – 1.2x   // menos
  Efecto neto          ~6% degradación adicional

Tres hallazgos merecen leerse juntos.

Solo un dominio superó el umbral de readiness. Python programming: 17 de 19 modelos lograron RS@20 ≥ 98%. El mejor modelo global, Gemini 3.1 Pro, fue ready en solo 11 de 52 dominios. La corrupción catastrófica — definida como RS@20 ≤ 80% — ocurrió en más del 80% de las combinaciones modelo-dominio.

El uso agéntico de herramientas empeoró las cosas. Los cuatro modelos probados con un harness agéntico multi-turn — acceso a archivos, shell, ejecución de código — degradaron 6% más en promedio que los mismos modelos en modo chat-only. La intuición de que darle al modelo más affordances debería ayudar en tareas de horizonte largo resultó equivocada en este benchmark. Dos mecanismos manejaron la regresión: las tool calls inflan el consumo de tokens input dos a cinco veces (lo cual de por sí empeora la fidelidad de contexto largo), y los modelos prefirieron escribir archivos en lugar de usar ejecución de código para verificar, así que la superficie de herramientas agregó overhead sin ejercitar su affordance más fuerte.

El patrón de falla no es gradual. Los errores se agruparon. Los modelos no perdían 5% del documento por round trip; mantenían el documento casi intacto durante varios rounds y después caían 10-30 puntos porcentuales en una sola interacción. Los modelos más débiles tendieron a fallar por borrado — secciones desaparecían directamente. Los modelos frontera tendieron a fallar por corrupción — el contenido permanecía plausible, mantenía su forma superficial, pero ya no era correcto. El modo de falla de los modelos frontera es más difícil de detectar con heurísticas baratas como longitud o validación de schema.

La paradoja agéntica, explicada

El resultado de que los harnesses agénticos degraden en lugar de mejorar el rendimiento contradice un año entero de material de marketing y merece un desglose cuidadoso.

Tres razones estructurales emergieron del paper.

Inflado de contexto. Cada tool call agrega tokens. Definiciones de herramientas, argumentos, resultados, contenidos intermedios de archivos, trazas de error — todo fluye a través de la misma ventana de contexto que el modelo está usando para razonar sobre la tarea. Para la interacción 20, una corrida agéntica puede haber consumido 3-5x más tokens de contexto que una corrida chat-only sobre la misma tarea. El rendimiento en contexto largo degrada de forma no lineal: duplicar el input no duplica la tasa de error; puede quintuplicarla. El harness agéntico estaba pagando por las herramientas quemando el presupuesto de contexto largo.

Sesgo de selección de herramientas hacia escribir en lugar de verificar. Los modelos con acceso a shell y ejecución de código abrumadoramente usaron esas herramientas para commit cambios en lugar de para chequearlos. Dada la opción entre correr un parser sobre el output previo para verificar integridad de schema y sobrescribir el archivo con una nueva versión, los modelos eligieron sobrescribir. La capacidad agéntica más valiosa — cerrar el loop sobre su propio output con un verificador determinista — fue la que los modelos usaron menos.

Conflación de acción latente. Un paso de razonamiento textual y una tool call son dos superficies diferentes, pero el modelo las trata como composicionales. Cuando la tarea requiere razonamiento intermedio cuidadoso (lo cual describe la mayoría de la edición de documentos no trivial), empujar el razonamiento dentro de los argumentos de la tool call lo trunca. El modelo gasta su presupuesto de razonamiento formulando la llamada en lugar de pensar en la edición.

Nada de esto es un veredicto sobre sistemas agénticos en general. DELEGATE-52 mide un eje específico — fidelidad de round trip sobre edición de documentos — y el harness agéntico ofrecido fue deliberadamente básico. Pero es un veredicto sobre la suposición prevaleciente de que "más herramientas siempre es mejor". Para workflows de horizonte largo sobre documentos, la tool call marginal tiene que pagar por el costo de contexto largo que impone, y la mayoría de las tool calls marginales no lo pagan.

Modos de falla que tenés que poder reconocer

El análisis cualitativo del paper (Apéndice F.2) cataloga patrones de falla que cualquier practitioner corriendo workflows largos debería aprender a detectar.

Borrado silencioso. La falla más común en modelos más débiles. Una sección, fila de tabla o ítem de lista desaparece entre rounds sin reconocimiento alguno. Frecuentemente confinada a estructuras subordinadas — footnotes, comentarios, campos opcionales.

Corrección alucinada. El modelo "arregla" contenido que estaba correcto. Un string SMILES válido es reescrito como otro string SMILES válido pero para una molécula distinta. Una jugada de ajedrez correcta se reemplaza por otra jugada legal pero no relacionada. El output luce estructurado; solo un chequeo específico de dominio lo agarra.

Drift-luego-colapso. RS@k se mantiene por encima del 95% durante los rounds 1-6, cae a 70% en el round 7, después se estabiliza en el nuevo nivel más bajo. El modelo encuentra un punto fijo degenerado y hace round-trip entre él y sí mismo. Una vez que cruza el acantilado, los rounds adicionales no recuperan.

Reformateo como ataque contra sí mismo. El modelo "mejora" el formateo del documento entre rounds — convirtiendo tabs a espacios, normalizando comillas, ordenando claves alfabéticamente. Los evaluadores específicos de dominio cuentan estos como cambios sustantivos cuando rompen parsers downstream (Makefiles, EDIFACT, ciertos dialectos de CIF).

Filtración cross-dominio. En modo agéntico específicamente, el modelo ocasionalmente arrastró patrones de una tool call al documento de otra. Las claves de un JSON previo aparecieron en las stage directions de un screenplay posterior. Este patrón fue raro pero inequívoco.

Qué haría falta para arreglar esto

La respuesta honesta es que ninguna técnica individual resuelve el problema de delegación de horizonte largo. Cerrar la brecha hacia el 100% de autonomía es un stack de mitigaciones, cada una atacando una superficie de falla distinta. Acá está el inventario de técnicas hacia el que el campo está convergiendo, aproximadamente en el orden en que un equipo de ingeniería debería adoptarlas.

1. Outputs estructurados y round trips validados por schema

La victoria más barata. Si el artifact tiene un schema parseable — JSON Schema, Protobuf, AST, SMILES, CIF — envolvé cada output del modelo en un validador y rechazá cualquier output que falle. El validador es determinista, barato, y agarra la clase entera de "ataques de reformateo". No agarra corrupción semántica, pero elimina la superficie de falla sintáctica entera. Frameworks como Instructor, Outlines, y la API de structured outputs de OpenAI existen exactamente para esto.

2. Sub-agentes verificadores independientes

Corré un segundo modelo, más chico, cuyo único trabajo es comparar el output del round n con el input del round n-1 bajo un prompt de verificación. Si el verificador marca el round, o reintentás (con el output fallido incluido como contraejemplo) o escalás a un humano. El verificador no es la misma instancia que produjo el output; idealmente es una familia de modelo completamente distinta para reducir fallos correlacionados. Es el equivalente del review "two-pass" en workflows humanos y consistentemente compra 10-20 puntos RS@20 en experimentos internos en LLM4Agents.

3. State checkpointing con hashes criptográficos de contenido

Hasheá cada artifact intermedio (SHA-256 del contenido canonicalizado). Mantené la cadena de hashes al lado del documento. Si un round downstream produce contenido cuyo diff contra la cadena es estructuralmente implausible — por ejemplo edita regiones fuera del scope intencionado de la instrucción del round — rechazá el round y hacé rollback al último hash válido. Esto convierte "borrado silencioso" en una alarma determinista. También produce un audit log que un validador ERC-8004 puede atestiguar después (ver nuestro post de ERC-8004).

4. Ventanas de contexto deslizantes y rotativas

Si el contexto largo es el driver primario de degradación, no pretendas que el modelo tiene memoria larga. Rotá resúmenes explícitos de rounds previos a través de una ventana de tamaño fijo, evictá historias crudas de tool calls agresivamente, y mantené el documento mismo como el estado canónico — nunca como una historia larga de ediciones que el modelo tenga que reproducir mentalmente. Es la misma idea detrás de Graphiti y Mem0: resúmenes cortos, densos y recuperables le ganan a la cronología cruda en todos los benchmarks de horizonte largo que vimos.

5. Anclaje en grafos de conocimiento externos

Para dominios con conjuntos de entidades estables — proteínas, líneas de cuenta contables, personajes de un guion, tonalidades musicales — bindeá las referencias del documento a un grafo externo (o un store estructurado) y exigí que cada round reconcilie contra ese grafo antes del commit. El modelo se vuelve responsable de transformaciones sobre los nodos del grafo, no de mantener cada entidad correcta en texto libre. El grafo de conocimiento bi-temporal de Graphiti es una implementación grado producción; una tabla Postgres con un foreign-key constraint es otra. Ambas funcionan porque le sacan la carga de integridad al modelo.

6. Process reward models y supervisión de procesos

La mayoría de los modelos frontera están entrenados con supervisión de outcome: el reward es sobre la respuesta final. Los process reward models puntúan cada paso intermedio y recompensan la trayectoria, no solo el destino. La línea de trabajo "Let's Verify Step by Step" de OpenAI y los resultados recientes de process-RLHF de Anthropic muestran que los modelos supervisados a nivel proceso exhiben razonamiento de horizonte largo sustancialmente mejor. La trampa es que la supervisión de procesos es cara de etiquetar y benchmarkear, por eso permanece sub-deployada. DELEGATE-52 es exactamente el tipo de benchmark que debería usarse para fine-tunear contra rewards de nivel proceso.

7. Planificadores conscientes del costo de herramientas

La regresión en modo agéntico es en parte una falla de planificación: el modelo no contempla el costo de contexto largo de cada tool call al decidir hacerla. Una capa de planner que presupueste tool calls contra tokens de contexto, y que explícitamente compense "usar la herramienta" contra "hacer el razonamiento inline", recupera la mayor parte de la brecha. Es la misma idea que scheduling consciente de recursos en sistemas operativos aplicada al contexto.

8. Self-consistency con sampling adversarial

Corré el mismo round trip tres veces con seeds de sampling diferentes. Si dos de las tres coinciden, commiteá; si discrepan, escalá. Self-consistency está bien estudiada para math y code; los datos de DELEGATE-52 sugieren que generaliza también a edición de documentos, aunque a 3-5x el costo. Combinalo con validación de structured output para rechazo más barato de samples claramente rotos.

9. Validation registries y attestations

Para agentes cuyos outputs son consumidos por otros agentes — el substrate hacia el cual el deAI stack está construyendo — registrá los resultados de validación a un registry como ERC-8004 para que los consumidores downstream puedan filtrar por track record atestiguado en lugar de por reputación sola. El agente que tiene 5,000 round trips on-chain a RS@20 ≥ 95% bajo validadores independientes es contratable para workflows largos. El agente que tiene 50 round trips con dos attestations de corrupción no lo es. Esto empuja el problema de la falla de "confiar en la plataforma" a "consultar la cadena".

10. Human-in-the-loop con condiciones de parada calibradas

La técnica que nadie quiere poner en el slide pero que todo equipo en producción usa. Después de cada k rounds (calibrado por dominio), devolvé el control a un humano. La ingeniería interesante está en elegir k a partir de los datos — dominios con curvas de falla en forma de acantilado quieren k chicos; dominios que degradan suavemente quieren k más grandes con parada estadística. Las curvas RS@k por dominio de DELEGATE-52 son exactamente el input que un calibrador de stop-condition quiere.

Qué requeriría 100% de autonomía en serio

La reflexión honesta al cierre de este paper es que no estamos cerca de agentes autónomos que puedan ejecutar cualquier workflow de 20 pasos sin supervisión. Estamos cerca de agentes autónomos que pueden ejecutar workflows específicos de 20 pasos en dominios específicos con safeguards específicos. El camino de ahí a autonomía general no es un único breakthrough algorítmico; es la acumulación lenta de las técnicas de arriba en compuestos que recompran los puntos porcentuales perdidos.

Tres shifts estructurales tienen que ocurrir antes de que el campo pueda hablar en serio de sacar al humano de la delegación de horizonte largo.

La memoria tiene que graduarse más allá de la ventana de contexto. La curva de degradación de contexto largo es un hecho de hardware, no una falla de prompting. Hasta que un substrate de memoria de trabajo — grafos externos, stores episódicos, resúmenes recuperables — se siente debajo de cada workflow largo, los modelos van a seguir pagando el impuesto de contexto largo y van a seguir perdiendo fidelidad contra él. Las arquitecturas estilo Titans, los memory operating systems estilo MemOS, y los stores anclados en grafos como Graphiti son la forma temprana de ese substrate.

La verificación tiene que ser más barata que la generación. Si verificar un output cuesta más que producirlo, nadie corre el verificador a escala. El punto entero de structured outputs, schema validators, y round-trip checks basados en parser es que la verificación es dos a tres órdenes de magnitud más barata que la generación. Las pruebas zkML y las attestations TEE empujan la verificación más allá: un tercero puede confirmar el reclamo de un agente sin re-ejecutar el trabajo. La Validation Registry de ERC-8004 es la expresión on-chain de este principio.

El process reward tiene que desplazar al outcome reward en el entrenamiento. Los modelos frontera todavía están optimizados para la respuesta final correcta. Mientras la función de pérdida no penalice trayectorias que parecen correctas pero drifteen, los modelos van a seguir produciendo trayectorias que parecen correctas pero drifteen. El patrón de corrupción de DELEGATE-52 — silencioso, plausible, en forma de acantilado — es exactamente lo que el entrenamiento con supervisión de outcome recompensa: el modelo que acierta la respuesta 18 de 20 veces luce genial en benchmarks aunque las interacciones 19 y 20 rompan el documento silenciosamente.

Dónde aterriza esto en LLM4Agents

Leemos DELEGATE-52 como realidad de ingeniería, no como desánimo. La mayoría de las técnicas de arriba — outputs validados por schema, sub-agentes verificadores independientes, state checkpointing, contexto deslizante, anclaje en grafos, validation attestations — ya están en el roadmap de LLM4Agents o en producción. El benchmark nos da un sistema de coordenadas para medirlas.

Los próximos pasos concretos que tomamos en respuesta al paper:

DELEGATE-52 como CI check para Agent Gen. Cada agente generado por Agent Gen va a correr un subset relevante de DELEGATE-52 sobre su dominio como parte de su release validation. Un agente que no logre cruzar 95% RS@20 en su dominio declarado va a shippear con un warning; un agente que no logre cruzar 80% no shippea sin override explícito. El threshold es conservador porque la corrupción es silenciosa.

Verificadores de structured-output como default en el SDK. El SDK shippea un wrapper que, para cualquier herramienta cuyo schema de output esté declarado, corre el validador de round trip sobre cada llamada al modelo. Apagalo si sabés lo que estás haciendo. Encendido por default porque el costo es despreciable y el upside es grande.

Recibos de validación ERC-8004 sobre RS@k. Los agentes registrados a través de Agent Gen postean sus resultados RS@k como validation attestations en la Validation Registry de ERC-8004. Esto hace visible la fidelidad de horizonte largo para las contrapartes antes de contratar al agente, que es el único mecanismo durable que conocemos para empujar al campo hacia mejor comportamiento en contexto largo. Si tu benchmark está on-chain, tu incentivo es optimizar contra él.

Loops de verificador aislados en microVM. El sub-agente verificador independiente corre en una microVM Firecracker separada, sin estado compartido, sin egress de red, y con un timeout duro (escribimos sobre microVM sandboxes hace dos semanas). El fallo correlacionado entre el modelo productor y el modelo verificador es el riesgo principal de este diseño; correrlos en sandboxes aisladas con familias de modelo distintas y prompts adversariales es la forma más barata de descorrelacionarlos.

Cierre

Lo más importante que hizo DELEGATE-52 fue darle al campo un benchmark que no se avergüenza de sí mismo. La tasa de corrupción de modelos frontera no es una curiosidad — es el hecho que carga peso y explica por qué las demos de agentes de larga duración fallan en producción, por qué los workflows autónomos cara al cliente no llegaron todavía, y por qué cada equipo de agentes en producción ha convergido silenciosamente sobre el mismo puñado de mitigaciones.

El contenido técnico del paper es más denso de lo que este resumen puede capturar; el PDF completo (arXiv:2604.15597) y el código público del benchmark (microsoft/DELEGATE52) merecen una lectura cuidadosa. Si estás diseñando un sistema que eventualmente va a delegar un workflow de 20 pasos a un modelo, ambos pertenecen a tu escritorio esta semana.

La autonomía no es un switch. Es una asíntota. DELEGATE-52 cuantifica qué tan lejos estamos de ella. El trabajo interesante de los próximos dos años está en el stack de mitigaciones que cierran la brecha una técnica a la vez — y en la infraestructura de validación que hace visible ese cierre a las contrapartes que tienen que confiar en el resultado.