Agentes al vuelo frente a un harness gobernado

Un equipo de agentes puede producir un informe impecable. Otra pregunta es si ese informe detecta los riesgos que le hemos puesto delante. Y una tercera, todavía más incómoda, es si mañana los volverá a encontrar.

He dedicado horas, créditos y un experimento reproducible en lo esencial a separar estas preguntas. No he intentado demostrar que los agentes generados dinámicamente sean malos; he intentado averiguar qué política ofrece una respuesta fiable cuando hay que comprometerse con un cliente.

La respuesta operativa del estudio es clara: con los datos disponibles, prefiero Claude Opus 5.5 ejecutado en GitHub Copilot CLI y un equipo fixed. Pero la superioridad de esa CLI sobre Claude Code no está demostrada: 76,7 % frente a 76,0 % de recall, con 10 de 10 ejecuciones completadas en ambos casos. Es, en la práctica, un empate.

Tesis de este artículo. Un harness que organiza el trabajo es necesario, pero no suficiente. Un gate de proceso (QA) y un corrector de resultados (QC) son instrumentos diferentes; ambos necesitan validación. La estabilidad de la salida importa tanto como su capacidad de detección.

1. De una licitación ficticia a un benchmark de diez dominios

Empecé con una licitación ficticia de modernización de un sistema comercial de aguas. Introduje deliberadamente 15 defectos y dos controles independientes. Aquella prueba, documentada en “QA no es QC”, era un laboratorio metodológico: distintos perfiles fijos, generados y congelados, tres modelos y un piloto de orquestación delegada. No era el benchmark que analizo aquí.

Ese primer trabajo me enseñó algo más importante que cualquier ranking. Un gate rojo podía ser un falso negativo causado por una cláusula sin identificador; un corrector demasiado permisivo podía premiar un informe que citase indiscriminadamente todas las cláusulas. En aquel conjunto, el estudio histórico comunicaba un KR-20 de 0,25 y variaciones sensibles al endurecimiento del corrector. Son resultados del experimento anterior, no estadísticas recalculadas sobre las 120 ejecuciones de este artículo.

Para no depender de un único pliego, amplié la muestra a diez RFP sintéticas de dominios diferentes: servicios sociales, movilidad, urbanismo, vivienda, energía, bibliotecas, transporte, deportes, mercados y agua. Cada una contenía 15 defectos esperados y dos controles, definidos de antemano para ser contrastados con la salida del auditor.

2. Qué se comparó de verdad: modelo, CLI y política

Código y herramienta: AgentsBenchmarkToolKit en GitHub. El repositorio publica el runner, las políticas de agentes y las utilidades de evaluación; su corpus público actual es nuevo y no contiene los resultados históricos de este artículo.

En el paquete original el campo round toma los valores 1 y 2. Para este reanálisis lo interpreté como versión 01 y versión 02, siguiendo la correspondencia aportada después por el autor: la versión 01 identifica GitHub Copilot CLI; la 02 identifica la herramienta propia del fabricante del modelo. Por ello no deben describirse las 120 filas como 120 proyectos independientes ni las versiones como dos repeticiones homogéneas de una misma herramienta.

En cada combinación comparé tres políticas: dynamic, que diseña el equipo para el caso; fixed, que utiliza un equipo predefinido y revisado; y frozen, que reutiliza un diseño generado durante calibración sin adaptarlo de nuevo. Cada entorno aplica su propia configuración de harness según el protocolo declarado.

Diagrama 1 · Lugar que ocupa el diseño del equipo en cada política. Representación conceptual del protocolo, no un registro de las llamadas internas de cada CLI.

La matriz es 10 RFP × 2 modelos × 2 versiones × 3 políticas = 120 ejecuciones. De ellas, 114 terminaron y seis fallaron. El ZIP contiene veinte archivos results.csv, uno por combinación de RFP y modelo, cada uno con seis resultados individuales.

3. Antes de hablar de ganadores, una advertencia de trazabilidad

Hay una incidencia en la instrumentación: los metadatos del paquete siguen identificando “GitHub Copilot CLI 1.0.98” también en la versión 02, y además indican que el modelo realmente ejecutado no está verificado de forma independiente. No he sobrescrito esos registros. La atribución de 01/02 a las diferentes CLI es la correspondencia declarada por el autor, no una confirmación criptográfica ni una prueba aportada por los logs.

Esto importa. Las cifras por versión se pueden calcular exactamente; lo que no se puede hacer es convertir una etiqueta reconstruida en evidencia independiente de qué ejecutable generó cada informe. Por esa razón hablaré de “resultado atribuido a la herramienta” y no de una superioridad certificada de Copilot, Codex o Claude Code.

4. Qué mide recall y qué ocurre cuando una ejecución falla

El recall (también llamado sensibilidad o exhaustividad de detección) responde a una pregunta sencilla: «De todos los defectos que sabemos que existen en un pliego, ¿cuántos ha encontrado el equipo de agentes?». No mide lo convincente que suena el informe ni cuántas páginas produce. Mide cobertura frente a una lista de defectos conocidos antes de ejecutar la auditoría.

RECALL = (defectos detectados / defectos conocidos) × 100

Un ejemplo sencillo. Imaginemos una RFP con 15 defectos sembrados deliberadamente, guardados en una clave de respuestas a la que los agentes no tienen acceso. Si el informe identifica correctamente 12, obtiene un recall del 80 %: encontró 12 y dejó escapar 3. Si solo encuentra 9, baja al 60 %: quedan 6 sin detectar. A igualdad de condiciones, el 80 % es mejor porque escapan menos riesgos conocidos.

¿Por qué es preferible un valor alto? Un defecto que se escapa puede convertirse más adelante en un incumplimiento, una incompatibilidad o un sobrecoste. Pasar del 60 % al 80 % significa detectar más problemas reales. Pero no significa que el informe sea perfecto: un sistema puede elevar su recall denunciando demasiadas cláusulas y generando falsas alarmas.

Para evaluar la calidad de la auditoría hay que separar cuatro preguntas. No son indicadores intercambiables:

¿Cómo interpretar un 76,7 % de recall medio? En las ejecuciones completadas, esa configuración identificó en promedio aproximadamente tres de cada cuatro defectos esperados, según el corrector automático. No significa que resolviera el 76,7 % de las licitaciones, ni que cada RFP obtuviera ese porcentaje exacto, ni que exista una probabilidad demostrada del 76,7 % para cualquier proyecto futuro.

El estudio distingue además dos formas de agregarlo. Recall condicional: media de detección solo entre ejecuciones que terminaron. Recall operacional: media que asigna valor cero a una ejecución que no entregó informe. Ejemplo: si nueve rondas terminan con un recall medio del 80 % y la décima falla, el recall condicional es del 80 %, pero el operacional es del 72 % (80 % × 9/10). El cero expresa ausencia de resultado entregado, no que se haya inspeccionado el pliego y encontrado cero defectos.

Por último, los defectos detectados se puntúan con un corrector heurístico. La revisión humana sigue pendiente: cifras altas de recall no sustituyen comprobar que el sistema de medida es fiable, que las citas son correctas y que los hallazgos resultan útiles para tomar decisiones. Esa es precisamente la diferencia entre pasar un gate de QA y demostrar calidad mediante QC.

5. Los resultados recalculados: doce configuraciones, no tres barras

Figura 1 · Recall operacional de las doce combinaciones (un fallo se computa como 0 para la métrica compuesta). Fuente: veinte results.csv incluidos en el ZIP aportado.

En Claude, fixed es prácticamente un empate entre Copilot CLI (76,7 %, 10/10) y Claude Code (76,0 %, 10/10). La política frozen logra el mayor recall condicional en Claude + Copilot (77,8 %), pero su ejecución fallida reduce la cobertura operacional al 70,0 %. Dynamic se queda en el 70,0 % con Copilot y en el 64,0 % con Claude Code.

En Astra cambia una parte del resultado: Copilot CLI con fixed consigue un 73,3 % entre nueve ejecuciones completadas, pero Codex CLI con fixed entrega un 72,7 % completando diez de diez. Si se valora el resultado útil esperado por RFP, gana Astra + Codex CLI + fixed (72,7 % frente a 66,0 %). Una comparación basada únicamente en recall de éxitos invertiría indebidamente la recomendación.

Figura 2 · Recall condicional frente a fiabilidad. Puntos con 100 % de completitud no son equivalentes a puntos con 80–90 % aunque tengan recall similar.

6. ¿Cuál es mejor, realmente? La estadística obliga a separar decisión y demostración

Mi recomendación para esta carga de trabajo es Claude Opus 5.5 + GitHub Copilot CLI + fixed. Combina el mejor recall operacional observado (76,7 %) y diez ejecuciones terminadas de diez. Pero debo añadir algo que no queda bien en una infografía triunfalista: Claude Code + fixed alcanzó el 76,0 % y terminó también todas las ejecuciones.

Comparé las dos versiones sobre las mismas diez RFP. La diferencia media de Claude + fixed es de 0,67 puntos porcentuales a favor de Copilot. Un bootstrap pareado con remuestreo por RFP —40.000 muestras, semilla fija— devuelve un intervalo percentil aproximado del 95 % desde −2,7 hasta +5,3 puntos. Cruza el cero holgadamente. Esa evidencia no justifica proclamar que una CLI sea superior a la otra.

Figura 3 · Diferencias de recall operacional entre versiones 01 y 02, con intervalos bootstrap exploratorios. Cero significa igualdad; todos los intervalos incluyen la ausencia de ventaja clara.

Tampoco confundiría los quince defectos de cada RFP con 150 observaciones independientes: varios defectos están correlacionados dentro del mismo pliego, y las comparaciones comparten los mismos casos. Para estimar incertidumbre de la decisión, la unidad de remuestreo razonable es la RFP, no cada defecto aislado. Con diez unidades, los intervalos necesariamente son anchos.

Qué sí sostienen estos datos: fixed proporciona aquí el mejor equilibrio entre cobertura y continuidad; en Claude las dos CLI están cerca; en Astra Codex + fixed es la opción operativa más estable. Qué no sostienen: la superioridad universal de una CLI, de un modelo o de una política sobre cualquier dominio y arquitectura.

7. Diez RFP en lugar de cien: decisión racional, no certeza estadística

El plan inicial contemplaba cien RFP por combinación. Detuve la ejecución en diez. No porque una prueba estadística hubiese certificado saturación, sino porque la pregunta de ingeniería que debía responder tenía ya una dirección operativa, mientras que el coste de continuar era considerable.

Hay una prueba concreta de sensibilidad que ayuda a explicar esa decisión. Recalculé la mejor combinación eliminando sucesivamente una de las diez RFP: en ocho de diez exclusiones seguía encabezando Claude + Copilot CLI + fixed. Las otras dos favorecían Claude + Claude Code + fixed o Claude + Copilot CLI + frozen. Esto aporta una evidencia útil de robustez del ranking, aunque no prueba que cien RFP arrojasen el mismo orden.

Figura 4 · Análisis leave-one-RFP-out: ganador al excluir cada caso. Evalúa sensibilidad a una muestra concreta, no la convergencia temporal de un experimento secuencial.

Es importante no inventar aquí una curva de convergencia temporal: los identificadores 01–10 de los pliegos no prueban el orden real de ejecución. La prueba leave-one-out es más honesta para lo que contienen los archivos. Además, las diferencias de menos de un punto entre las mejores herramientas podrían cambiar con un número mayor de pliegos.

Según el informe operativo original, el estudio acumuló 393 invocaciones y unas 40,05 horas-modelo medidas. Se consumieron créditos de IA; el autor estimó un gasto del orden de 200 USD, pero los registros publicados no permiten verificar una factura ni una tarifa de conversión desde las unidades internas. No presentaré 155,35 USD, una cifra estimada bajo supuestos, como coste auditado.

Más casos mejorarían las estimaciones de varianza entre RFP, estrecharían los intervalos y podrían cambiar el orden de configuraciones próximas. Por tanto, lo que se detuvo fue un experimento de decisión con coste marginal creciente; no se declaró resuelto un problema científico de generalización. La distinción es deliberada: utilidad operacional y significación estadística no son sinónimos.

8. QA no es QC: la lección que se mantiene de un experimento al siguiente

En el experimento previo comprobé que un gate de estructura podía penalizar una cita correcta a una sección sin identificador y que un corrector ingenuo podía ser engañado por un informe que citaba demasiado. Aquellos resultados no se recalcularon con este nuevo paquete: los menciono porque explican por qué en el benchmark actual separo los gates, los defectos detectados, las falsas alarmas, las ejecuciones fallidas y la revisión humana pendiente.

Diagrama 2 · QA controla el contrato y el proceso; QC contrasta el producto con defectos conocidos. La revisión humana valida el sistema de medida y las decisiones.

QA — aseguramiento de la calidad — establece criterios, trazabilidad, políticas y controles de proceso. QC — control de la calidad — inspecciona el resultado y comprueba qué riesgos realmente identificó. Un informe puede pasar QA y seguir omitiendo problemas de negocio críticos.

La tesis de fondo no es “prohibir agentes dinámicos”. Un harness nativo gobierna cómo la CLI realiza llamadas, delega trabajo y maneja su ejecución; eso no sustituye por sí solo un contrato persistente de requisitos, evaluación, equivalencia, aprobación y transferencia del conocimiento a lo largo del ciclo de vida. Tampoco mi harness propio queda exento: debe pasar sus propias pruebas de control y trazabilidad.

La frontera de confianza no debería descansar en que el modelo «recuerde» qué agentes creó o cómo distribuyó el trabajo en una ejecución. Debe apoyarse en especificaciones verificables, decisiones registradas, evidencias de pruebas y criterios de aceptación que un equipo diferente pueda reproducir. Eso requiere una metodología explícita, no únicamente un conjunto de prompts o agentes temporales.

9. Conclusión: fixed gana; la metodología no viene incluida en el modelo

Hay una conclusión que sí puedo sostener con claridad después de estas diez RFP: la política fixed es la que mejor equilibrio ofrece entre detección de defectos y continuidad de ejecución en este experimento. No significa que los agentes dinámicos sean inútiles, ni que un equipo fijo vaya a ganar siempre. Significa algo mucho más útil: aquí un equipo predefinido, revisado y reutilizable ha dado mejores resultados operativos que improvisar su composición para cada pliego. Fijo no significa anticuado; significa que sé quién hace qué, bajo qué criterios y cómo evaluar su trabajo.

Si debo elegir una configuración concreta, me quedo con Claude Opus 5.5 + GitHub Copilot CLI + fixed: un 76,7 % de recall operacional y 10 de 10 ejecuciones completadas. Claude Code con el mismo modelo y política obtiene un 76,0 % y también 10 de 10. Es prácticamente un empate; no tengo evidencia estadística para proclamar superior a una CLI. El 77,8 % de recall condicional que alcanzó frozen en Claude + Copilot es interesante, pero llega con una ejecución fallida. Prefiero la regularidad a ganar una décima en la foto.

Con GPT-6 Astra, OpenAI Codex CLI + fixed entrega un mejor resultado operacional en este conjunto: 72,7 % con 10/10 completadas, frente al 66,0 % operacional de Copilot CLI + fixed, que completó nueve. Es una ventaja concreta de la herramienta del fabricante, no una ley general. En Claude ocurre lo contrario por un margen muy pequeño. Por eso la lectura interesante no es «qué fabricante tiene la mejor CLI», sino qué aporta de verdad la CLI frente al modelo, el equipo de agentes y el método que lo gobierna.

Los modelos frontera dejan de ser una ventaja exclusiva en cuanto pueden utilizarse desde distintas herramientas. Es razonable que quien desarrolla un modelo disponga, en determinados momentos, de ventajas de integración, conocimiento de sus capacidades y ajustes de producto. Pero eso es una ventaja táctica, no necesariamente una ventaja sostenible. Lo he comentado en muchas reuniones: la distancia se acorta rápidamente. Y lo observado aquí —especialmente GitHub Copilot CLI trabajando con Claude— ilustra que una herramienta que no pertenece al fabricante del LLM puede estar perfectamente a su altura.

La cuestión que me preocupa es otra. A fecha de 18 de octubre de 2026, el harness que incorpora una herramienta puede resolver muy bien cómo invocar el modelo, usar herramientas, delegar tareas y gestionar el contexto de esa ejecución. Eso no sustituye mi experiencia, ni el diseño consciente de un harness propio que gobierne una metodología de ingeniería: requisitos y decisiones trazables, criterios de aceptación, pruebas, equivalencia funcional, revisión, seguridad, despliegue y transferencia de conocimiento. Que la CLI sepa orquestar acciones no demuestra por sí mismo que sepa gobernar todo ese proceso.

Veo continuamente demostraciones espectaculares de agentes creados al vuelo. Lo que todavía no he visto demostrado de forma verificable y reproducible es que esas herramientas, por sí solas, sean capaces de diseñar y sostener una metodología completa para un SDLC de extremo a extremo: desde descubrir y formalizar reglas de negocio hasta construir, validar, evolucionar y operar el producto con la misma disciplina a lo largo del tiempo. Este benchmark examina auditorías de RFP, no demuestra una imposibilidad universal del SDLC; es mi juicio profesional sobre las evidencias y soluciones disponibles hoy.

Para acercarse a ese objetivo no basta con generar más agentes. Hacen falta métodos explícitos, conocimiento de ingeniería, patrones, reglas de decisión y criterios de verificación que el sistema pueda consultar, aplicar y auditar: el equivalente práctico a disponer de buenos libros, procedimientos y experiencia organizada, pero convertidos en contratos ejecutables y evaluables. Un modelo no puede inferir de forma fiable una metodología privada que no se le ha proporcionado. Tampoco podemos saber con precisión qué material ha visto durante su entrenamiento. Por eso no esperaría que genere espontáneamente todo ese conocimiento específico.

En mi caso, esa metodología no es una promesa ni una diapositiva: la he desarrollado y la estoy utilizando. Parte de ese conocimiento no está publicado abiertamente como un procedimiento que cualquiera pueda importar en su CLI. No sostengo que sea la única metodología posible ni que ninguna otra organización haya resuelto partes del problema. Sí sostengo que tener un modelo potente no equivale a tener incorporada la experiencia y las reglas con las que yo dirijo ese trabajo.

¿Por qué paré en diez y no llegué a cien? Porque, para tomar esta decisión de ingeniería, la señal era suficientemente útil frente al coste de seguir ejecutando. Más casos habrían estrechado los intervalos y quizá cambiado el orden de herramientas muy próximas; no voy a disfrazar la decisión de ahorrar tiempo y créditos de certeza matemática. Pero tampoco necesito gastar el presupuesto de cien casos para ignorar lo que diez ya me estaban enseñando sobre el valor de un equipo fixed bien gobernado.

Mi conclusión es sencilla: el acceso al modelo se democratiza; la disciplina de ingeniería, no. El harness nativo de la herramienta puede acelerar la ejecución. El harness metodológico propio define qué significa ejecutar bien, cómo se comprueba y cómo se mantiene ese estándar durante todo el ciclo de vida. Esa es, hoy, la diferencia que no compro pulsando un botón.