La demo tiene una distribución estadística de un solo aplauso
Un agente terminó una tarea compleja. Excelente. Ahora repetila con el mismo estado inicial, cambiá un detalle razonable, cortá una herramienta y medí cuánto cuesta recuperarse.
Ahí empieza la información útil para decidir si lo ponés a trabajar. El video ya cumplió su función comercial.
Evaluar un agente significa medir un sistema que actúa sobre un entorno, bajo un contrato de éxito y un presupuesto definidos. El modelo es una de sus variables. También lo son las herramientas, la memoria, los permisos, la infraestructura y la lógica que decide cuándo terminó.
Propongo un protocolo para un agente que prepara cambios en un repositorio. Los números didácticos y los formatos de este artículo son ilustrativos; no describen mediciones propias.
Definir éxito antes de leer la respuesta
Para una tarea como “corregir una falla y preparar un cambio revisable”, aceptaría una ejecución solamente si cumple condiciones observables:
- El comportamiento solicitado queda implementado según un evaluador independiente.
- Las regresiones seleccionadas siguen pasando.
- Los cambios permanecen dentro del alcance autorizado.
- No aparecen efectos externos prohibidos ni exposición de secretos.
- La ejecución respeta el presupuesto y el plazo definidos.
El evaluador inspecciona el estado final y los eventos de herramientas. La declaración “todo funciona” entra como una afirmación a contrastar. Si usamos la misma declaración para aprobar la ejecución, acabamos de contratar al candidato para corregir su propio examen.
El preprint Beyond Task Completion, de marzo de 2026, estudia resultados aparentemente exitosos que violan requisitos de procedimiento. Es una razón concreta para registrar cómo se obtuvo el resultado, además del estado final.
En una rúbrica propia, un criterio crítico funciona como condición de aceptación. Una filtración no se compensa con buena documentación. Los puntajes parciales siguen siendo útiles para diagnosticar, aunque la ejecución quede rechazada.
Versionar el experimento completo
Este manifiesto conceptual muestra información que exigiría para reproducir una comparación. Los valores REQUIRED deben sustituirse por identificadores reales:
experiment:
dataset_revision: REQUIRED
task_split: held_out
model_snapshot: REQUIRED
harness_commit: REQUIRED
system_prompt_sha256: REQUIRED
tool_contract_revision: REQUIRED
grader_commit: REQUIRED
environment:
image_digest: REQUIRED
initial_repository_commit: REQUIRED
cpu_limit: REQUIRED
memory_limit_mb: REQUIRED
network_policy: REQUIRED
dependency_cache_policy: REQUIRED
execution:
trials_per_task: REQUIRED
deadline_seconds: REQUIRED
max_total_tokens: REQUIRED
max_tool_calls: REQUIRED
max_cost_usd: REQUIRED
Cada intento empieza con un estado limpio. Una solución que quedó en el filesystem, una memoria escrita por el intento anterior o una caché con respuestas pueden cambiar la tarea. Los efectos externos se aíslan por ejecución o se reemplazan por fixtures cuyo comportamiento esté especificado.
Cuando el proveedor no permite fijar exactamente una versión del modelo, documento el identificador disponible y la ventana temporal. Reproducir el entorno reduce ambigüedad; no vuelve determinista a un servicio remoto.
El harness también rinde examen
En febrero de 2026, Anthropic reportó diferencias de seis puntos porcentuales en Terminal-Bench 2.0 entre configuraciones de infraestructura de su experimento. El resultado pertenece a ese estudio, no a cualquier agente. Fuente primaria.
Para comparar dos diseños, mantendría constantes los recursos y bloquearía las ejecuciones por tarea y período. Alternaría el orden de los candidatos para reducir el efecto de ejecutar siempre uno durante una ventana más favorable. Registraría saturación, latencia del proveedor y errores del entorno.
Hay dos preguntas válidas: qué tan bien resuelve el sistema completo en condiciones operativas, y qué aporta un componente bajo condiciones controladas. Conviene publicar ambos resultados con sus denominadores. El usuario también sufre un fallo de infraestructura, aunque al equipo del modelo le resulte incómodo contarlo.
Las exclusiones se definen antes del experimento y se reportan. Eliminar después los timeouts del candidato favorito produce una métrica excelente para una realidad bastante selectiva.
Capacidad y consistencia necesitan números distintos
Tau-bench introdujo pass^k para estudiar consistencia entre intentos. En la práctica conviene distinguirlo de pass@k, que mide la posibilidad de obtener al menos un éxito.
Con n intentos intercambiables de una tarea, c éxitos y k <= n, los estimadores combinatorios son:
pass@k = 1 - C(n - c, k) / C(n, k)
pass^k = C(c, k) / C(n, k)
C(a, k) = 0 cuando a < k
La estimación se calcula por tarea y después se agrega. No juntes todos los aciertos de tareas fáciles y difíciles antes de aplicar la fórmula.
Como ejemplo puramente matemático, si cada intento independiente tuviera probabilidad de éxito p = 0.8, cuatro intentos darían pass@4 = 0.9984, mientras que pass^4 = 0.4096. El mismo comportamiento admite un slide triunfal y una operación bastante nerviosa.
Esas fórmulas poblacionales suponen intentos independientes con probabilidad constante. En un sistema real, las ejecuciones pueden compartir una falla de herramientas o una limitación del modelo. Reportaría tasas por tarea e intervalos obtenidos remuestreando tareas; si hay dependencias por repositorio o incidente, respetaría esos grupos en el muestreo.
Pass@k también presupone que podés reconocer la solución correcta entre los intentos. En producción, ese selector tiene costo y errores propios. El oráculo del benchmark no viene incluido en la API.
La contaminación ahora puede ocurrir durante la ejecución
En marzo de 2026, Anthropic documentó casos en BrowseComp donde un agente identificó el benchmark y localizó sus respuestas. El problema excede lo que pudo estar en el entrenamiento. Las herramientas también pueden traer el examen resuelto. Análisis original.
Para evaluar investigación con navegación, separaría tareas públicas de casos reservados y registraría qué fuentes sustentan cada respuesta. Una respuesta correcta obtenida desde una solución publicada debe marcarse como contaminada para la capacidad que se quería medir. Si la tarea evaluaba encontrar respuestas existentes, el contrato sería otro.
Para código, mantendría las pruebas reservadas fuera del entorno del agente y registraría las modificaciones que intenta hacer sobre el evaluador. Una tarea que depende de documentación pública necesita acceso a esa documentación; bloquear toda la red puede evitar una fuga y cambiar a la vez el problema evaluado.
El informe debe explicar ese compromiso. Ninguna etiqueta de dataset privado sustituye el análisis de qué podía ver realmente el sistema.
Jueces con responsabilidades acotadas
Usaría código para invariantes y resultados verificables, una rúbrica semántica para cuestiones abiertas y revisión humana para calibrar desacuerdos. La guía de evaluación de agentes de Anthropic también distingue evaluadores basados en código, modelos y personas.
Al juez semántico le daría evidencia y criterios explícitos, con la posibilidad de responder “no determinable”. Mediría falsos positivos y falsos negativos sobre casos revisados, incluyendo respuestas largas y convincentes pero incorrectas.
La evidencia del agente es entrada no confiable para el juez. Una instrucción dentro de un archivo o una respuesta no debe cambiar la rúbrica. Registrar versiones del prompt y del modelo evaluador permite saber cuándo cambió la medición, incluso si el agente quedó igual.
El costo por éxito incluye las derrotas
Defino una ejecución aceptada como una que satisface el contrato completo. Para una carga fija:
costo_por_ejecucion_aceptada =
costo_total_de_todas_las_ejecuciones / ejecuciones_aceptadas
El numerador incluye modelos, herramientas, infraestructura y reintentos. El trabajo humano se reporta en minutos y, si se monetiza, con una tarifa declarada. Con cero éxitos, el cociente no ofrece un costo finito útil.
Publicaría esta métrica junto con tasa de aceptación, latencia p50/p95, tiempo hasta abandono e intervenciones. También mostraría resultados por dificultad: aceptar solamente lo fácil puede mejorar el costo agregado y reducir la utilidad del producto.
Una abstención es correcta cuando el contrato exige abstenerse ante evidencia insuficiente o una acción prohibida. Cuando la tarea sí debía resolverse, es una tarea no resuelta. Hace falta reportar cobertura para que esa distinción no se convierta en una salida contable.
Un criterio de adopción que pueda fallar
Antes de ejecutar, fijaría el máximo costo aceptable, el mínimo nivel de éxito y las condiciones críticas que bloquean el lanzamiento. Compararía contra el sistema actual, conservaría resultados crudos y explicaría qué parte de la mejora persiste al quitar memoria, delegación o recuperación adicional.
El resultado puede ser que el diseño nuevo no justifique su complejidad. Para eso existe el experimento. Si todas las pruebas terminan validando la arquitectura elegida de antemano, probablemente estés midiendo la capacidad narrativa del equipo.
Un agente está listo para ampliar autonomía cuando su desempeño, sus límites y sus costos resisten una evaluación repetible sobre tareas relevantes. La demo sirve para mostrar una posibilidad. La decisión operativa necesita una distribución.
Esta evaluación se puede aplicar al diseño de agentes recursivos y al protocolo de ejecución de herramientas.