El equipo de investigación de Google presentó un artículo en arXiv el 1 de octubre, dando a conocer un framework de verificación de agentes llamado VeriHarness, cuyo código también se publicó en GitHub bajo licencia Apache 2.0. El problema que busca resolver es muy concreto: cuando un agente de IA ejecuta una tarea de decenas de pasos y entrega una tabla, un informe o un archivo editado, quién decide si ese resultado es correcto.
El enfoque de VeriHarness consiste en que el propio modelo que generó la respuesta actúe como revisor. La misma pregunta se ejecuta varias veces de forma independiente con el modelo, obteniendo varios resultados que luego se comparan entre sí, tratándolos por separado según sean "discrepancia" o "consenso".
Dos vías de revisión
La primera vía trata la discrepancia. Cuando varios resultados difieren en alguna conclusión, el revisor vuelve al entorno de la tarea para buscar evidencia —por ejemplo, reabriendo el archivo original o revisando una celda concreta de una tabla— y usa lo que encuentra en el entorno para descartar la afirmación errónea.
La segunda vía trata el consenso. Cuando varios resultados coinciden, el framework tampoco los da por buenos de inmediato: busca activamente fallos, evidencia que pueda refutar esa conclusión, y a la vez comprueba si todos los resultados pasaron por alto algún requisito de la tarea. El punto de partida del artículo es que varias ejecuciones lleguen a la misma respuesta no garantiza que sea correcta; el modelo bien puede cometer el mismo error cada vez.
Tras completar ambas vías, comienza la fase de veredicto: se elige como base el resultado con mejores fundamentos, se proponen correcciones según la evidencia encontrada, se rehace todo por completo si es necesario, y los puntos que siguen sin aclararse se anotan por separado. El framework dota al revisor de un espacio de trabajo, herramientas de recopilación de evidencia y un conjunto de "habilidades de verificación" reutilizables; según el artículo, estas habilidades también pueden mejorar por sí mismas a partir de la retroalimentación de los fallos.
Qué se probó y cuánto mejoró
La evaluación abarca cinco benchmarks de espacios de trabajo de largo horizonte: APEX-Agents, Workspace-Bench Lite, WorkBuddy Bench, SpreadsheetBench 2 y JobBench, en su mayoría tareas que exigen entregar archivos, como documentos de oficina, hojas de cálculo y materiales de solicitud de empleo. La generación y la revisión usan el mismo modelo, y se probaron dos: Gemini 3.5 Flash y Claude Opus 4.8, ambos a través de Vertex AI.
Según el artículo y el README, VeriHarness quedó primero en "puntuación de selección" en los cinco benchmarks, frente a grupos de control que incluyen la ejecución única y métodos anteriores de LLM-as-a-Verifier. Sumando la corrección guiada por evidencia, frente a la generación única, Gemini 3.5 Flash sube en promedio 6,2 puntos, y Claude Opus 4.8, 6,4 puntos.
El equipo también publicó en Hugging Face unas 26.000 trayectorias de ejecución, con los dos modelos ejecutando cada pregunta 10 veces en los cinco benchmarks, junto con el proceso de ejecución renderizado, los archivos entregados y las puntuaciones. No se publicaron las entradas ni las soluciones de referencia de los benchmarks. El artículo menciona que producir este conjunto de datos costó más de 100.000 dólares.
En qué se diferencia de "ejecutar varias veces y votar por mayoría"
Hacer que el modelo se ejecute varias veces y luego votar es un método habitual en la industria para subir la puntuación, de bajo costo y fácil de implementar, con un efecto claro en preguntas cortas. Pero en tareas largas aparecen dos problemas: la entrega es un archivo, lo que impide votar de forma sencilla; y cuando los resultados coinciden, la votación conserva el error compartido tal cual. Las dos vías de VeriHarness apuntan justo a estos dos problemas.
Otro enfoque habitual es usar un modelo como juez que lee varios resultados y puntúa directamente. Este enfoque depende del juicio de lectura del juez y no regresa al entorno para verificar. VeriHarness pone en el centro si se puede encontrar evidencia en el entorno, al precio de que la propia revisión se convierta en una tarea de agente que debe llamar herramientas y gastar tokens. El artículo no ofrece la proporción de coste adicional de la revisión frente a la generación; las empresas que quieran calcular ese coste, por ahora, solo pueden probarlo por su cuenta.
Este sitio ya había informado sobre el benchmark ThinkingBox de Microsoft, que exige repetir la evaluación de la misma tarea 20 veces para ver si los resultados del agente son estables. Puestos ambos trabajos uno junto al otro, la dirección es la misma: en tareas largas, la puntuación de una sola ejecución tiene un valor de referencia limitado, y la diferencia entre varias ejecuciones es en sí misma una señal: una se usa para medir estabilidad, la otra para corregir errores.
¿Se puede usar ya directamente?
El README especifica que el entorno de ejecución es Linux, y requiere Python 3.10 o superior, Node.js 22.19 o superior, Docker y espacios de nombres de usuario sin privilegios; por debajo, se ejecuta sobre el runtime de código abierto pi, de modo que se puede conectar con cualquier proveedor de modelos compatible con pi. La página del proyecto también incluye una frase:
"This is not an officially supported Google product." (Este no es un producto respaldado oficialmente por Google.)
Es decir, por ahora se trata solo de código de investigación, y Google no se compromete a mantenerlo. Los dos modelos probados en el artículo no son la última generación de cada proveedor; cuánta mejora quedaría al cambiar a Gemini 4 u Opus 5.5 es algo que los autores no probaron, y eso solo podrá responderse con reproducciones de terceros.
Fuentes: artículo de arXiv "VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks", página del proyecto de Google Research en GitHub, CocoLoop, página del conjunto de datos en Hugging Face; el artículo y el README verifican los nombres de los cinco benchmarks, las mejoras promedio de puntuación de los dos modelos, las aproximadamente 26.000 trayectorias y los requisitos de entorno.