Capítulo 5 — HarnessCompass: evolución automática de harnesses

Los capítulos anteriores tratan el harness como algo que vos construís y afinás a mano. Este capítulo se ocupa de la pregunta siguiente: ¿y si el harness se afinara solo?

---

Ficha del trabajo original

Título	HarnessCompass: Guiding Automatic Harness Evolution toward Generalizable and Effective Agent Harnesses
Autores	Luan Zhang*, Ruochen Zhou*, Dandan Song†, Zhengyu Chen, Yuhang Tian, Jun Yang, Huipeng Ma, Chenhao Li, Guangyuan Feng, Xudong Li, Yizhou Jin, Yan Xu
Instituciones	¹ Beijing Institute of Technology, China · ² City University of Hong Kong, China · ³ Independiente, China
Contacto	{luan_zhang, sdd}@bit.edu.cn · [email protected]
Publicado	3 de agosto de 2026
Referencia	arXiv:2608.01918v1 [cs.LG] · DOI 10.48550/arXiv.2608.01918
Licencia	Creative Commons Attribution 4.0 (CC BY 4.0)
Estado	Preprint, actualmente bajo revisión

* Estos autores contribuyeron por igual. † Autor de correspondencia.

Nota de autoría

Todas las ideas, el método, los experimentos, las tablas y los prompts de este capítulo son obra de Zhang et al., no míos. Este documento es una traducción y exposición en español del paper completo, publicada bajo el amparo de la licencia CC BY 4.0 del original, que permite reproducir y adaptar la obra siempre que se dé crédito.

Lo que aporté yo se limita a: la traducción, el reordenamiento de secciones para lectura lineal, los diagramas explicativos, y las secciones finales marcadas explícitamente como lectura propia (§14 y §15). Todo lo demás es contenido del paper.

Si vas a citar este trabajo en un contexto académico, citá el original:

@misc{zhang2026harnesscompass,
  title  = {HarnessCompass: Guiding Automatic Harness Evolution toward
            Generalizable and Effective Agent Harnesses},
  author = {Zhang, Luan and Zhou, Ruochen and Song, Dandan and Chen, Zhengyu
            and Tian, Yuhang and Yang, Jun and Ma, Huipeng and Li, Chenhao
            and Feng, Guangyuan and Li, Xudong and Jin, Yizhou and Xu, Yan},
  year   = {2026},
  eprint = {2608.01918},
  archivePrefix = {arXiv},
  primaryClass  = {cs.LG}
}

Este capítulo es autoconclusivo

Está escrito para que leerlo equivalga a leer el paper. Incluye el abstract, la introducción, los trabajos relacionados, el formalismo, el algoritmo, las tres secciones de método, todos los experimentos con sus tablas numéricas completas, el caso de estudio, la conclusión, el trabajo futuro, el apéndice de prompts íntegro y la bibliografía. No hace falta que abras el PDF.

Los prompts del apéndice se reproducen verbatim en inglés, tal como están en el original: son artefactos operativos pensados para copiarse y usarse, y traducirlos los rompería. Cada uno va precedido de una explicación en español de qué hace y qué reglas impone.

---

Índice

1. Abstract
2. Introducción
3. Trabajos relacionados
4. Preliminares y formalismo
5. El algoritmo de HarnessCompass
6. Principio ❶ — Evolución restringida
7. Principio ❷ — Feedback proactivo
8. Principio ❸ — Optimización por componente y fusión R³
9. Experimentos
10. Caso de estudio: cuando la evolución sin compuerta premia el sobreajuste
11. Conclusión
12. Trabajo futuro
13. Apéndice A — Los prompts completos
14. Lectura propia: qué te llevás a tu harness manual
15. Lectura propia: limitaciones para leerlo con criterio
16. Referencias del paper

---

1. Abstract

El diseño del harness juega un rol crítico en el rendimiento de los agentes, porque moldea cómo los modelos de lenguaje grandes (LLMs) perciben, razonan y actúan dentro de entornos ejecutables. Trabajo reciente ha propuesto la evolución automática de harnesses, que mejora iterativamente el harness a partir de las interacciones agente-entorno. Sin embargo, los métodos existentes suelen sobreajustarse a las tareas de evolución, se apoyan exclusivamente en señales derivadas de trayectorias, y optimizan los componentes del harness de forma conjunta, causando interferencia entre componentes.

Proponemos HarnessCompass, un framework novedoso de evolución automática de harnesses construido alrededor de la evolución restringida, el feedback proactivo y la optimización por componente. HarnessCompass primero impone restricciones globales sobre la evolución, restringiendo las modificaciones a cambios de harness agnósticos a la tarea que generalizan más allá de las tareas de evolución. Luego aumenta la evidencia derivada de trayectorias con feedback proactivo en primera persona del agente sobre el uso del harness, lo que produce señales más ricas para la evolución. Finalmente, desacopla la optimización de los distintos componentes del harness antes de consolidarlos en un harness unificado, reduciendo la interferencia entre componentes y preservando su sinergia.

Sobre SWE-bench Verified con GPT-5.4, HarnessCompass mejora Pass@1 de 54 % a 66 % en solo 5 iteraciones de evolución, superando a AHE tanto en efectividad como en eficiencia evolutiva. Además, el harness evolucionado transfiere efectivamente a tareas held-out y a otros modelos, demostrando una generalización sustancialmente más fuerte que los métodos previos de evolución automática de harnesses.

---

2. Introducción

2.1 El harness es una palanca real

Los agentes basados en LLM se despliegan cada vez más en entornos ejecutables: arreglan repositorios de código, ejecutan flujos de terminal de múltiples pasos y coordinan herramientas a lo largo de horizontes largos.

Más allá del modelo base, su rendimiento depende del harness: la capa de software que orquesta cómo el modelo interactúa con su entorno. Eso incluye los prompts y las herramientas, así como el middleware, la memoria y los componentes de verificación que moldean qué observa y qué hace.

Trabajo reciente muestra que el diseño del harness por sí solo puede desplazar sustancialmente el rendimiento del agente incluso con el modelo base fijo, lo que lo convierte en una palanca importante para mejorar agentes.

2.2 Pero el bucle manual no escala

Como el mejor harness es específico del modelo y debe re-afinarse cada vez que el modelo base cambia, ese trabajo sigue cayendo sobre los desarrolladores, que leen trayectorias, diagnostican fallas y revisan el harness a mano. Como los modelos base avanzan rápido, este bucle manual se queda atrás, y se abre una brecha creciente entre lo que un modelo puede hacer y lo que su harness le permite realizar.

Eso motivó el desarrollo de la evolución automática de harnesses, donde un meta-agente mejora iterativamente el harness a partir de las interacciones agente-entorno. Estos métodos siguen típicamente un bucle de búsqueda: el meta-agente analiza trayectorias pasadas generadas por el agente de tareas, propone modificaciones al harness, evalúa el harness modificado sobre tareas de benchmark, e itera.

flowchart LR
    A["Agente de tareas<br/>+ harness actual"] -->|"resuelve tareas"| B["Trayectorias<br/>crudas"]
    B --> C["Meta-agente<br/>analiza"]
    C -->|"propone ediciones"| D["Harness<br/>modificado"]
    D -->|"se evalúa"| A

Tales métodos buscan sobre todo el espacio del harness y reportan ganancias sustanciales en benchmarks públicos.

2.3 Las tres limitaciones

Pero una mirada más cercana a cómo surgen esas ganancias revela tres limitaciones que, en conjunto, ponen un techo a la confiabilidad y la generalidad de los métodos actuales.

❶ Los métodos existentes se sobreajustan a las tareas de búsqueda

Como el meta-agente puede revisar el harness libremente contra el feedback de un verificador sobre un conjunto fijo de tareas, tiende a hornear atajos específicos de esas tareas que suben el score sobre el conjunto de búsqueda pero no transfieren.

Estudios de evaluación recientes lo confirman, reportando que los harnesses evolucionados generalizan pobremente a tareas held-out cuando los conjuntos de búsqueda y evaluación son disjuntos, lo que apunta a adaptación a tareas específicas más que a diseño transferible de harness.

❷ Los métodos existentes se apoyan solo en señales derivadas de trayectorias

El meta-agente ve cada interacción solo desde afuera, así que aprende que una tarea falló y dónde, pero no por qué el agente encontró el harness difícil de usar.

Como resultado, es propenso a la mala atribución, donde la fricción genuina del harness se lee como un error del agente, o el propio razonamiento fallido del agente se le achaca a una herramienta faltante.

❸ Los métodos existentes optimizan todos los componentes conjuntamente

Cuando prompts, herramientas, middleware y memoria se revisan juntos en una sola pasada, sus ediciones interfieren, de modo que las ganancias que cada edición trae aislada tienden a taparse en vez de componerse una vez combinadas.

2.4 La causa común

Estas limitaciones surgen en puntos distintos del bucle, pero se remontan a una sola causa. Los métodos actuales le dan al meta-agente libertad amplia para cambiar el harness mientras le alimentan solo resultados externos y lo dejan revisar todo de una vez.

Las ediciones sin restricción invitan al sobreajuste, la evidencia solo-de-resultado invita a la mala atribución, y las modificaciones simultáneas invitan a la interferencia. El desafío central, por lo tanto, no es la evolución del harness en sí, sino la falta de estructura y disciplina que gobierne el proceso de evolución.

Un harness efectivo debería en cambio emerger de un proceso de evolución disciplinado que restrinja qué puede cambiar, provea al meta-agente evidencia más rica para razonar, y aísle las modificaciones individuales antes de consolidarlas.

2.5 Los tres principios

Motivados por esa meta, los autores proponen HarnessCompass, un framework construido sobre tres principios que atacan las tres limitaciones una a una:

flowchart TD
    L1["❶ Sobreajuste<br/>al conjunto de búsqueda"] --> P1["Evolución restringida"]
    L2["❷ Señal pobre<br/>(solo trayectorias)"] --> P2["Feedback proactivo"]
    L3["❸ Interferencia entre<br/>componentes"] --> P3["Optimización por componente"]
    P1 --> H["Harness efectivo<br/>y transferible"]
    P2 --> H
    P3 --> H

❶ La evolución restringida sujeta cada edición a restricciones globales. Solo permite cambios agnósticos a la tarea, descartando hardcodeo, keyword matching y reglas específicas de instancia, para que el framework aprenda principios de diseño reutilizables en vez de atajos ajustados al conjunto visto.

❷ El feedback proactivo agrega una señal que las trayectorias solas no pueden dar, pidiéndole al agente que reporte en primera persona su propia experiencia usando el harness, lo que expone fricción de uso y capacidades faltantes. Para mantenerlo confiable, el feedback cuenta solo como evidencia candidata: se fundamenta contra las trayectorias antes de motivar una edición, de modo que la señal agregada sea a la vez más rica y verificable.

❸ La optimización por componente afina cada componente del harness en su propia pista en vez de editar todo de una vez, y después fusiona las modificaciones validadas en un harness unificado mediante un paso de integración con principios. Esta separación frena la interferencia entre componentes mientras retiene la sinergia entre ediciones complementarias.

2.6 Contribuciones

Los autores resumen sus contribuciones en tres puntos:

• Identifican tres limitaciones clave de los métodos existentes de evolución automática de harnesses: sobreajuste a las tareas de búsqueda, feedback insuficiente para diagnosticar problemas del harness, e interferencia entre componentes optimizados conjuntamente.

• Introducen HarnessCompass, un framework disciplinado de evolución de harness que combina evolución restringida, feedback proactivo y optimización por componente para producir harnesses efectivos y transferibles.

• Conducen experimentos extensos sobre SWE-bench Verified, demostrando que HarnessCompass logra ganancias sustanciales de rendimiento mientras mejora la generalización a través de tareas y modelos no vistos.

---

3. Trabajos relacionados

3.1 Agentes LLM y diseño de harness

Desplegar un LLM como agente en un entorno ejecutable requiere más que un modelo base capaz; requiere también un harness bien diseñado que module cómo el modelo percibe el estado, interactúa con herramientas y se recupera de fallas.

Paradigmas fundacionales como reasoning-and-acting (ReAct, Yao et al. 2023) establecieron el bucle de interacción para agentes basados en LLM. Construyendo sobre esa base, los agentes de ingeniería de software mostraron que las interfaces y los harnesses cuidadosamente diseñados son críticos para el rendimiento:

• SWE-agent (Yang et al. 2024b) demuestra que una interfaz agente-computadora hecha a propósito mejora sustancialmente la resolución de issues sobre SWE-Bench (Jimenez et al. 2024b).
• Plataformas como OpenHands (Wang et al. 2025) unifican prompts, herramientas y lógica de control en scaffolds de agente completos.

Evidencia reciente refuerza esta tendencia: modificar el scaffold del agente por sí solo puede producir ganancias de rendimiento comparables a las obtenidas actualizando el modelo base subyacente. Esta observación desplazó el campo desde scaffolds diseñados a mano hacia agentes capaces de mejorar autónomamente sus propias implementaciones.

En esa línea:

• La Darwin Gödel Machine (Zhang et al. 2025a) ve a los agentes como sistemas de software editables y los mejora mediante auto-modificación iterativa y evaluación empírica.
• Live-SWE-agent (Xia et al. 2025) parte de un scaffold mínimo, solo-Bash, y evoluciona autónomamente su implementación en tiempo de ejecución mientras resuelve tareas reales de ingeniería de software.
• Un survey reciente (Gao et al. 2025) organiza este campo emergente alrededor de qué, cuándo y cómo evoluciona un agente.

Sin embargo, los sistemas existentes en su mayoría artesanan o evolucionan harnesses sin mecanismos explícitos que aseguren efectividad y generalidad, lo que motiva métodos que adapten harnesses automáticamente manteniendo su rendimiento y transferibilidad.

3.2 Optimización automática de prompts, herramientas y workflows

Una línea paralela de trabajo reemplaza el ajuste manual con búsqueda automática sobre partes del stack del agente.

A nivel de prompt:

• OPRO (Yang et al. 2024a) genera instrucciones mejoradas a partir de scores previos, aprovechando la búsqueda basada en LLM.
• TextGrad (Yuksekgonul et al. 2024) optimiza sistemas compuestos propagando feedback en lenguaje natural.
• Self-Supervised Prompt Optimization (Xiang et al. 2025) reduce aún más los requisitos de supervisión derivando señales únicamente de comparaciones de salida, sin referencias ground-truth.
• Un survey (Ramnath et al. 2025) resume esta área en rápido crecimiento.

Más allá de los prompts:

• ToolMaker (Wölflein et al. 2025) convierte repositorios de código en herramientas invocables mediante un bucle autocorrectivo.
• ToolLibGen (Yue et al. 2025) organiza herramientas generadas automáticamente en una librería mantenible.

A nivel estructural:

• ADAS (Hu, Lu y Clune 2025) busca diseños de agentes en código.
• AFlow (Zhang et al. 2025b) formula la construcción de workflows como Monte Carlo tree search sobre grafos de código.
• Optimizadores de agentes end-to-end (Evers-Hood et al. 2025) extienden esta dirección aún más.

Lo más estrechamente relacionado: la evolución automática de harnesses optimiza conjuntamente el harness completo mediante interacciones agente-entorno (Lin et al. 2026 — el método AHE, Agentic Harness Engineering, que sirve de baseline principal en este paper).

Sin embargo, evaluación reciente (Wang et al. 2026) revela que tales métodos a menudo se sobreajustan a las tareas de búsqueda y generalizan pobremente a conjuntos de evaluación disjuntos, resaltando las brechas de confiabilidad y generalización que este estudio aborda.

---

4. Preliminares y formalismo

Sea M el modelo base, que permanece fijo durante todo el proceso de evolución, y sea H un harness, representado como un conjunto de componentes editables.

Siguiendo a Lin et al. (2026), un harness consiste en siete tipos de componentes ortogonales, divididos en dos categorías:

flowchart TB
    subgraph EST["Componentes ESTRUCTURALES"]
        E1["Implementaciones<br/>de herramientas"]
        E2["Middleware"]
        E3["Configuración de<br/>sub-agentes"]
    end
    subgraph GUI["Componentes de GUÍA"]
        G1["System prompt"]
        G2["Descripciones<br/>de herramientas"]
        G3["Skills"]
        G4["Memoria de<br/>largo plazo"]
    end
    EST -->|"ejecutan código<br/>e interacciones de control"| A["Harness H"]
    GUI -->|"proveen guía<br/>de comportamiento"| A

• Componentes estructurales: implementaciones de herramientas, middleware y configuraciones de sub-agentes, que ejecutan código e interacciones de control.
• Componentes de guía: el system prompt, las descripciones de herramientas, las skills y la memoria, que proveen guía de comportamiento.

Esta distinción no es cosmética: es el eje sobre el que giran los tres principios.

Definiciones operativas

• Correr M con un harness H sobre una tarea x ∈ D produce una trayectoria τ, también llamada raw trace, que registra la secuencia completa de mensajes, llamadas a herramientas y observaciones del entorno.
• Un verificador asigna un resultado r(τ) ∈ {0, 1}, donde 1 indica completitud exitosa de la tarea.
• Se realizan k rollouts por tarea y se evalúa el rendimiento usando Pass@1, definido como la tasa de éxito promedio sobre las tareas evaluadas.

El bucle evoluciona un harness sobre iteraciones t = 1, …, N. En cada iteración t, el meta-agente Meta recibe la evidencia estructurada destilada de la corrida bajo H_t−1 y produce el siguiente harness H_t.

El harness semilla es deliberadamente mínimo

El proceso se inicializa deliberadamente con un harness mínimo H₀, que consiste solo en un único comando de shell como su herramienta, un system prompt corto, y sin middleware, skills ni sub-agentes.

Empezar mínimo asegura que cada componente de un harness posterior H_t sea uno que el bucle mismo introdujo y midió contra los rollouts de M bajo H, en vez de uno heredado de un punto de partida fuerte cuya contribución no se podría aislar.

---

5. El algoritmo de HarnessCompass

HarnessCompass es un framework de evolución automática de harness que mejora el harness de un agente de código manteniendo el modelo base fijo. Siguiendo trabajo previo (Lin et al. 2026), adopta un bucle cerrado iterativo de tres etapas: evaluar el harness actual sobre tareas de búsqueda, analizar las trayectorias resultantes, y mejorar el harness a partir del análisis.

Lo que distingue a HarnessCompass es cómo disciplina ese bucle:

1. La evolución restringida limita qué puede editar el meta-agente, para que los cambios sigan siendo agnósticos a la tarea y transferibles.
2. El feedback proactivo enriquece la evidencia sobre la que razona el meta-agente con una señal en primera persona que las trazas crudas no llevan.
3. La optimización por componente optimiza distintas clases de componentes en pistas separadas y después reconcilia las ediciones sobrevivientes en un solo harness, de modo que las pistas no interfieran.

Algoritmo 1 — Procedimiento de evolución de HarnessCompass

Requiere: harness inicial H₀, modelo base M, meta-agente Meta,
          tareas de búsqueda D, k rollouts por tarea, N iteraciones
Asegura:  harness evolucionado H*

 1: H* ← H₀
 2: para t = 1 hasta N hacer
 3:     T ← Rollout(M, H*, D, k)             ▷ evaluar harness actual
 4:     E ← Distill(T)                        ▷ evidencia basada en trayectorias
 5:     F ← GroundSelfFeedback(Meta, T)       ▷ evidencia en primera persona
 6:     para toda pista c ∈ {structure, guidance} hacer   ▷ optimización por componente
 7:         H^c ← GatedEvolve(Meta, H*, E, F, c)          ▷ evolución restringida
 8:         T^c ← Rollout(M, H^c, D, k)
 9:     fin para
10:     w ← argmax_c Pass@1(T^c);  ℓ ← la otra pista
11:     H_t ← R³(H^w, H^ℓ)                    ▷ integrar ediciones complementarias
12:     si Pass@1(T^w) > Pass@1(T) entonces
13:         H* ← H_t                          ▷ aceptar harness mejorado
14:     fin si
15: fin para
16: devolver H*

flowchart TD
    S["H* = harness actual"] --> R1["Rollout sobre D<br/>(k por tarea)"]
    R1 --> D1["Distill:<br/>evidencia E de trayectorias"]
    R1 --> D2["GroundSelfFeedback:<br/>evidencia F en primera persona"]
    D1 --> G1["GatedEvolve<br/>pista ESTRUCTURAL"]
    D2 --> G1
    D1 --> G2["GatedEvolve<br/>pista de GUÍA"]
    D2 --> G2
    G1 --> EV1["Rollout y Pass@1"]
    G2 --> EV2["Rollout y Pass@1"]
    EV1 --> W{"¿quién gana?"}
    EV2 --> W
    W -->|"ganador = base<br/>perdedor = candidato"| R3["R³:<br/>Revisión + Recombinación<br/>+ Refinamiento"]
    R3 --> ACC{"¿mejoró<br/>sobre H*?"}
    ACC -->|sí| S
    ACC -->|no| S

---

6. Principio ❶ — Evolución restringida

La evolución restringida contrarresta el sobreajuste haciendo inadmisibles desde el arranque las ediciones específicas de tarea, para que el meta-agente solo pueda subir el score mediante cambios que además transfieran a tareas no vistas.

Se implementa como una compuerta de generalización (generalization gate) que cada edición candidata debe pasar antes de aplicarse. La compuerta cubre los siete tipos de componentes e impone dos requisitos sobre cada edición: uno sobre qué puede expresar y otro sobre dónde puede residir.

6.1 Requisito de contenido

El primer requisito gobierna el contenido de una edición. Aquí, la compuerta rechaza toda edición que mencione:

• una instancia de tarea específica,
• un nombre de función o archivo de test,
• un símbolo privado o una ruta de archivo bajo evaluación,
• así como cualquier rama de código que se dispare con tokens que aparecen exclusivamente en tareas particulares.

Lo que admite es el complemento de eso: un criterio de decisión reutilizable acompañado de una condición de aplicabilidad que el agente pueda evaluar en una tarea que nunca vio.

Este requisito desplaza el objetivo de la evolución desde fixes memorizados hacia principios de diseño transferibles, que son exactamente lo que los harnesses sobreajustados fallan en capturar.

6.2 Requisito de ubicación

El segundo requisito gobierna dónde puede colocarse una edición. Las ediciones se separan en dos categorías:

Categoría	Qué hace	Dónde debe ir
Ediciones de capacidad	Agregan funcionalidad ejecutable nueva, como correr tests o instalar paquetes	Deben implementarse como código ejecutable dentro de middleware, herramientas o sub-agentes
Ediciones de guía	Solo proveen instrucciones de comportamiento al agente	Deben colocarse en el system prompt o la memoria, no en componentes ejecutables

Esta separación impide que la guía se codifique como lógica ejecutable. A diferencia del código de capacidad, la guía no define una condición de ejecución confiable: puede dispararse en tareas no relacionadas o fallar en activarse cuando se la necesita. Permitir tales ediciones reintroduciría los comportamientos específicos de tarea que la compuerta de generalización busca eliminar.

En conjunto, los dos requisitos aseguran que cada edición sea a la vez agnóstica a la tarea y apropiadamente ubicada, guiando la evolución del harness hacia principios de ingeniería reutilizables en vez de optimizaciones específicas de tarea.

(El texto completo de ambos requisitos, tal como aparece en el system prompt del meta-agente, está en el Apéndice A.2 y A.3.)

---

7. Principio ❷ — Feedback proactivo

El feedback proactivo enriquece la evidencia sobre la que razona el meta-agente. Los métodos previos de evolución automática de harness observan cada interacción solo desde una perspectiva externa, así que muestran que una tarea falló y dónde, pero no por qué el agente de código luchó por usar el harness.

Los autores cierran esa brecha en tres pasos: primero le piden al propio agente de código que reporte su experiencia usando el harness (ya que solo él sabe dónde se trabó); después chequean cada reporte contra la trayectoria y conservan solo lo que la trayectoria realmente sostiene; y finalmente convierten los reportes sobrevivientes en evidencia que el meta-agente puede usar, junto a la evidencia de trayectorias que ya tiene.

sequenceDiagram
    participant A as Agente de código<br/>(mismo modelo M)
    participant V as Verificador externo
    participant R as Reconciliador
    participant G as Analizador<br/>(grounding)
    A->>A: Paso 1 · Reporte ciego<br/>(no conoce el veredicto)
    V->>A: veredicto + salida
    A->>A: Paso 2 · Reporte con retrospectiva<br/>+ atribución de la falla
    A->>R: los dos reportes
    R->>R: Paso 3 · Reconciliación<br/>(etiqueta de acuerdo)
    R->>G: ítems unificados
    G->>G: Paso 4 · Validar contra trayectoria<br/>+ asignar pista
    G-->>A: evidencia fundamentada

Nota de implementación: las tres primeras llamadas las hace el mismo modelo base M que generó la trayectoria, asegurando que la reflexión sea genuinamente en primera persona. La cuarta la maneja el modelo analizador, que sirve como chequeador externo. Las cuatro se fundamentan en la misma trayectoria, y solo a la reflexión ciega se le oculta el veredicto de ejecución.

7.1 Obtención del feedback en primera persona

Después de que el verificador puntúa una ronda, se recolecta feedback en primera persona de cada tarea fallida, usando el mismo modelo base M que generó la trayectoria. Se emiten dos consultas y se reconcilian sus salidas:

Reporte ciego (blind report)

Se provee la trayectoria sin revelar el veredicto y se le pregunta al agente de código dónde el harness obstaculizó su ejecución y qué capacidades hubiera deseado que el harness le proveyera.

Este diseño evita el sesgo retrospectivo: sin conocer el resultado, el agente es menos propenso a racionalizar la falla desde un resultado conocido.

Reporte con retrospectiva (hindsight report)

Se revela el veredicto y se le pide al agente de código diagnosticar la falla, asignándola a una de cuatro causas:

Causa	Qué implica
el harness	Es un problema que la evolución puede arreglar
el propio razonamiento del agente	El agente razonó mal; el harness no tiene la culpa
ambigüedad de la tarea	La tarea estaba mal especificada
el entorno	Factor externo, incontrolable

Esta atribución aísla los problemas relacionados con el harness, impidiendo que el proceso de evolución optimice contra fallas que el harness no puede arreglar.

Los dos reportes se reconcilian luego en ítems de feedback unificados, registrando su nivel de acuerdo. El feedback resultante sirve como evidencia adicional para la evolución del harness, junto a la evidencia derivada de trayectorias.

7.2 Fundamentación contra las trayectorias

Un reporte en primera persona es meramente una afirmación, y un agente de código puede atribuir sus propias fallas al harness. Por eso un ítem de feedback se retiene solo cuando la trayectoria lo sostiene:

• Para quejas sobre componentes existentes, la trayectoria debe revelar directamente la dificultad subyacente.
• Para pedidos de capacidades nuevas, que no pueden observarse directamente en la trayectoria, la trayectoria debe en cambio demostrar un hueco concreto que la capacidad propuesta atendería.

El feedback no sostenido se descarta, removiendo tanto las quejas espurias como las fallas incorrectamente atribuidas al harness. Los ítems restantes forman la evidencia fundamentada (grounded evidence) que consume el meta-agente durante la evolución.

7.3 Agregación y uso

Los reportes sobrevivientes se agregan en evidencia estructurada que el meta-agente puede usar directamente. Esta agregación sigue un procedimiento determinista, sin ninguna llamada adicional al modelo.

Los reportes se agrupan por el componente del harness que implican, y a cada grupo se le asigna un score de confianza basado en tres factores:

1. el nivel de acuerdo entre reportes,
2. la cantidad de tareas distintas afectadas,
3. la consistencia entre el reporte ciego y el retrospectivo.

Estos reportes agrupados se proveen al meta-agente como una fuente de evidencia adicional en vez de un reemplazo de la evidencia de trayectorias.

Cualquier edición motivada por esta evidencia se sostiene con el mismo estándar que cualquier otra edición, así que igual debe estar sostenida por la trayectoria y se revierte en la ronda siguiente si no lo está.

De este modo, el feedback proactivo enriquece la evidencia disponible para el meta-agente manteniéndose dentro de las restricciones impuestas por la evolución restringida.

---

8. Principio ❸ — Optimización por componente y fusión R³

La optimización por componente contrarresta la interferencia causada por modificar conjuntamente componentes completos del harness. Los autores la evitan optimizando componentes en pistas separadas y reconciliando los resultados solo después. El proceso consta de dos pasos.

8.1 Correr las pistas independientemente

En cada ronda se evolucionan dos variantes del harness en paralelo, cada una restringida a uno de los dos grupos de componentes definidos por la evolución restringida:

• Una variante se enfoca en componentes estructurales: middleware, implementaciones de herramientas y sub-agentes, que ejecutan código e interacciones de control.
• La otra se enfoca en componentes de guía: el system prompt, las skills, las descripciones de herramientas y la memoria, que proveen guía de comportamiento.

Como las dos variantes operan sobre espacios de componentes disjuntos, sus actualizaciones permanecen aisladas dentro de cada ronda.

Se evalúan ambas variantes y se selecciona la que tiene mayor Pass@1 como ganadora.

Cada variante lleva además un auto-chequeo de frontera: antes de escribir el manifiesto de cambios, verifica que cada archivo editado esté de su lado y, si alguno cayó del otro lado, lo revierte o re-expresa la intención dentro de su propio lado.

8.2 Fusionar las pistas — R³

El ganador es solo la mitad del progreso de la ronda, ya que el perdedor editó un grupo de componentes diferente y todavía puede contener mejoras útiles. Para preservar esas ganancias sin heredar regresiones, se realiza una fusión de tres pasos partiendo del ganador como base.

Los autores llaman a este procedimiento R³, correspondiente a tres etapas: Revisión, Recombinación y Refinamiento.

La fusión se ejecuta en un git worktree ramificado desde el ganador, lo que hace que las ediciones del ganador sean la base inmutable y el diff del perdedor el único material candidato.

flowchart LR
    W["Variante GANADORA<br/>(base inmutable)"] --> R1
    L["Variante PERDEDORA<br/>(material candidato)"] --> R1
    R1["1 · Revisión<br/>KEEP / DROP cada cambio<br/>del perdedor, uno por uno"] --> R2
    R2["2 · Recombinación<br/>aplicar los KEEP sobre<br/>la base ganadora"] --> R3
    R3["3 · Refinamiento<br/>cazar y eliminar<br/>duplicados confirmados"] --> F["Harness<br/>unificado"]

1 · Revisión. Examina cada edición del perdedor y retiene solo las que son independientemente beneficiosas y ni duplican ni entran en conflicto con el ganador, descartando regresiones, reglas específicas de tarea y modificaciones inciertas.

Regla ante la duda: DROP. La base ganadora ya se sostiene sola; agregar cambios dudosos solo arriesga bajarla. Pero múltiples cambios buenos e independientes pueden y deben conservarse todos — no hay que limitar artificialmente a uno. El perdedor exploró una pista entera; hay que rescatar todo lo genuinamente útil.

2 · Recombinación. Aplica las ediciones retenidas al harness con base en el ganador, con el ganador teniendo precedencia en cualquier conflicto a nivel de archivo. Como las pistas son ortogonales, rara vez tocan el mismo archivo.

3 · Refinamiento. Remueve las ediciones redundantes que no entran en conflicto a nivel de archivo pero implementan funcionalidad solapada, reteniendo la modificación asociada con el componente más confiable.

Concretamente: se recorre cada ítem de consejo ahora presente en el harness combinado (cada regla del system prompt, cada entrada de memoria, cada nota de descripción de herramienta) y se pregunta: “¿este comportamiento ya está impuesto deterministamente por algún middleware o implementación de herramienta en este mismo harness?”. Si la respuesta es sí, ese ítem de consejo es redundante y se borra. Cuando hay redundancia, se conserva el mecanismo determinista y se borra el consejo, sin importar de qué variante venga.

Este paso existe porque el bloat de prompts y memoria a lo largo de las rondas fue un modo de falla real en corridas previas. Pero la barra para borrar es alta: solo se borra ante un duplicado confirmado. Si no se puede señalar el componente específico que ya lo cubre, se conservan ambos. El criterio es “puedo nombrar qué hace esto redundante”, no “borrar libremente”.

8.3 El manifiesto de cambios

Cada edición del meta-agente se registra en un manifiesto legible por máquina, que la ronda siguiente usa para atribuir cambios de score a ediciones individuales y determinar rollbacks.

Los dos campos finales del manifiesto enlazan cada edición con la evidencia de feedback en primera persona que la motivó, lo que permite medir con qué frecuencia el feedback proactivo lleva a cambios efectivamente comprometidos.

(El esquema completo está en el Apéndice A.13.)

---

9. Experimentos

Los experimentos responden tres preguntas:

	Pregunta
Efectividad	¿HarnessCompass evoluciona un harness mejor que la evolución automática previa, y a qué costo en iteraciones?
Atribución	¿Contribuye cada uno de los tres principios, y cómo se compensan entre sí?
Generalización	¿El harness evolucionado logra generalización a tareas held-out y a modelos base, en vez de sobreajustarse a las tareas de búsqueda?

9.1 Setup

Benchmark. La evolución se realiza sobre SWE-Bench Verified (Jimenez et al. 2024a), un subconjunto validado por humanos de 500 tareas de SWE-Bench que cubren issues reales de repositorios Python.

Para evaluar explícitamente la generalización, se muestrean al azar 50 tareas como conjunto de evolución y se expone el proceso de evolución solo a esas tareas. Las 450 tareas restantes se mantienen no vistas y se usan únicamente para evaluación.

Se reportan resultados sobre ambos splits: el rendimiento sobre el conjunto de evolución refleja el progreso de optimización, mientras que el rendimiento sobre el conjunto held-out revela si el harness evolucionado transfiere más allá de las tareas de búsqueda.

Métricas. Siguiendo el setup de AHE (Lin et al. 2026), se reporta Pass@1, la tasa binaria media de éxito sobre k rollouts por tarea, porque un harness útil debería permitir que el agente resuelva tareas en su primer intento. Se agregan resultados sobre las 500 tareas usando un promedio a nivel de tarea, donde cada tarea contribuye por igual al score Total.

Junto a Pass@1 se reporta el número de turnos (Turns) de evolución requeridos por cada método para obtener su harness final, ya que cada turno implica evaluación del harness evolucionado, y una evolución eficiente debería producir un harness fuerte en menos turnos.

Modelos. El agente de código, el analizador de trayectorias, el agente de feedback y el meta-agente comparten todos un modelo base: GPT-5.4 (OpenAI 2025). Compartir un modelo asegura que cualquier ganancia medida sea atribuible a la evolución del harness, no a un meta-agente o analizador más fuerte.

Todas las corridas son en modo no-thinking para aislar el efecto del diseño del harness, ya que el razonamiento extendido provee una fuente adicional de rendimiento que podría enmascarar las ganancias de la evolución del harness.

Para el estudio cross-model, se congela el harness evolucionado con GPT-5.4 y se lo re-evalúa sobre Claude-Sonnet-4.6 (Anthropic 2025), también en modo no-thinking, sin ninguna evolución adicional.

Baselines. Se compara contra dos baselines bajo las mismas condiciones experimentales:

1. La semilla libre de harness H₀, un harness mínimo con solo un comando de shell como herramienta y sin middleware, skills ni sub-agentes, que mide el rendimiento del modelo base antes de la evolución.
2. La evolución automática de harnesses, representada por AHE (Lin et al. 2026), un método SOTA de evolución de harness.

9.2 Resultado principal

HarnessCompass evoluciona un harness más fuerte en muchos menos turnos.

Tabla 1 — Resultados principales sobre SWE-Bench Verified con GPT-5.4 (modo no-thinking). Todas las columnas son Pass@1: Sample sobre el conjunto de evolución de 50 tareas, Held-Out sobre las 450 tareas disjuntas nunca vistas durante la evolución, y Total el score ponderado por tarea sobre las 500 tareas. Turns es el número de iteraciones de evolución necesarias para alcanzar el harness reportado. Mejor en negrita.

Método	Sample	Turns	Held-Out	Total
H₀ (semilla)	54.0 %	0	51.6 %	51.8 %
AHE	63.0 %	20	54.7 %	55.5 %
HarnessCompass	66.0 %	5	60.4 %	61.0 %

Partiendo del harness semilla en 54,0 %, HarnessCompass mejora Pass@1 sobre el sample de evolución a 66,0 %, superando a AHE por 3 puntos mientras requiere solo 5 turnos de evolución comparados con los 20 de AHE.

La brecha se ensancha sobre las tareas held-out, donde HarnessCompass puntúa 60,4 % contra 54,7 % de AHE, así que su score total ponderado por tarea sobre las 500 tareas sube a 61,0 % contra 55,5 % de AHE y 51,8 % de la semilla.

Como todos los agentes de rol comparten un modelo base y ambos métodos automáticos parten del idéntico H₀, este margen aísla el efecto de las ediciones que el bucle compromete al harness.

La ventaja es más evidente en las tareas held-out. La brecha de rendimiento entre los dos métodos es sustancialmente mayor sobre las tareas held-out (5,7 puntos) que sobre el sample de evolución (3,0 puntos), resaltando la generalización más fuerte de HarnessCompass.

Esta mejora proviene de la compuerta de generalización, que impone ediciones agnósticas a la tarea y permite que las mejoras descubiertas sobre el conjunto de evolución generalicen a tareas no vistas. Más allá de mejorar la generalización, la compuerta también mejora la eficiencia evolutiva al impedir que el bucle gaste iteraciones en adaptaciones específicas de tarea que fallan en generalizar.

9.3 Eficiencia evolutiva

HarnessCompass sube más rápido y se asienta más alto.

La curva de Pass@1 por iteración sube empinada y alcanza su pico alrededor de la iteración 6, mientras que AHE mejora despacio y se nivela por debajo recién después de unas 20 iteraciones.

Dos mecanismos explican este comportamiento:

1. La compuerta de generalización mantiene las ediciones transferibles, así que el harness sube sin la devolución que causan los fixes por tarea cuando se revierten.
2. R³ pliega de vuelta las ediciones útiles de la pista perdedora en cada ronda, así que cada iteración compone en vez de descartar la mitad de su exploración.

Como resultado, HarnessCompass no solo alcanza mayor rendimiento final sino que llega ahí en aproximadamente una cuarta parte de las iteraciones de AHE.

Las tres ediciones que marcan los saltos de la curva son concretas, y ninguna es específica de una tarea:

Iteración	Edición	Componentes
~3	Normalizador canónico de límites + smoke check read-after-write	prompt + herramienta
~5	Guardia de veredicto de parche: bloquear la finalización si la validación falla	middleware
~9	Runner de tests en venv aislado + routing de fallas de runtime	herramienta + middleware

9.4 Estudio de ablación

Para atribuir las ganancias a los tres principios en vez de al bucle de evolución como un todo, se realiza una ablación progresiva partiendo del harness semilla e introduciendo un principio a la vez mientras se mantiene el bucle fijo. Primero se agrega la compuerta de generalización, después el feedback proactivo, y finalmente la integración R³, de modo que cada fila mide la contribución marginal de un principio sobre los anteriores.

Tabla 2 — Ablación sobre HarnessCompass. Cada principio es acumulativo con los de arriba.

Configuración	Sample	Turns	Held-Out	Total
H₀ (semilla)	54.0 %	0	51.6 %	51.8 %
+ Compuerta de generalización	62.0 %	2	58.4 %	58.8 %
+ Feedback proactivo	66.0 %	12	55.8 %	56.8 %
+ Integración R³	66.0 %	5	60.4 %	61.0 %

Cada principio contribuye, y sus efectos son complementarios.

• La compuerta de generalización sola mejora la semilla de 54,0 % a 62,0 % en solo dos turnos, mientras sube Pass@1 held-out de 51,6 % a 58,4 %. Esto confirma que restringir las ediciones a cambios agnósticos a la tarea es crucial para transferir mejoras más allá del conjunto de evolución.

• Agregar feedback proactivo eleva aún más Pass@1 sobre el conjunto de evolución a 66,0 %, ya que la señal más rica en primera persona revela oportunidades de mejora que los resultados de trayectoria por sí solos no pueden exponer. Sin embargo, sin salvaguardas esta ganancia viene al costo de la generalización: Pass@1 held-out cae a 55,8 % y los turnos suben a 12, lo que sugiere que las ediciones guiadas por feedback pueden sobreajustarse al conjunto de evolución.

• La integración R³ resuelve esta tensión: mantiene el score de 66,0 % sobre el sample mientras restaura Pass@1 held-out a 60,4 % y reduce los turnos a 5. Al reconciliar las dos pistas de componentes, R³ preserva las ganancias complementarias mientras remueve las ediciones redundantes o no transferibles.

En conjunto, los tres principios juegan roles complementarios: la compuerta promueve la transferencia, el feedback expande la señal de optimización, y R³ preserva la generalización mientras mejora la eficiencia evolutiva.

9.5 Generalización a tareas held-out y a modelos base

La columna held-out de la Tabla 1 establece la primera dimensión de generalización al mostrar que, bajo el mismo modelo base, el harness evolucionado transfiere a tareas no vistas y estrecha sustancialmente la brecha sample-a-held-out.

Una pregunta más difícil es si el harness también transfiere a través de modelos base, ya que un harness optimizado para los comportamientos de un modelo puede no beneficiar a otro. Para evaluarlo, se congela el harness evolucionado con GPT-5.4 y se lo re-evalúa sobre Claude-Sonnet-4.6 en modo no-thinking sin evolución adicional, comparando cada modelo base contra su propia semilla.

Tabla 3 — Resultados de transferencia cross-model. Ours se refiere a HarnessCompass. El harness evolucionado con GPT-5.4 se congela y se evalúa sobre Claude-Sonnet-4.6 sin evolución adicional. Cada modelo base se compara contra su harness semilla solo-bash.

Modelo base	Harness	Sample	Held-Out	Total
GPT-5.4	H₀	54.0 %	51.6 %	51.8 %
GPT-5.4	Ours	66.0 %	60.4 %	61.0 %
Claude-Sonnet-4.6	H₀	68.0 %	70.2 %	70.0 %
Claude-Sonnet-4.6	Ours	76.0 %	73.6 %	73.8 %

El harness congelado mejora un modelo sobre el que nunca evolucionó.

Sobre Claude-Sonnet-4.6, el harness congelado mejora Pass@1 total de 70,0 % a 73,8 %, con ganancias tanto sobre el conjunto de evolución (de 68,0 % a 76,0 %) como sobre el split held-out (de 70,2 % a 73,6 %), a pesar de que el harness fue evolucionado únicamente a partir de GPT-5.4.

Este resultado sugiere que HarnessCompass aprende mejoras de ingeniería reutilizables más que fixes específicos del modelo o de la tarea.

La transferencia es positiva pero despareja. El harness transfiere positivamente en agregado, dando +3,8 puntos de ganancia total, y mejora astropy en 18,1 puntos. Aun así, las ganancias no son uniformes: pytest cae 10,5 puntos y sphinx 4,5 puntos, a pesar de que el harness semilla ya rendía fuertemente sobre esos repositorios para este modelo (84,2 % y 65,9 % respectivamente).

Esto sugiere que algunos mecanismos evolucionados con GPT-5.4 pueden ser innecesarios para un modelo base más fuerte. Los autores consideran por lo tanto la transferencia agregada como el resultado principal.

9.6 Dónde caen las ganancias entre repositorios

El Total agregado oculta un benchmark heterogéneo, ya que SWE-Bench Verified abarca doce repositorios cuyos conteos de tareas van de 231 hasta una sola tarea. Para ver si el harness evolucionado ayuda ampliamente o meramente levanta unos pocos repositorios grandes, se desglosa Pass@1 por repositorio para ambos modelos base.

Tabla 4 — Pass@1 por repositorio (%) sobre el benchmark completo de 500 tareas de SWE-Bench Verified. H₀ denota el harness semilla solo-bash, Ours el mejor harness evolucionado por HarnessCompass; Δ reporta su diferencia en puntos porcentuales, con los valores positivos en negrita. Los repositorios están ordenados por conteo de tareas n. El harness se evoluciona una vez con GPT-5.4, después se congela y se evalúa sobre Claude-Sonnet-4.6 sin evolución adicional; así, los resultados de Claude miden transferencia a un modelo base no visto durante la optimización.

Repositorio	n	GPT-5.4 H₀	GPT-5.4 Ours	Δ	Claude-4.6 H₀	Claude-4.6 Ours	Δ
django/django	231	59.3	70.1	+10.8	73.2	78.8	+5.6
sympy/sympy	75	47.3	52.0	+4.7	68.0	73.3	+5.3
sphinx-doc/sphinx	44	35.2	58.0	+22.8	65.9	61.4	−4.5
matplotlib/matplotlib	34	38.2	44.1	+5.9	61.8	64.7	+2.9
scikit-learn/scikit-learn	32	73.4	68.8	−4.6	93.8	93.8	±0.0
pydata/xarray	22	59.1	63.6	+4.5	81.8	86.4	+4.6
astropy/astropy	22	36.4	40.9	+4.5	45.5	63.6	+18.1
pytest-dev/pytest	19	52.6	68.4	+15.8	84.2	73.7	−10.5
pylint-dev/pylint	10	15.0	30.0	+15.0	30.0	30.0	±0.0
psf/requests	8	12.5	12.5	±0.0	12.5	12.5	±0.0
mwaskom/seaborn	2	0.0	25.0	+25.0	50.0	50.0	±0.0
pallets/flask	1	100.0	100.0	±0.0	100.0	100.0	±0.0
Total	500	51.8	61.0	+9.2	70.0	73.8	+3.8

Todos los resultados se computan con k = 2 rollouts sobre el benchmark completo de 500 tareas. Así, un repositorio con n tareas contribuye 2n trials, y su Pass@1 se cuantiza en incrementos de 1/(2n). La fila Total reporta la media ponderada por tarea sobre las 500 tareas y por lo tanto coincide con los totales de la Tabla 1.

Las ganancias son ampliamente distribuidas y concentradas en repositorios sensibles al harness. Sobre GPT-5.4, el harness evolucionado mejora o iguala cada repositorio con más de un puñado de tareas, y las ganancias más grandes caen exactamente donde el harness semilla es más débil y la estructura de tarea es más sensible al harness:

• sphinx-doc salta de 35,2 % a 58,0 %
• pytest-dev de 52,6 % a 68,4 %
• django, el repositorio más grande, de 59,3 % a 70,1 %

Como estos repositorios ejercitan los bucles multi-paso de editar-y-verificar que las herramientas y el middleware evolucionados atacan, el harness tiene el mayor margen para ayudar ahí, mientras que sobre scikit-learn, donde el harness semilla ya es fuerte con 73,4 %, el score apenas se mueve.

La ganancia es amplia pero concentrada en repositorios grandes. Bajo GPT-5.4, el harness evolucionado mejora ocho de los doce repositorios, queda sin cambio en tres y regresa en uno. La mejora no está impulsada por un puñado de repositorios pequeños: django, que por sí solo aporta 231 de las 500 tareas, gana 10,8 puntos, mientras que sympy, el segundo más grande con 75 tareas, gana 4,7 puntos. Juntos, estos dos repositorios representan el 61 % del benchmark y por lo tanto contribuyen sustancialmente a la ganancia general de +9,2.

Este patrón es precisamente lo que la evolución restringida está diseñada para lograr: un harness que meramente memorizara su conjunto de evolución de 50 tareas no generalizaría para mejorar sustancialmente un repositorio de 231 tareas que rara vez encontró durante la evolución.

Los repositorios pequeños tienen resolución estadística limitada. Los repositorios más chicos — psf (8 tareas), mwaskom (2 tareas) y pallets (1 tarea) — tienen resoluciones de Pass@1 de 6,25, 25 y 50 puntos porcentuales respectivamente. Como resultado, un solo trial que cambie puede producir una diferencia mayor que la mayoría de los efectos subyacentes.

La ganancia de +25,0 en mwaskom corresponde a un solo éxito adicional entre cuatro trials, mientras que las entradas de ±0,0 solo indican que ningún trial cambió. Los autores incluyen estas filas por completitud pero advierten contra sobre-interpretarlas; lo mismo aplica a pallets, cuya única tarea es resuelta por ambos modelos bajo cualquier harness.

---

10. Caso de estudio: cuando la evolución sin compuerta premia el sobreajuste

El score agregado por sí solo no revela si la evolución descubrió competencia de ingeniería reutilizable o meramente memorizó soluciones para las tareas vistas durante la evolución. Por eso los autores inspeccionan los artefactos que la evolución deja atrás. Esto provee un chequeo mecanicista cualitativo sobre el rol de la compuerta de generalización, en vez de tratar Pass@1 como evidencia de generalización por sí mismo.

10.1 Dos clases de memoria acumulada

El contraste entre las corridas sin compuerta (ungated) y con compuerta (gated) es cualitativo pero pronunciado.

En la corrida sin compuerta, la memoria acumulada está dominada por recetas específicas de tarea. Entradas representativas:

django__django-13158 regressed because guidance drifted toward
shape-preserving QuerySet.none() rewrites. For combined queries,
emptiness must propagate into combined_queries ...

sympy__sympy-14711 showed arithmetic protocol bugs must be fixed at the
direct failing operator entry point. If A.x + 0 fails, patch Vector.__add__
first ...

Estas entradas referencian explícitamente instancias del benchmark y detalles privados de implementación. Por lo tanto pueden servir como claves de respuestas compactas: cuando se encuentra la misma tarea o una estrechamente relacionada, la memoria indica directamente dónde editar y qué comportamiento implementar.

Sin embargo, su estabilidad aparente no implica por sí misma que el harness haya aprendido un método robusto; el harness puede simplemente estar recuperando repetidamente soluciones codificadas de sus tareas de evolución.

En contraste, la corrida con compuerta registra principios generales junto con condiciones explícitas de aplicabilidad. Por ejemplo:

Regla de propiedad del camino de ejecución (execution-path ownership rule). Aplicabilidad: cuando varias capas cercanas podrían plausiblemente parchearse, rastreá el valor que falla hasta la función que realmente lo emite, y parcheá ese propietario en vez de un helper aguas arriba o un formateador aguas abajo.

Regla de alcance por conteo de consumidores (consumer-count scope rule). Aplicabilidad: cuando elegís entre un fix local y un cambio de abstracción compartida, reescribí el helper compartido solo cuando múltiples consumidores comparten el mismo contrato roto; de lo contrario mantené el fix local.

Ninguno de estos principios identifica un repositorio, un número de tarea, un símbolo o un parche esperado. En cambio, cada uno especifica un criterio de decisión que puede evaluarse sobre un codebase no visto.

La cláusula de aplicabilidad es importante: impide que una observación útil sea promovida a una regla incondicional, y hace explícita la frontera de la transferencia.

10.2 Interpretación

Los dos artefactos sostienen una interpretación causal directa de la diferencia de score.

Sin la compuerta, la evolución puede promover soluciones específicas de tarea a contexto global siempre-activo. Esto crea un camino directo desde tareas previamente observadas hacia scores más altos, pero deja el harness resultante fuertemente acoplado al conjunto de evolución y con poca probabilidad de beneficiar tareas no familiares.

En efecto, la evolución sin compuerta cambia memorización específica del benchmark por ganancias aparentes de rendimiento.

La compuerta remueve este atajo al prohibir identificadores de tarea, símbolos específicos de tarea y rutas de archivo, mientras exige que cada lección retenida especifique sus condiciones de aplicabilidad. El artefacto con compuerta por lo tanto codifica conocimiento a nivel de método en vez de un catálogo de parches.

La inspección de la memoria por sí sola no prueba la generalización, ni implica que cada regla con compuerta transferirá exitosamente. Sí, en cambio, descarta la explicación alternativa directa para la ganancia sin compuerta: la ventaja observada puede atribuirse a la naturaleza del artefacto evolucionado, con la corrida sin compuerta almacenando recetas específicas y la corrida con compuerta almacenando criterios de decisión condicionales, cross-task.

En pocas palabras: la memoria sin compuerta responde “cómo modificar django-13158”, mientras que la memoria con compuerta responde “cómo decidir qué capa modificar cuando se viola un contrato compartido”.

La primera puede mejorar el rendimiento sobre el benchmark de evolución mientras funciona como un libro de respuestas; la segunda captura la forma de conocimiento requerida para transferir a tareas no vistas.

Este caso de estudio por lo tanto complementa los resultados held-out y cross-model: la evaluación cuantitativa mide si ocurre la transferencia, mientras que la inspección de artefactos explica por qué una mejora de score sin restricciones no debería interpretarse automáticamente como mayor habilidad general de ingeniería.

---

11. Conclusión

Observando que la evolución automática de harness existente puede sobreajustarse a las tareas de búsqueda, apoyarse en señales a nivel de trayectoria e introducir interferencia al optimizar conjuntamente los componentes del harness, los autores proponen HarnessCompass, que guía la evolución del harness mediante evolución restringida, feedback proactivo y optimización por componente.

Estos tres principios aseguran que las modificaciones del harness permanezcan agnósticas a la tarea, enriquecen la evidencia de trayectorias con feedback en primera persona, y aíslan las pistas de componentes para reducir la interferencia entre componentes.

Como resultado, HarnessCompass logra efectividad y generalización más fuertes que los métodos previos.

Los hallazgos sugieren que la evolución disciplinada es tan importante como la búsqueda en sí misma, motivando trabajo futuro hacia harnesses que sean a la vez efectivos y ampliamente generalizables.

---

12. Trabajo futuro

Los agentes basados en LLM todavía sufren de alucinaciones y comportamientos intermedios no confiables, que pueden ser particularmente dañinos en tareas de horizonte largo.

A diferencia de la generación de un solo paso, las tareas agénticas involucran interacciones extendidas entre razonamiento, uso de herramientas y feedback del entorno, donde una acción errónea temprana o una suposición alucinada puede propagarse a través de pasos subsiguientes y acumularse en una falla final.

Una dirección prometedora es extender la evolución automática de harness hacia el descubrimiento y la mitigación automáticos de tales patrones de falla. Específicamente:

• Los harnesses evolucionados podrían aprender rúbricas generalizables que identifiquen comportamientos intermedios problemáticos del agente asociados con fallas aguas abajo, en vez de depender solo de señales de resultado.
• Basado en esas rúbricas, el harness podría evolucionar además mecanismos correctivos, como filtrado a nivel de trayectoria, generación de feedback dirigido, o modificación de reward, para prevenir la propagación de errores durante la ejecución.

Al reducir las fallas acumuladas y mejorar la calidad de las trayectorias recolectadas, tales harnesses podrían proveer señales de supervisión más fuertes para aprendizaje por refuerzo y habilitar entrenamiento más confiable de agentes de horizonte largo.

---

13. Apéndice A — Los prompts completos

El apéndice del paper presenta los prompts que implementan los componentes del harness introducidos en HarnessCompass, organizados según el principio de diseño que realizan: el harness semilla H₀, la compuerta de generalización para la evolución restringida, el pipeline de cuatro etapas de feedback proactivo en primera persona, y las restricciones de pista junto con el integrador R³ para la optimización por componente.

Todos los prompts se reproducen verbatim, en inglés, tal como están en el paper. Los placeholders Jinja ({{ ws }}, {{ iteration }}) y los campos de formato Python ({pre_json}, {loser_diff}) los instancia el harness en tiempo de ejecución.

A.1 Seed harness H₀

El harness semilla es deliberadamente mínimo: consiste solo de una herramienta de shell y el system prompt de abajo, sin middleware, skills, sub-agentes ni memoria de largo plazo. En consecuencia, cada componente de un harness posterior H_t es introducido por el propio bucle de evolución.

You solve software tasks in a non-interactive setting. Your only tool is
**`run_shell_command`**: use the shell to inspect the repo, edit files, run
builds/tests, and finish the work. Do not ask the user questions.

- Prefer short replies; use the tool for actions.
- Before commands that delete or overwrite important data, state briefly what they do.
- Long-running processes: use `is_background: true` on `run_shell_command` (do not
  use `&` in the command string).

Date: {{ date }}
Username: {{ username }}
Working Dir: {{ working_directory }}

A.2 Compuerta de generalización — requisito de contenido

La compuerta se especifica una sola vez en el system prompt del meta-agente y se impone uniformemente sobre todas las ediciones candidatas de los siete tipos de componentes. Este primer prompt especifica la restricción de contenido: qué puede expresar una edición.

Contiene la lista completa de superficies cubiertas, la prohibición dura (IDs de tarea, nombres de test, símbolos privados, keyword matching, recitaciones), la única categoría permitida (principios reutilizables cross-task con criterio de aplicabilidad), el test de tornasol, y el ejemplo canónico de la diferencia entre una respuesta y un criterio.

## 3. Generalization Gate (applies to EVERY component you author)

Everything the evolve agent writes is GLOBAL context applied to tasks you have never
seen. It must encode a *transferable decision criterion*, never the answer to a
specific observed task.

This gate covers ALL of these surfaces, with no exception:
- `systemprompt.md`
- `LongTermMEMORY.md`
- `skills/**` (SKILL.md and scripts)
- `tool_descriptions.yaml`
- `tools/**` and `middleware/**` Python
- `sub_agents/**` -- including sub-agent's `prompt.md` and `agent.yaml` (a
  sub-agent prompt is a second system prompt -- equally capable of carrying task
  answers)
- `code_agent.yaml`
- Any guidance that instructs the code agent what to record into
  `ShortTermMEMORY.md` (you cannot edit ShortTermMEMORY directly, but you
  must NOT route task-specific seeds into it indirectly via prompt/skill rules)

**HARD BAN -- none of these may appear in ANY surface above:**
- A specific task / instance id (e.g. a `<library>-<number>` benchmark id).
- A specific test function or test-file name (e.g. `test_*`, `tests/.../*.py`).
- A private symbol / function / class / attribute / file path of a *task-under-test*
  codebase.
- Dataset/task/library-specific keyword matching in code -- e.g.
  `if '<repo-or-test-token>' in text:`. Code branches must NOT switch on tokens that
  only appear in specific tasks.
- "Iteration N showed task X needs change Y" recitations -- these are answers, not
  criteria.

**ONLY allowed:** cross-task reusable principles. Each principle MUST carry an
*applicability criterion* the agent can evaluate on an unseen task -- NOT a
conclusion tied to one task.

Litmus test before writing anything, to any surface above: **"Would this still help a
task from a library I have never seen?"** If it names a task/symbol/path,
rewrite it as a criterion or DISCARD it. If it cannot be task-agnostic, it is
not knowledge -- drop it.

WRONG (answer): "widen the `P` format branch to also handle `Q`".
RIGHT (criterion): "When one shared producer feeds a wrong value to several
call-sites, fix the producer; when the value is wrong only in the current local
scenario, keep the fix local and do NOT promote it to the narrowest primitive.
Decide by counting how many consumers depend on the value and whether the broken
invariant is global or local."

A.3 Compuerta de generalización — requisito de ubicación

El segundo prompt especifica la restricción de ubicación: dónde puede residir una edición. Es lo que impide que la guía quede embebida en código ejecutable, y contiene además las reglas específicas para escribir en memoria.

### Structural Changes Must Be Deterministic, Not Advisory

Middleware, tools, and sub-agents are **structural** surfaces. A structural change
must add capability: perform a concrete action -- triggered by a real execution event
-- and return a result the agent cannot obtain directly. Examples: run the narrowest
reproducer/test and surface its exit code and traceback; detect a missing dependency
from stderr and install it; verify a patch actually applied and its imports resolve;
expose a tool that locates the owning module/symbol.

A structural change must NOT merely inject advisory text ("remember to verify the
symmetric owner", "prefer the canonical owner") into the model context. Advice is not
anchored to an observable failure event, so a structural surface that only injects
advice must guess applicability from broad activity signals such as recent shell
commands or edit types. Those signals are shared by many unrelated tasks, making the
component effectively global and allowing it to leak across cases that the
Generalization Gate is meant to keep isolated. If a change's only effect is advice,
it is a **guidance** change, not a structural one: write the criterion to
`systemprompt.md` / `LongTermMEMORY.md`, where it is read once and governed directly
by the gate.

### Writing to Memory

Memory is always-on global context for ALL tasks -- the highest-conflict surface.
Apply the Generalization Gate (Core Principle 3) strictly:
- Each entry is one transferable principle + its applicability criterion. No task ids,
  no task-under-test symbols, no file/test names.
- Before adding, scan existing memory. If the new lesson duplicates or CONTRADICTS an
  existing entry, do NOT stack them -- merge into a single criterion that states
  *when* each side applies. Contradictory per-task rules stacked verbatim (e.g. "fix
  the shared layer" vs "keep the fix local") are a primary cause of conflict; replace
  both with the deciding criterion.
- Prune every iteration: delete task-specific recitations and entries that no longer
  generalize. Fewer, sharper criteria beat many memorized answers.
- Do NOT work around this gate by telling the code agent (via prompt or skill) to
  record task-specific fixes into ShortTermMEMORY at runtime. The gate follows the
  *content*, not the file.

A.4 Paso 1 — Reflexión ciega (pre-veredicto) en primera persona

El veredicto se oculta, impidiendo que la reflexión sea racionalizada retrospectivamente en base a un resultado conocido.

You are the SAME coding agent whose trajectory is shown above. You have just finished
the task and do NOT yet know whether you passed or failed.
Reflect ONLY on how usable the HARNESS was for you (tools, middleware, skills,
long-term memory, system prompt). Report BOTH:
 (a) friction with EXISTING harness features (kind=improve_existing), and
 (b) capabilities you WISHED EXISTED but did not -- a tool/middleware/skill/sub_agent
     the harness does not currently provide that would have helped you
     (kind=new_capability). For (b), describe the missing capability concretely even
     though it is not in the trace yet.
Do not solve the task; assess the harness.

Output ONE JSON object and nothing else:
{
  "phase": "pre",
  "outcome_visible_to_agent": false,
  "harmful_or_missing_harness_features": [
    {"kind": "improve_existing|new_capability",
     "component": "<middleware|tool_impl|tool_desc|skill|prompt|memory|sub_agent>",
     "friction": "...", "desired_change": "...",
     "trace_refs": ["turn_x"], "severity": 1}
  ],
  "one_change_that_would_have_improved_pass_at_1": "...",
  "risks_of_that_change": "..."
}

A.5 Paso 2 — Reflexión con retrospectiva (post-veredicto) y atribución de la falla

El veredicto del verificador y su salida se anexan a este prompt. El campo failure_attribution permite descartar el feedback de una tarea cuando el propio agente reconoce que la falla no fue causada por el harness.

You are the SAME coding agent whose trajectory is shown above. The EXTERNAL verifier
has now run; its verdict and output appear below (you never saw it during the task).
With this hindsight, re-assess the HARNESS usability and attribute the outcome.
Report BOTH friction with EXISTING features (kind=improve_existing) AND capabilities
you wished existed but the harness lacks (kind=new_capability).

Output ONE JSON object and nothing else:
{
  "phase": "post",
  "verifier_result": "pass|fail",
  "failure_attribution": "harness|agent_reasoning|task_ambiguity|environment",
  "harmful_or_missing_harness_features": [
    {"kind": "improve_existing|new_capability",
     "component": "<middleware|tool_impl|tool_desc|skill|prompt|memory|sub_agent>",
     "friction": "...", "desired_change": "...", "trace_refs": ["turn_x"],
     "severity": 1}
  ],
  "recommended_harness_component":
    "<middleware|tool_impl|tool_desc|skill|prompt|memory|sub_agent>"
}

A.6 Paso 3 — Reconciliación de los dos reportes

Los dos reportes se fusionan en un conjunto de ítems con la etiqueta de acuerdo registrada. Esa etiqueta se usa después para computar el score de confianza del patrón agregado.

You earlier produced TWO harness-usability reflections for this same task: a
PRE-verdict one (before you knew the result) and a POST-verdict one (after). They are
shown below. Reconcile them into your final, honest view of harness friction. Keep
only what the trajectory genuinely supports -- EXCEPT new_capability items, which
describe something not yet in the harness and so need only be plausible and motivated
by the trajectory. Preserve each item's kind (improve_existing|new_capability).

PRE_REFLECTION:
{pre_json}

POST_REFLECTION:
{post_json}

Output ONE JSON object and nothing else:
{
  "phase": "final",
  "self_consistency": "pre_post_agree|partial|conflict",
  "final_friction_items": [
    {"kind": "improve_existing|new_capability",
     "component": "<middleware|tool_impl|tool_desc|skill|prompt|memory|sub_agent>",
     "friction": "...", "desired_change": "...", "trace_refs": ["turn_x"],
     "severity": 1}
  ]
}

A.7 Paso 4 — Fundamentación contra la trayectoria y routing a una pista

Esta llamada aplica validación específica por ítem: las quejas sobre componentes existentes requieren evidencia en la traza, mientras que los pedidos de capacidades nuevas solo necesitan atender un hueco revelado por la traza.

Además asigna los ítems sobrevivientes a pistas de grano grueso y reclasifica los ítems estructurales cuyo desired_change sigue siendo una instrucción de prompt, tratándolos como guía en vez de como consejo codificado.

Below is a coding agent's self-reported harness friction for the task whose
trajectory is shown above. The agent's complaints are CANDIDATE EVIDENCE ONLY -- do
not trust them blindly. Apply the right test per item kind:
 - kind=improve_existing: REQUIRES concrete supporting evidence in the trajectory.
   DROP it if the trace does not support it.
 - kind=new_capability: describes a capability the harness does not have yet, so it
   cannot appear in the trace. KEEP it only if the trajectory shows a gap that such a
   capability would plausibly have addressed; cite the turns showing that gap.
For each SURVIVING item, copy its kind/friction/desired_change/severity verbatim and
cite the supporting turns. Then assign a coarse `track` -- NOT a specific component:
 - track=structural: the friction can be addressed by a deterministic code mechanism
   (middleware, a tool's implementation, or a sub-agent). Choose this whenever code
   could enforce/observe/return the missing thing. Do NOT pick a specific component --
   that decision belongs downstream.
 - track=guidance: the fix is INHERENTLY a cross-task principle that cannot be
   enforced by code (pure prose guidance / a recorded lesson).
Classify NEUTRALLY by the friction's true nature -- do NOT bias toward either track.
Pick structural ONLY when a deterministic code mechanism can genuinely
enforce/observe/return the missing thing; pick guidance when the fix is inherently a
cross-task principle. A friction phrased as 'tell me'/'make it clearer' is guidance
UNLESS code could actually enforce it. Each item goes to exactly the one track that
truly fits.
CRITICAL REWRITE RULE for track=structural items: the downstream structural variant
may ONLY edit code (middleware / tool implementations / sub_agents) and is FORBIDDEN
from touching system prompt / memory / docs. So you MUST rewrite `desired_change` as
a concrete CODE ACTION with NO prompt/doc wording. Forbidden phrasings in a
structural desired_change: 'tell/remind the agent', 'clarify in the prompt',
'document', 'instruct', 'note that', 'make it clear'. Required style: name the code
mechanism + observable effect -- e.g. 'middleware: on stderr match X, auto-run Y and
inject its result before next turn', 'shell tool: detect missing dependency and
return install hint in tool output', 'sub-agent: validate patch applied & imports
resolve, return pass/fail'. If a structural friction genuinely CANNOT be expressed as
a code action (only as prose advice), then it is NOT structural -- reclassify it as
track=guidance instead. Never allow a structural item whose desired_change reads like
a prompt instruction.

FRICTION_ITEMS:
{items_json}

Output ONE JSON object and nothing else:
{
  "grounded_items": [
    {"kind": "improve_existing|new_capability", "friction": "...",
     "desired_change": "...", "severity": 1, "trace_refs": ["turn_x"],
     "track": "structural|guidance"}
  ]
}
Include only items that pass the test above. If none survive, return an empty list.

A.8 Evidencia agregada en primera persona, inyectada en la query de evolución

El agrupamiento y el scoring de confianza siguen un procedimiento fijo sin llamadas adicionales al modelo. El bloque resultante se inserta en la query de evolución del meta-agente y se filtra por la pista accesible a la variante actual.

Su encabezado impone explícitamente el rol subordinado de esta evidencia respecto de la trayectoria.

## Agent-Experience Evidence (code-agent self-reported friction, trace-verified)

**Status of this evidence**: this is the code agent's SUBJECTIVE self-report of
harness friction. It is a KNOWLEDGE REFERENCE / SUPPLEMENT only. The Agent Debugger
analysis (section 4 above) and the raw trajectory are the more OBJECTIVE, primary
sources -- when they conflict with this section, trust them over this. Use this
section to enrich your understanding of WHY the harness felt hard to use, not as a
standalone mandate.

Candidate-evidence ONLY: each item was self-reported by the code agent (same model,
blind pre-verdict + post-verdict reconciled) and then verified against the
trajectory; unsupported claims were dropped. You MUST still confirm via trajectory
and the falsification loop.

**Generalize, never copy**: the friction text may mention specific tasks/symbols/
files. Do NOT encode those into any component (no keyword-matching, no per-task
dispatch, no hardcoded names). Extract only the cross-task mechanism -- the fix must
help tasks you have never seen. See the Generalization Gate.

**You choose the component**: each pattern carries only a coarse `track` (structural
or guidance) -- NOT a specific component. Like the Agent Debugger analysis, this
gives you evidence, not a prescription. Within your variant's allowed track you
decide the best component yourself (structural -> middleware / tool_impl /
sub_agent; guidance -> systemprompt / memory / skill / tool_desc).

**HARD TRACK BOUNDARY (never cross it)**: choose freely AMONG the components of your
OWN track, but you may NEVER edit a component of the other track. [...]

**DETERMINISTIC-NOT-ADVISORY** (structural track): if a candidate_fix reads like
advice ('surface X', 'tell the agent Y', 'document Z'), do NOT satisfy it by editing
system prompt / memory -- that is guidance dressed up as a fix. Re-express it as a
deterministic mechanism (middleware that auto-injects the missing context/dependency,
a tool whose code now returns the missing result, a sub-agent). A prompt edit that
merely restates the friction tends to be INEFFECTIVE.

- [P-structural] track=structural, kind=improve_existing+new_capability,
  confidence 0.87, 4 task(s), 6 grounded item(s).
  Candidate fix (you choose the component): {candidate_fix}
  tasks: {affected_tasks}
  feedback_ids: {feedback_ids}

If you act on a pattern, cite its feedback_ids in the manifest's
`agent_feedback_evidence` and set `feedback_confidence` to its confidence.

A.9 Restricción de la variante estructural

Cada ronda corre dos meta-agentes en paralelo sobre la misma evidencia, diferenciándose solo en la restricción obligatoria anexada a sus queries de evolución. Como las dos restricciones particionan los siete tipos de componentes, las variantes resultantes editan archivos disjuntos y no pueden interferir entre sí dentro de una ronda.

You MUST focus on STRUCTURAL changes: middleware, tool implementations, or
sub-agents. Do NOT modify system prompt or skill content this iteration. CRITICAL --
the Generalization Gate applies to ALL structural surfaces: they must be GENERIC
mechanisms that work on tasks you have never seen. FORBIDDEN: any code branch that
keyword-matches task/test/library-specific strings (e.g. `if "<token>" in text`) and
any hardcoded per-task dispatch. If you cannot describe the mechanism without naming
a specific task, it is task-specific hacking -- do not write it.

DETERMINISTIC-NOT-ADVISORY: a structural change must alter what the agent
DETERMINISTICALLY DOES and return an observable result the agent cannot obtain
directly -- e.g. auto-run the narrowest reproducer/test and surface its exit code &
traceback, auto-detect-and-install missing dependencies, deterministically validate
that a patch applied and imports resolve, add a new tool that locates the owning
module/symbol.
If a structural change's ONLY effect is to inject advisory text into the model
context ("remember to verify X", "prefer the canonical owner", a decision criterion
in prose), it is NOT a structural change -- it is guidance dressed up as a structural
change; discard it rather than writing it as code.

A.10 Restricción de la variante de guía

You MUST focus on GUIDANCE changes: system prompt rules, skill packages, tool
descriptions, or LongTermMEMORY. Do NOT create or modify middleware Python files this
iteration. CRITICAL: every rule you write is global context for tasks you have never
seen. Write only cross-task principles, each with an explicit applicability criterion
(when it applies / when it does not) -- never a recitation of a specific task's fix,
symbol, file path, or test name. Before adding to memory, merge or prune contradictory
per-task rules into a single deciding criterion. Do NOT instruct the code agent to
record task-specific fixes into ShortTermMEMORY. If a lesson cannot be made
task-agnostic, discard it.

A.11 Auto-chequeo de frontera de pista

Se anexa a ambas variantes.

You are one of multiple parallel evolve agents. Each agent is assigned a different
strategy direction.
**Your assigned constraint**: {strategy_hint}
You MUST follow this constraint. Violations will waste this variant's exploration
budget.

**Hard boundary + self-check**: STRUCTURAL variant edits ONLY middleware / tool code /
sub_agents and NEVER systemprompt.md / *MEMORY.md / tool_descriptions / skills.
GUIDANCE variant edits ONLY systemprompt / memory / skills / tool_descriptions and
NEVER middleware / tool code / sub_agents. Within the component, you may freely choose
the component, but you may NOT cross to the other side. Before writing
change_manifest.json, verify every edited file is on your side; if any is on the other
side, REVERT it (or re-express the intent within your side) -- do not report a
cross-boundary edit.

A.12 Integrador R³

Después de evaluar ambas variantes, la fusión se realiza en un git worktree ramificado desde el ganador, haciendo que las ediciones del ganador sean la base inmutable y el diff del perdedor el único material candidato. El prompt siguiente conduce Revisión, Recombinación y Refinamiento en una sola pasada.

# R3 Integration -- combine two evaluated harness variants into one

You are the R3 Integrator. This iteration ran TWO harness variants in parallel, each
constrained to a different track:
- variant {winner_idx} (WINNER, pass@1 {winner_rate}) -- the higher-scoring variant
- variant {loser_idx} (loser, pass@1 {loser_rate}) -- the lower-scoring variant

The two variants edited DIFFERENT, non-overlapping component tracks (one structural:
middleware/tool_impl/sub_agent; the other guidance: prompt/skill/tool_desc/memory).
Winner-take-all throws the loser's work away every round. Your job is to salvage the
loser's genuinely useful, independent changes ON TOP OF the winner -- so the result is
>= winner, never worse.

Your workspace `{ws}/` ALREADY CONTAINS THE WINNER's full changes as the base. Do NOT
undo them. You only ADD selected loser changes and then simplify.

## The loser's changes (candidate material to fold in)
{loser_manifest}

## The loser's diff (what it actually changed)
{loser_diff}

## Per-variant evaluation evidence (which tasks each flipped / regressed)
{eval_evidence}

## Do exactly three steps, in ONE pass, writing into `{ws}/`

### 1. Revision (judge the loser's changes)
Go through the loser's changes ONE BY ONE -- enumerate EVERY change in the
manifest/diff, do not stop after the first obvious one. For each, decide KEEP or DROP
using the evidence, and record your verdict for every change:
- KEEP only if it looks like an INDEPENDENT positive contribution (plausibly helped
  tasks, does not duplicate or contradict a winner change).
- DROP if it looks like a regression source, is task-specific hacking, or you cannot
  tell it helped. When unsure, DROP -- the winner base already stands on its own;
  adding doubtful changes only risks lowering it. Multiple independent good changes
  can and should ALL be kept -- do not artificially cap to one. The loser explored a
  whole track; salvage everything genuinely useful.

### 2. Recombination (apply kept loser changes onto the winner base)
Apply the KEEP changes into `{ws}/`. Because the tracks are orthogonal they should
rarely touch the same file as the winner. If a loser change DIRECTLY conflicts with a
winner change, the winner wins -- skip the loser one.

### 3. Refinement (Occam's razor -- remove redundancy)
Do NOT wait for redundancy to be obvious -- actively HUNT for it. Concretely: walk
EACH advisory item now in the combined harness (every systemprompt rule, every memory
entry, every tool_description note) and ask: "is this behavior ALREADY enforced
deterministically by some middleware / tool_impl in this same harness?" If yes, that
advisory item is redundant -- DELETE it. Two changes are redundant when they do the
SAME job even in different files with no mere conflict. When redundant, KEEP the more
DETERMINISTIC one and DELETE the advisory one -- regardless of which variant (winner
or loser) it came from.

This keeps prompts/memory from bloating over rounds (a real failure mode in past
runs). Still: only delete on a CONFIRMED duplicate -- if you cannot point to the
specific component that already covers it, keep both. The bar is "I can name what
makes this redundant", not "delete freely".

## Constraints
- Stay within the Generalization Gate: no task/test/symbol-specific content.
- Do NOT modify LLM config, tracer, verifier, or any infrastructure.
- Preserve every capability that is not a confirmed duplicate.
- NOTE ON THE SYSTEM-PROMPT RULE "do not delete ORIGINAL system prompt rules": that
  protects ITERATION-1 baseline rules. In Refinement you MAY delete a rule that THIS
  iteration's variants just added if it is a confirmed duplicate of a more
  deterministic component -- that is the whole point of this step. Never delete
  iteration-1 baseline rules.

## Deliverable
This is an INTEGRATION task, not a normal evolution step. Write the manifest as
`{ws}/integration_manifest.json`:
{
  "base": "winner variant {winner_idx}",
  "kept_from_loser": [ {"change": "...", "why": "..."} ],
  "dropped_from_loser": [ {"change": "...", "why": "..."} ],
  "removed_as_redundant": [ {"change": "...", "kept_instead": "...", "why": "..."} ]
}
Then commit all changes in `{ws}/`.

A.13 Esquema del manifiesto de cambios

Cada edición del meta-agente se registra en un manifiesto legible por máquina, que la ronda siguiente usa para atribuir cambios de score a ediciones individuales y determinar rollbacks. Los dos campos finales enlazan cada edición con la evidencia de feedback en primera persona que la motivó, permitiendo medir con qué frecuencia el feedback proactivo lleva a cambios comprometidos.

{
  "iteration": "{{ iteration }}",
  "changes": [
    {
      "id": "chg-1",
      "type": "new|improvement|rollback",
      "description": "What was changed and why",
      "files": ["relative/to/workspace/file.py"],
      "failure_pattern": "The failure class this addresses",
      "predicted_fixes": ["task-name-a", "task-name-b"],
      "risk_tasks": ["task-name-c"],
      "constraint_level": "middleware|tool_impl|tool_desc|skill|prompt",
      "why_this_component": "Why this component level was chosen over alternatives",
      "agent_feedback_evidence": [],
      "feedback_confidence": 0.0
    }
  ]
}

agent_feedback_evidence / feedback_confidence (OPCIONAL, solo cuando hay Agent-Experience Evidence): si este cambio actúa sobre un patrón de fricción auto-reportado, hay que listar los feedback_ids de ese patrón y copiar su confidence. Esto es EVIDENCIA CANDIDATA que solo SUPLEMENTA la evidencia de trayectoria — nunca un sustituto. Un cambio igual requiere trajectory_evidence real y debe pasar el bucle de falsación; ambos campos se dejan vacíos ([] / 0.0) para los cambios no motivados por feedback.

---

14. Lectura propia: qué te llevás a tu harness manual

Esta sección no es del paper. Es mi lectura aplicada de sus principios al harness que mantenés a mano — el AGENTS.md, el CLAUDE.md, tus scripts, tus hooks.

Aunque no vayas a montar nunca un bucle de evolución automática, los principios son directamente accionables:

1 · Poné una compuerta de generalización sobre vos mismo. Antes de agregar una regla a tu archivo de instrucciones o a la memoria de tu agente, aplicá el test de tornasol del paper: ¿esto seguiría ayudando en un repo que nunca vi? Si nombra un archivo, un test o un símbolo específico, reescribilo como criterio o descartalo. Y hacé que cada regla lleve su condición de aplicabilidad, no solo la conclusión.

2 · Separá capacidad de consejo. Si un problema se puede resolver con un mecanismo determinista — un script que corre los tests, un hook que valida el parche, una herramienta que localiza el módulo dueño de un símbolo — escribí el mecanismo, no el recordatorio. El consejo tiene que adivinar cuándo aplica; el código no. El paper es tajante: “un prompt edit que meramente reformula la fricción tiende a ser INEFECTIVO”.

3 · Preguntale al agente, no solo mires el resultado. Después de una sesión fallida, pedile al agente que reporte dónde el harness le hizo fricción y qué capacidad le hubiera gustado tener. Pero pedilo antes de decirle si pasó o falló, y después contrastá lo que dijo contra lo que realmente hizo. Un reporte en primera persona sin fundamentar es solo una afirmación.

4 · Atribuí la falla antes de tocar el harness. No todo lo que falla es culpa del harness. Distinguir harness / razonamiento del agente / tarea ambigua / entorno evita agregar componentes que no arreglan nada.

5 · Podá la memoria en cada iteración. El bloat de prompts y memoria es un modo de falla real, verificado en corridas previas de los autores. Si una regla en prosa ya está impuesta por un script o un hook, borrá la regla y quedate con el script. “Menos criterios y más filosos le ganan a muchas respuestas memorizadas.”

6 · Fusioná reglas contradictorias en el criterio que decide. Cuando dos lecciones se contradicen (“arreglá la capa compartida” vs “mantené el fix local”), no las apiles. Reemplazá ambas por el criterio que decide cuándo aplica cada una — como la regla de conteo de consumidores del caso de estudio. Las reglas por-tarea apiladas verbatim son, según el paper, una causa primaria de conflicto.

7 · No edites todo a la vez. Si cambiás el prompt, las herramientas y la memoria en la misma pasada y el resultado mejora, no sabés qué funcionó. Y si empeora, tampoco.

---

15. Lectura propia: limitaciones para leerlo con criterio

Esta sección tampoco es del paper. Es mi lectura crítica de sus alcances.

• Es un preprint bajo revisión, sin peer review a la fecha de publicación.
• Un solo benchmark: SWE-bench Verified. Todo el resultado es sobre resolución de issues en repositorios Python; no hay evidencia sobre otros dominios de agentes.
• Conjunto de evolución de 50 tareas, con la varianza que eso implica. Los propios autores advierten explícitamente contra sobre-interpretar los repositorios chicos.
• k = 2 rollouts por tarea. La resolución estadística por repositorio es gruesa: en mwaskom un solo trial que cambia mueve el score 25 puntos.
• La transferencia cross-model es positiva pero despareja: hay repositorios donde el harness congelado empeora al modelo más fuerte (pytest −10,5, sphinx −4,5).
• Los modelos son de una generación concreta (GPT-5.4, Claude-Sonnet-4.6). El propio paper sugiere que un modelo base más fuerte podría no necesitar varios de los mecanismos evolucionados.
• El caso de estudio de la memoria es cualitativo, y los autores lo dicen: la inspección de artefactos no prueba generalización, solo descarta la explicación alternativa más directa.
• No hay costo computacional reportado en términos absolutos. “5 turnos contra 20” es una comparación relativa; cada turno implica correr rollouts sobre el conjunto de evolución con k repeticiones, más las llamadas de feedback por cada tarea fallida.

---

16. Referencias del paper

Bibliografía completa del trabajo original.

• Anthropic. 2025. Claude Sonnet 4.5. https://www.anthropic.com/news/claude-sonnet-4-5. Accedido: 2026-07-28.
• Ben Sghaier, O.; Li, H.; Adams, B.; y Hassan, A. E. 2026. Don’t Blame the Large Language Model: How Agent Harness Evolution Shapes Coding Agent Quality. arXiv:2607.03691.
• Bui, N. D. Q.; et al. 2026. Building Effective AI Coding Agents for the Terminal: Harness, Scaffolding, Context Engineering, and Lessons Learned. arXiv:2603.05344.
• Chakraborty, T.; Ghosh, U.; Zhang, X.; Niloy, F. F.; Dong, Y.; Li, J.; Roy-Chowdhury, A.; y Song, C. 2025. HEAL: An Empirical Study on Hallucinations in Embodied Agents Driven by Large Language Models. En Findings of the ACL: EMNLP 2025, 21226–21243.
• Evers-Hood, W.; Nair, H.; Brookes, P.; Voskanyan, V.; Giavrimis, R.; Truscott, M.; Ilieva, M.; Pavlou, C.; Staicu, A.; Adham, M.; Gong, J.; Zhang, K.; Fedoseev, M.; Sharma, V.; Bauer, R.; Wang, Z.; Jie, W.; Xu, T.; Constantin, A.; Kanthan, L.; y Basios, M. 2025. Evolving Excellence: Automated Optimization of LLM-based Agents. arXiv:2512.09108.
• Gao, H.-a.; Geng, J.; Hua, W.; Hu, M.; Liu, H.; Liu, S.; Qiu, J.; Qi, X.; Wu, Y.; Wang, H.; Xiao, H.; Zhou, Y.; Zhang, S.; Zhang, J.; Xiang, J.; Fang, Y.; Zhao, Q.; Liu, D.; Ren, Q.; Qian, C.; Wang, Z.; Wu, Q.; Ji, H.; y Wang, M. 2025. A Survey of Self-Evolving Agents: What, When, How, and Where to Evolve on the Path to Artificial Super Intelligence. arXiv:2507.21046.
• Hu, S.; Lu, C.; y Clune, J. 2025. Automated Design of Agentic Systems. En ICLR.
• Jimenez, C. E.; Yang, J.; Wettig, A.; Yao, S.; Pei, K.; Press, O.; y Narasimhan, K. 2024a. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? En ICLR.
• Jimenez, C. E.; Yang, J.; Wettig, A.; Yao, S.; Pei, K.; Press, O.; y Narasimhan, K. 2024b. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? En ICLR.
• Lee, J.; Nair, R.; Zhang, Q.; Lee, K.; Khattab, O.; y Finn, C. 2026. Meta-Harness: End-to-End Optimization of Model Harnesses. arXiv:2603.28052.
• Liang, Y.; Zhu, Y.; Ge, C.; Yang, L.; Shen, Y.; Zheng, B.; y Guo, S. 2026. Learning from the Irrecoverable: Error-Localized Policy Optimization for Tool-Integrated LLM Reasoning. En ACL (Volume 1: Long Papers), 11008–11028.
• Lin, J.; Liu, S.; Pan, C.; Lin, L.; Dou, S.; Xi, Z.; Huang, X.; Yan, H.; Han, Z.; Gui, T.; y Jiang, Y.-G. 2026. Agentic Harness Engineering: Observability-Driven Automatic Evolution of Coding-Agent Harnesses. arXiv:2604.25850. ← el baseline AHE
• Lin, X.; Ning, Y.; Zhang, J.; Dong, Y.; Liu, Y.; Wu, Y.; Qi, X.; Sun, N.; Shang, Y.; Wang, K.; et al. 2025. LLM-based Agents Suffer from Hallucinations: A Survey of Taxonomy, Methods, and Directions. arXiv:2509.18970.
• Ma, H.; Zhang, L.; Song, D.; Hu, L.; Tian, Y.; Yang, J.; Zhou, C.; Li, C.; Jin, Y.; Li, X.; et al. 2026. ActiShade: Activating Overshadowed Knowledge to Guide Multi-Hop Reasoning in Large Language Models. En AAAI, volumen 40, 32419–32427.
• Merrill, M. A.; Shaw, A. G.; Carlini, N.; Li, B.; et al. 2026. Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. arXiv:2601.11868.
• Mialon, G.; Fourrier, C.; Swift, C.; Wolf, T.; LeCun, Y.; y Scialom, T. 2024. GAIA: A Benchmark for General AI Assistants. En ICLR.
• OpenAI. 2025. GPT-5 System Card. https://openai.com/index/gpt-5-system-card/. Accedido: 2026-07-28.
• Ramnath, K.; Zhou, K.; Guan, S.; Mishra, S. S.; et al. 2025. A Systematic Survey of Automatic Prompt Optimization Techniques. En EMNLP.
• Wang, X.; Li, B.; Song, Y.; Xu, F. F.; Tang, X.; Zhuge, M.; Pan, J.; Song, Y.; Li, B.; Singh, J.; Tran, H. H.; Li, F.; Ma, R.; Zheng, M.; Qian, B.; Shao, Y.; Muennighoff, N.; Zhang, Y.; Hui, B.; Lin, J.; Brennan, R.; Peng, H.; Ji, H.; y Neubig, G. 2025. OpenHands: An Open Platform for AI Software Developers as Generalist Agents. En ICLR.
• Wang, Y.; Zhu, H.; Hu, Z.; Yuan, Y.; Chen, Z.; Senthil, S.; Hajishirzi, H.; Tsvetkov, Y.; Dasigi, P.; y Xiao, T. 2026. Rethinking the Evaluation of Harness Evolution for Agents. arXiv:2607.12227.
• Wölflein, G.; Ferber, D.; Truhn, D.; Arandjelović, O.; y Kather, J. N. 2025. LLM Agents Making Agent Tools. arXiv:2502.11705.
• Xia, C. S.; Wang, Z.; Yang, Y.; Wei, Y.; y Zhang, L. 2025. Live-SWE-agent: Can Software Engineering Agents Self-Evolve on the Fly? arXiv:2511.13646.
• Xiang, J.; Zhang, J.; Yu, Z.; Liang, X.; Teng, F.; Tu, J.; Ren, F.; Tang, X.; Hong, S.; Wu, C.; y Luo, Y. 2025. Self-Supervised Prompt Optimization. arXiv:2502.06855.
• Yang, C.; Wang, X.; Lu, Y.; Liu, H.; Le, Q. V.; Zhou, D.; y Chen, X. 2024a. Large Language Models as Optimizers. En ICLR.
• Yang, J.; Jimenez, C. E.; Wettig, A.; Lieret, K.; Yao, S.; Narasimhan, K.; y Press, O. 2024b. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. En NeurIPS.
• Yao, S.; Zhao, J.; Yu, D.; Du, N.; Shafran, I.; Narasimhan, K.; y Cao, Y. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. En ICLR.
• Yu, C.; Wang, Y.; Wang, S.; Yang, H.; y Ming, L. 2026. InfiAgent: An Infinite-Horizon Framework for General-Purpose Autonomous Agents. En Findings of the ACL 2026, 35884–35894.
• Yue, M.; Liu, Z.; Yang, L.; Zhang, J.; Chen, H.; Yao, Z.; Savarese, S.; Xiong, C.; Heinecke, S.; y Wang, H. 2025. ToolLibGen: Scalable Automatic Tool Creation and Aggregation for LLM Reasoning. arXiv:2510.07768.
• Yuksekgonul, M.; Bianchi, F.; Boen, J.; Liu, S.; Huang, Z.; Guestrin, C.; y Zou, J. 2024. TextGrad: Automatic “Differentiation” via Text. arXiv:2406.07496.
• Zhang, H.; Zhang, S.; Li, K.; Zhang, C.; Chen, Y.; Zhang, Y.; Bai, L.; y Hu, S. 2026a. Self-Harness: Harnesses That Improve Themselves. arXiv:2606.09498.
• Zhang, J.; Hu, S.; Lu, C.; Lange, R.; y Clune, J. 2025a. Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents. arXiv:2505.22954.
• Zhang, J.; Xiang, J.; Yu, Z.; Teng, F.; Chen, X.-H.; Chen, J.; Zhuge, M.; Cheng, X.; Hong, S.; Wang, J.; Zheng, B.; Liu, B.; Luo, Y.; y Wu, C. 2025b. AFlow: Automating Agentic Workflow Generation. En ICLR.
• Zhang, L.; Song, D.; Wu, Z.; Chen, Z.; Zhang, C.; Tian, Y.; Ma, H.; Li, C.; Zhou, C.; Li, X.; et al. 2026b. PruneTIR: Inference-Time Tool Call Pruning for Effective yet Efficient Tool-Integrated Reasoning. arXiv:2605.09931.
• Zhang, L.; Song, D.; Wu, Z.; Tian, Y.; Zhou, C.; Xu, J.; Yang, Z.; y Zhang, S. 2025c. Detecting Hallucination in Large Language Models Through Deep Internal Representation Analysis. En IJCAI, 8357–8365.

---

Lecturas complementarias de este tutorial

• Capítulo 1 — Harnesses para agentes de larga duración
• Capítulo 2 — Harness Engineering, el marco de ingeniería
• Capítulo 3 — El viaje de adopción de Mitchell Hashimoto
• Capítulo 4 — Protocolo para agentes: construí tu harness