Rethinking Harness Evolution: Why Test-Time Scaling Still Beats Automatic Harness Design

A new paper from the Allen Institute for AI and the University of Washington arrives at an uncomfortable conclusion for the growing field of automatic harness engineering: the supposed gains of evolving agent scaffolds — prompts, tools, middleware, memory — largely vanish when compared with simple test-time scaling baselines under matched inference budgets. Across experiments on Terminal-Bench 2.1 with GPT-5.4 and Claude Opus 4.6, automatic harness evolution consistently underperforms basic parallel sampling, and evolved harnesses show near-zero generalization to held-out tasks. The findings serve as a methodological check on a field that may have been evaluating itself with a rigged yardstick.

Un nuevo paper del Allen Institute for AI y la University of Washington llega a una conclusión incómoda para el creciente campo de la ingeniería automática de harness: las supuestas ganancias de evolucionar scaffolds de agente — prompts, herramientas, middleware, memoria — desaparecen en gran medida cuando se comparan con líneas base simples de test-time scaling bajo presupuestos de inferencia equiparados. A través de experimentos en Terminal-Bench 2.1 con GPT-5.4 y Claude Opus 4.6, la evolución automática de harness rinde consistentemente peor que el muestreo paralelo básico, y los harness evolucionados muestran una generalización cercana a cero a tareas no vistas. Los hallazgos sirven como un control metodológico para un campo que puede haberse estado evaluando con una vara de medir amañada.

The Evaluation Problem

El Problema de Evaluación

Automatic harness evolution is an appealing idea. Instead of manually tuning prompts, tool definitions, and control flow for agentic tasks, you let the agent improve its own scaffold — analyzing prior trajectories, diagnosing failures, and revising the harness code. Methods like Meta-Harness, Agentic Harness Engineering (AHE), and AEVO have shown promising results on benchmarks like Terminal-Bench. But the Allen/UW team identifies a basic methodological flaw in how these results are reported: harness evolution is itself a search procedure that evaluates candidate harnesses on benchmark tasks during development, so its final performance conflates genuine harness improvement with the statistical benefit of repeated sampling. If the evolution loop gets to try K harness configurations and report the best one, it is essentially running a multi-armed bandit over harnesses — and a simple bandit that allocates the same compute budget to directly sampling multiple trajectories per task might match or exceed its performance without any harness modification at all.

La evolución automática de harness es una idea atractiva. En lugar de ajustar manualmente prompts, definiciones de herramientas y flujo de control para tareas agénticas, dejas que el agente mejore su propio scaffold — analizando trayectorias anteriores, diagnosticando fallos y revisando el código del harness. Métodos como Meta-Harness, Agentic Harness Engineering (AHE) y AEVO han mostrado resultados prometedores en benchmarks como Terminal-Bench. Pero el equipo de Allen/UW identifica un defecto metodológico básico en cómo se reportan estos resultados: la evolución de harness es en sí misma un procedimiento de búsqueda que evalúa harness candidatos en tareas de benchmark durante el desarrollo, por lo que su rendimiento final confunde la mejora genuina del harness con el beneficio estadístico del muestreo repetido. Si el bucle de evolución puede probar K configuraciones de harness e informar la mejor, está esencialmente ejecutando un bandido multi-brazo sobre harnesses — y un bandido simple que asigna el mismo presupuesto de cómputo a muestrear directamente múltiples trayectorias por tarea podría igualar o superar su rendimiento sin ninguna modificación del harness.

The second concern is overfitting. When the search tasks and the evaluation tasks are drawn from the same public benchmark, measured gains may reflect adaptation to task-specific patterns — memorizing which commands work for which Terminal-Bench scenarios — rather than genuinely better harness design that transfers to new problems. The paper formalizes both concerns into a controlled comparison protocol with four methods under a unified compute budget: parallel sampling (independent trajectories), sequential refinement (iterative trajectory revision), harness evolution (shared harness updates across tasks), and a new method called harness scaling (task-specific harness revision). All methods receive the same feedback signals and the same inference budget of K attempts per evaluation task.

La segunda preocupación es el sobreajuste. Cuando las tareas de búsqueda y las tareas de evaluación se extraen del mismo benchmark público, las ganancias medidas pueden reflejar adaptación a patrones específicos de tarea — memorizar qué comandos funcionan para qué escenarios de Terminal-Bench — en lugar de un diseño de harness genuinamente mejor que se transfiera a nuevos problemas. El paper formaliza ambas preocupaciones en un protocolo de comparación controlada con cuatro métodos bajo un presupuesto de cómputo unificado: muestreo paralelo (trayectorias independientes), refinamiento secuencial (revisión iterativa de trayectorias), evolución de harness (actualizaciones de harness compartidas entre tareas) y un nuevo método llamado escalado de harness (revisión de harness específica por tarea). Todos los métodos reciben las mismas señales de retroalimentación y el mismo presupuesto de inferencia de K intentos por tarea de evaluación.

Without Unit Tests: Harness Evolution Actively Hurts Performance

Sin Pruebas Unitarias: La Evolución de Harness Activamente Perjudica el Rendimiento

In the setting where no unit test cases are available — the agent must rely on its own judgment to evaluate and revise its outputs — the results are stark. Direct sampling from the initial harness achieves a 68.2% average across Claude Opus 4.6, GPT-5.4, and GPT-5.4 mini. Parallel sampling (taking the best of K=5 independent trajectories via self-selection) lifts this to 72.3%. Sequential refinement (iteratively revising the previous trajectory) manages 69.3%. Harness evolution — which attempts to improve the shared harness across rounds — actually degrades performance to 67.4%, below the direct sampling baseline. Harness scaling, which adapts the harness per instance, reaches 71.8%, competitive with parallel sampling but no better.

En el escenario donde no hay casos de prueba unitaria disponibles — el agente debe confiar en su propio juicio para evaluar y revisar sus salidas — los resultados son contundentes. El muestreo directo desde el harness inicial logra un 68.2% de promedio en Claude Opus 4.6, GPT-5.4 y GPT-5.4 mini. El muestreo paralelo (tomando la mejor de K=5 trayectorias independientes vía autoselección) eleva esto a 72.3%. El refinamiento secuencial (revisando iterativamente la trayectoria anterior) alcanza 69.3%. La evolución de harness — que intenta mejorar el harness compartido a lo largo de rondas — en realidad degrada el rendimiento a 67.4%, por debajo de la línea base de muestreo directo. El escalado de harness, que adapta el harness por instancia, alcanza 71.8%, competitivo con el muestreo paralelo pero no mejor.

The degradation on GPT-5.4 is particularly striking: direct sampling scores 75.3%, but harness evolution drops to 69.7%. Iteratively revising the shared harness based on self-generated feedback introduces noise, compounding errors rather than correcting them. The meta agent making the edits — the same underlying model — does not have reliable enough signals to determine which harness changes are improvements. Without the grounding signal of a unit test, harness revision becomes a self-deceiving process: the agent modifies its own scaffold based on its own possibly-flawed trajectory analysis, and each modification risks encoding the model’s blind spots deeper into the system.

La degradación en GPT-5.4 es particularmente llamativa: el muestreo directo puntúa 75.3%, pero la evolución de harness cae a 69.7%. Revisar iterativamente el harness compartido basándose en retroalimentación autogenerada introduce ruido, compounding errores en lugar de corregirlos. El meta-agente que hace las ediciones — el mismo modelo subyacente — no tiene señales suficientemente fiables para determinar qué cambios de harness son mejoras. Sin la señal de fundamentación de una prueba unitaria, la revisión del harness se convierte en un proceso de autoengaño: el agente modifica su propio scaffold basándose en su propio análisis posiblemente defectuoso de trayectorias, y cada modificación corre el riesgo de codificar los puntos ciegos del modelo más profundamente en el sistema.

With Unit Tests: Still Behind Parallel Sampling

Con Pruebas Unitarias: Todavía Detrás del Muestreo Paralelo

When unit test cases are available — providing an objective correctness signal — all methods improve substantially, confirming that external verification is the primary driver of gains. But harness evolution still fails to catch up to simple test-time scaling. On pass@1, parallel sampling achieves 86.0% average (84.8% on Claude Opus 4.6, 87.1% on GPT-5.4), while harness evolution reaches only 75.8%, barely above the direct sampling baseline of 72.9%. Harness scaling does better at 82.6% but still trails parallel sampling. On pass@5 — the probability that any one of five attempts succeeds — sequential refinement leads at 91.8%, followed by parallel sampling at 86.0%, harness scaling at 89.3%, and harness evolution at 86.2%.

Cuando hay casos de prueba unitaria disponibles — proporcionando una señal objetiva de corrección — todos los métodos mejoran sustancialmente, confirmando que la verificación externa es el principal motor de las ganancias. Pero la evolución de harness todavía no logra alcanzar al test-time scaling simple. En pass@1, el muestreo paralelo logra 86.0% de promedio (84.8% en Claude Opus 4.6, 87.1% en GPT-5.4), mientras que la evolución de harness alcanza solo 75.8%, apenas por encima de la línea base de muestreo directo de 72.9%. El escalado de harness funciona mejor con 82.6% pero aún así va detrás del muestreo paralelo. En pass@5 — la probabilidad de que uno de cinco intentos tenga éxito — el refinamiento secuencial lidera con 91.8%, seguido por el muestreo paralelo con 86.0%, el escalado de harness con 89.3% y la evolución de harness con 86.2%.

The key observation here is about what the metrics reveal. If harness evolution genuinely improved the harness, we would expect to see it in pass@1 — the model should solve more tasks with a single attempt because the system prompt, tools, and control flow are better. Instead, the improvement only materializes when multiple trajectories are allowed (pass@5), and even then it is smaller than what alternative methods achieve. The implication is clear: harness evolution is not producing better harnesses; it is producing the statistical equivalent of multiple attempts, but less efficiently than methods designed for that purpose. “Refining solutions is a more productive use of extra compute than revising the harness itself,” the authors conclude.

La observación clave aquí es sobre lo que revelan las métricas. Si la evolución de harness mejorara genuinamente el harness, esperaríamos verlo en pass@1 — el modelo debería resolver más tareas con un solo intento porque el prompt del sistema, las herramientas y el flujo de control son mejores. En cambio, la mejora solo se materializa cuando se permiten múltiples trayectorias (pass@5), e incluso entonces es menor que lo que logran métodos alternativos. La implicación es clara: la evolución de harness no está produciendo mejores harness; está produciendo el equivalente estadístico de múltiples intentos, pero menos eficientemente que los métodos diseñados para ese propósito. “Refinar soluciones es un uso más productivo del cómputo extra que revisar el harness mismo”, concluyen los autores.

The Generalization Test: Evolved Harnesses Don't Transfer

La Prueba de Generalización: Los Harness Evolucionados No Transfieren

The most damning evidence comes from the generalization experiment. The authors split Terminal-Bench 2.1 into 45 training tasks, 10 validation tasks, and 34 held-out test tasks. They run harness evolution on the training set, select the best harness based on validation performance, and evaluate it on the held-out test set. The result is a startling lack of transfer: the evolved harness improves Claude Opus 4.6 by just 1.2 points and GPT-5.4 by 0.0 points, for an average gain of 0.6 points over the initial harness. Compare this with the within-distribution improvements of 3–10 points reported in prior work on harness evolution — where the same harness both searched on and was evaluated on the same task set.

La evidencia más condenatoria proviene del experimento de generalización. Los autores dividen Terminal-Bench 2.1 en 45 tareas de entrenamiento, 10 tareas de validación y 34 tareas de prueba no vistas. Ejecutan evolución de harness en el conjunto de entrenamiento, seleccionan el mejor harness basándose en el rendimiento de validación y lo evalúan en el conjunto de prueba no visto. El resultado es una sorprendente falta de transferencia: el harness evolucionado mejora Claude Opus 4.6 en solo 1.2 puntos y GPT-5.4 en 0.0 puntos, para una ganancia promedio de 0.6 puntos sobre el harness inicial. Compárese esto con las mejoras dentro de la distribución de 3–10 puntos reportadas en trabajos anteriores sobre evolución de harness — donde el mismo harness tanto buscaba como era evaluado en el mismo conjunto de tareas.

This gap between within-distribution and out-of-distribution performance is the signature of overfitting. The edits discovered during evolution encode shortcuts specific to the training tasks — memorizing known bugs, implementation templates, file paths, and command sequences for particular scenarios — rather than general principles of better harness design. When those specific patterns don’t apply to new tasks, the advantage disappears. The study suggests that current harness evolution algorithms can effectively memorize fixes but cannot distill generalizable strategies.

Esta brecha entre el rendimiento dentro de la distribución y fuera de la distribución es la marca del sobreajuste. Las ediciones descubiertas durante la evolución codifican atajos específicos de las tareas de entrenamiento — memorizando bugs conocidos, plantillas de implementación, rutas de archivos y secuencias de comandos para escenarios particulares — en lugar de principios generales de mejor diseño de harness. Cuando esos patrones específicos no se aplican a nuevas tareas, la ventaja desaparece. El estudio sugiere que los algoritmos actuales de evolución de harness pueden efectivamente memorizar correcciones pero no pueden destilar estrategias generalizables.

Why Rational Edits Produce Marginal Gains

Por Qué las Ediciones Racionales Producen Ganancias Marginales

One might suspect that harness evolution fails because the meta agent does not know what it is doing — that the edits are random or counterproductive. The paper’s analysis shows the opposite is true. The meta agent makes entirely rational, well-motivated changes across multiple layers of the harness. At the prompt layer, it adds behavioral rules targeting recurring failure classes: produce deliverables early, copy fragile state before mutating it, recheck task constraints before finishing. At the middleware layer, it introduces runtime enforcement: turn budget trackers that remind the agent to ship output once thresholds are reached, truncation of oversized tool outputs, finalization gates that block completion when deliverables are missing. At the tool layer, it corrects misleading tool guidance and injects recovery hints at command execution time.

Uno podría sospechar que la evolución de harness falla porque el meta-agente no sabe lo que está haciendo — que las ediciones son aleatorias o contraproducentes. El análisis del paper muestra lo contrario. El meta-agente hace cambios enteramente racionales y bien motivados a través de múltiples capas del harness. En la capa de prompt, añade reglas de comportamiento dirigidas a clases de fallo recurrentes: producir entregables temprano, copiar estado frágil antes de mutarlo, reverificar restricciones de tarea antes de finalizar. En la capa de middleware, introduce enforcement en tiempo de ejecución: rastreadores de presupuesto de turno que recuerdan al agente enviar salida una vez que se alcanzan los umbrales, truncamiento de salidas de herramienta sobredimensionadas, compuertas de finalización que bloquean la finalización cuando faltan entregables. En la capa de herramienta, corrige guías de herramienta engañosas e inyecta pistas de recuperación en el momento de ejecución de comandos.

The problem is not irrational edits but the nature of what is being memorized. Most changes encode information that a competent agent can rediscover through exploration within a single rollout — knowing to batch installation commands, to allow longer timeouts for slow package installations, to run syntax checks before submitting. These changes save time on tasks the agent could already solve but rarely convert failures into successes. Meanwhile, the stable core of hard failures — tasks that demand deep domain reasoning or have constraints outside the harness’s control — remains entirely unaffected by accumulated knowledge. And the growing volume of persistent prompt text introduces context bloat, adding noise that can offset the remaining gains. The edits are rational, but their returns are fundamentally bounded by the model’s underlying capacity on the hardest tasks.

El problema no son las ediciones irracionales sino la naturaleza de lo que se memoriza. La mayoría de los cambios codifican información que un agente competente puede redescubrir a través de la exploración dentro de un solo rollout — saber agrupar comandos de instalación, permitir timeouts más largos para instalaciones lentas de paquetes, ejecutar verificaciones de sintaxis antes de enviar. Estos cambios ahorran tiempo en tareas que el agente ya podía resolver pero raramente convierten fallos en éxitos. Mientras tanto, el núcleo estable de fallos difíciles — tareas que exigen razonamiento profundo de dominio o tienen restricciones fuera del control del harness — permanece completamente intacto por el conocimiento acumulado. Y el volumen creciente de texto de prompt persistente introduce inflación de contexto, añadiendo ruido que puede compensar las ganancias restantes. Las ediciones son racionales, pero sus retornos están fundamentalmente limitados por la capacidad subyacente del modelo en las tareas más difíciles.

Task Difficulty and Harness Sensitivity

Dificultad de la Tarea y Sensibilidad del Harness

The paper offers two explanations for why harness evolution shows such limited gains on Terminal-Bench specifically. First, agents already achieve relatively high scores on this benchmark — direct sampling reaches 69.9% on Claude Opus 4.6 and 75.3% on GPT-5.4 — so the remaining failures are likely model-level limitations rather than harness deficiencies. Second, Terminal-Bench may simply not be very sensitive to harness design: a minimal setup of a shell tool and basic prompt suffices for most solvable tasks. If there is no significant headroom for harness improvement, then searching over harness configurations cannot produce large gains regardless of the algorithm’s sophistication.

El paper ofrece dos explicaciones de por qué la evolución de harness muestra ganancias tan limitadas en Terminal-Bench específicamente. Primero, los agentes ya logran puntuaciones relativamente altas en este benchmark — el muestreo directo alcanza 69.9% en Claude Opus 4.6 y 75.3% en GPT-5.4 — por lo que los fallos restantes son probablemente limitaciones a nivel de modelo en lugar de deficiencias del harness. Segundo, Terminal-Bench puede simplemente no ser muy sensible al diseño del harness: una configuración mínima de una herramienta shell y un prompt básico es suficiente para la mayoría de las tareas resolubles. Si no hay un margen significativo para la mejora del harness, entonces buscar sobre configuraciones de harness no puede producir grandes ganancias independientemente de la sofisticación del algoritmo.

The authors argue that future work on harness evolution should be evaluated on benchmarks satisfying two conditions: tasks must be difficult enough that current agents leave substantial headroom, and performance must depend heavily on the harness — as when specialized tools, complex workflows, or custom skills are crucial to success. Under these conditions, a genuinely better harness can expand the set of solvable problems rather than just saving time on already-solvable ones.

Los autores argumentan que el trabajo futuro sobre evolución de harness debería evaluarse en benchmarks que satisfagan dos condiciones: las tareas deben ser suficientemente difíciles como para que los agentes actuales dejen un margen sustancial de mejora, y el rendimiento debe depender fuertemente del harness — como cuando herramientas especializadas, flujos de trabajo complejos o habilidades personalizadas son cruciales para el éxito. Bajo estas condiciones, un harness genuinamente mejor puede expandir el conjunto de problemas resolubles en lugar de solo ahorrar tiempo en problemas ya resolubles.

Implications for the Field

Implicaciones para el Campo

This paper is important not because it disproves the value of automatic harness evolution — the idea remains compelling, and future algorithms may yet realize its potential — but because it identifies a methodological blind spot that has affected how the field measures progress. When the search and evaluation sets overlap, and when baselines do not receive matched compute budgets, reported gains are not reliably attributable to the claimed mechanism. The paper’s controlled comparison protocol — unifying feedback signals, inference budgets, and evaluation procedures across methods — should become a standard practice for any work claiming improvements in automatic harness design.

Este paper es importante no porque refute el valor de la evolución automática de harness — la idea sigue siendo convincente, y futuros algoritmos pueden aún realizar su potencial — sino porque identifica un punto ciego metodológico que ha afectado cómo el campo mide el progreso. Cuando los conjuntos de búsqueda y evaluación se superponen, y cuando las líneas base no reciben presupuestos de cómputo equiparados, las ganancias reportadas no son atribuibles de forma fiable al mecanismo reclamado. El protocolo de comparación controlada del paper — unificando señales de retroalimentación, presupuestos de inferencia y procedimientos de evaluación entre métodos — debería convertirse en una práctica estándar para cualquier trabajo que reclame mejoras en el diseño automático de harness.

The implications extend beyond harness engineering specifically. Any domain where an iterative search procedure is used to optimize a system component — prompts, retrieval configurations, tool definitions, middleware stacks — and then evaluated on the same distribution that guided the search, is vulnerable to the same confound. The core insight generalizes: when you allocate compute budget to search, some fraction of what you observe is the search itself, not what you searched over. Controlling for this requires separating the evaluation distribution from the optimization distribution, and comparing against baselines that receive equivalent budgets for simpler forms of search — like sampling more trajectories, or refining existing ones. If a complex optimization procedure does not outperform these trivial baselines, its apparent gains were never gains at all.

Las implicaciones se extienden más allá de la ingeniería de harness específicamente. Cualquier dominio donde se use un procedimiento de búsqueda iterativa para optimizar un componente del sistema — prompts, configuraciones de recuperación, definiciones de herramientas, pilas de middleware — y luego se evalúe en la misma distribución que guió la búsqueda, es vulnerable al mismo factor de confusión. La idea central se generaliza: cuando asignas un presupuesto de cómputo a la búsqueda, alguna fracción de lo que observas es la búsqueda misma, no aquello sobre lo que buscaste. Controlar esto requiere separar la distribución de evaluación de la distribución de optimización, y comparar contra líneas base que reciben presupuestos equivalentes para formas más simples de búsqueda — como muestrear más trayectorias, o refinar las existentes. Si un procedimiento de optimización complejo no supera a estas líneas base triviales, sus ganancias aparentes nunca fueron ganancias en absoluto.

References

Referencias