Cómo saber si tu agente es fiable: monta tu primera evaluación en una tarde
«Funciona bien» no es una medida: sin repeticiones, sin criterio de éxito y sin leer las trazas, lo que tienes es una impresión formada por las veces que miraste. Esta guía monta en una tarde la evaluación mínima que sí permite decidir, y explica qué números mirar y cuáles ignorar.
11 min de lecturalaboratorio: calculadorapublicado el 21 sept 2026
1El problema
Un agente que «funciona bien» no está medido: está recordado. Y lo que se recuerda son las veces que uno miró, que suelen ser las veces que acababa de salir bien. Un agente no repite: la misma tarea, encargada dos veces, da resultados distintos, y los errores de cada paso se van acumulando hasta el final.V
Debajo de esa impresión hay una distinción que casi nadie mide: precisión (acertar alguna vez) no es fiabilidad (acertar todas). El estudio de Princeton «Towards a Science of AI Agent Reliability» (Rabanser et al., feb-2026) evaluó 15 agentes sobre GAIA y τ-bench y concluye que, tras veinticuatro meses de modelos nuevos, la fiabilidad global apenas mejora mientras la precisión sube sin parar.V Dicho en corto: los modelos aciertan cada vez más y siguen siendo igual de inconstantes.
La consecuencia es aritmética. τ-bench midió ya en 2024 que gpt-4o resolvía menos del 50 % de las tareas de retail y que su pass^8 —acertar las ocho veces seguidas— caía por debajo del 25 %.V Y METR, un laboratorio independiente que mide hasta dónde llegan los agentes, advierte de que un horizonte del 50 % en tareas de X horas no significa que las tareas más cortas se puedan delegar con seguridad cuando el proceso necesita un 98 % de acierto o más.V
Por eso la pregunta útil no es «¿funciona?» sino «¿cuántas veces seguidas acierta, con cuánta variación y a qué coste?». Eso solo lo responde una evaluación, y la primera cabe en una tarde.
2Qué es una eval de agente
Anthropic fija el vocabulario mínimo en «Demystifying evals for AI agents» (9-ene-2026):V
Tarea: un caso de prueba con entradas y criterios de éxito definidos.
Intento (trial): cada ejecución sobre una tarea; se repiten porque la salida varía.
Calificador (grader): la lógica que puntúa algún aspecto del desempeño; una tarea puede tener varios.
Traza (transcript): el registro completo de un intento, con salidas, llamadas a herramientas, razonamiento y resultados intermedios.
Resultado (outcome): el estado final del entorno, que es distinto de lo que el agente dice haber hecho.
Ahí está la diferencia con evaluar un modelo. Un modelo produce texto y se califica ese texto. Un agente «opera en muchos turnos: llama a herramientas, modifica el estado y se adapta según los resultados intermedios», así que los errores se propagan y se componen.V Lo que hay que calificar no es lo que escribe, sino lo que quedó en el mundo: el agente puede decir «reserva hecha» sin que la reserva exista en la base de datos.V
Tres reglas de diseño que ahorran la mitad del trabajo:
Califica el resultado, no el camino. conviene puntuar lo que el agente dejó hecho y no cómo llegó hasta ahí, porque exigir un camino concreto descarta soluciones válidas que no se te habían ocurrido. En τ²-bench, Claude Opus 4.5 encontró un resquicio legítimo en la política de una aerolínea —mejorar la cabina y después modificar el vuelo— y la eval lo marcó como fallo aunque el resultado era mejor para el usuario.V
Aísla cada intento. Cada repetición debe partir de un entorno limpio; ficheros, cachés o recursos compartidos entre intentos producen fallos correlacionados que te harán creer que el agente es peor (o mejor) de lo que es.V
Usa el calificador más barato que sirva. Código (asserts, tests, comprobación del estado final) cuando el éxito es comprobable: rápido, objetivo y reproducible, aunque frágil ante variaciones válidas. Otro modelo haciendo de juez cuando la respuesta es abierta: es flexible, pero no da siempre la misma nota al mismo trabajo, sale más caro y hay que contrastarlo con personas antes de fiarse. Humano para muestras periódicas y casos ambiguos.V
Un apunte que evita confusiones: no es lo mismo el harness del agente —lo que convierte al modelo en agente— que el harness de evaluación, la infraestructura que ejecuta las evals de extremo a extremo.V
3Cómo se hace en una tarde
Lo caro de una eval es querer empezar con cientos de casos. Anthropic recomienda lo contrario: 20-50 tareas simples extraídas de fallos reales, en lugar de esperar a tener un corpus grande.V En su sistema multiagente de investigación arrancaron con unas veinte consultas representativas, porque con unos pocos casos ya se nota si un cambio ha mejorado o empeorado las cosas.V
Saca los casos de fallos reales (60-90 min). Incidencias de usuarios, correcciones manuales, comprobaciones que alguien hace a mano cada mañana. Prioriza por impacto. Para cada caso, exige una solución de referencia que demuestre que la tarea es resoluble: si nadie sabe resolverla, no es un caso de prueba, es un problema abierto.V
Define el criterio de éxito sobre el estado final (30 min). Binario: pasa o falla. Husain y Shankar recomiendan juicios binarios en lugar de escalas tipo Likert, comprobaciones por código antes que modelo-juez, y rechazan las métricas genéricas de texto (ROUGE, BERTScore).V Escríbelo como una frase comprobable —«existe una fila en pedidos con ese id y estado enviado»— y no como «la respuesta es buena».
Repite cada caso k veces (tiempo de máquina). Con 30 casos y k=5 son 150 ejecuciones; el laboratorio de abajo te dice cuántas te va a costar la tuya. Cada repetición, desde un entorno limpio.V
Califica (30 min). Primero por código. Solo donde el código no llegue, un único modelo-juez con rúbrica explícita: en el sistema multiagente de Anthropic la rúbrica cubría exactitud factual, citas, completitud, calidad de las fuentes y eficiencia en el uso de herramientas.V
Lee las trazas (45 min). No es opcional. OpenAI propone empezar justo por ahí: coger sesiones sueltas y puntuarlas una a una —si eligió bien la herramienta, si pasó bien el trabajo de un ayudante al siguiente, si respetó las instrucciones, si hizo algo inseguro—. Es la vía más rápida para encontrar dónde se rompe el proceso, porque los fallos que importan casi nunca están en una respuesta concreta, sino en el encadenado de pasos, y montar los datasets repetibles después.V Hamel Husain y Shreya Shankar, que se dedican a medir estos sistemas, van más lejos: leer los fallos uno a uno es la parte más importante del trabajo; y en agentes hay que localizar el primer fallo aguas arriba, porque todo lo posterior son consecuencias.V
Duda de tu propio calificador. Con Claude Opus 4.5, CORE-Bench pasó del 42 % al 95 % al corregir la calificación: comparaciones rígidas («96.12» frente a «96.124991…»), especificaciones ambiguas y tareas estocásticas irreproducibles.V Si un caso falla siempre y nadie entiende por qué, sospecha del calificador antes que del agente.
Qué anotar por cada caso: pass@k y pass^k, la variación entre repeticiones, el coste y los tokens por tarea, el paso exacto donde falló por primera vez, y la versión de modelo, prompt, herramientas y harness con la que se ejecutó. Sin esa última línea, los números de la semana que viene no serán comparables con los de hoy.
Anthropic cita como herramientas Harbor, Braintrust, LangSmith, Langfuse y Arize (Phoenix, AX).V Para la primera tarde, un script y una hoja de cálculo bastan; la plataforma es la segunda decisión, no la primera.
4Qué mirar en los números
Dos métricas con el mismo aire y significados opuestos. pass@k es la probabilidad de acertar al menos una vez en k intentos: sube con k. pass^k es la probabilidad de acertar las k veces: baja con k. Anthropic lo resume con un ejemplo: al llegar a diez intentos, las dos cifras cuentan historias opuestas —una se acerca al 100 % y la otra se desploma hacia el 0 %—, y la que describe tu proceso en producción es la segunda.V La métrica pass^k la introdujo τ-bench en junio de 2024.V
Cuál mirar depende de quién recoge los platos rotos. Si hay una persona que revisa y reintenta, pass@k describe tu situación. Si el agente ejecuta solo y nadie mira cada resultado, la cifra que manda es pass^k, con k igual al número de veces que se ejecuta sin supervisión.
Junto a ellas, dos números más:
Variación entre repeticiones. Un 70 % de media puede ser «casi siempre bien, algún fallo suelto» o «va a rachas», y no se gestionan igual. El trabajo de Princeton descompone la fiabilidad en cuatro dimensiones —consistencia, robustez, predictibilidad (calibración) y seguridad— con doce métricas, y observa que los modelos más grandes a veces son menos consistentes y que la sensibilidad a cambios superficiales del prompt persiste.V
Coste por tarea. Un agente que acierta algo más gastando el triple puede ser la peor opción disponible; el porcentaje medio lo esconde y el coste por tarea resuelta no. Anótalo desde la primera pasada, que es cuando es gratis anotarlo.
Y un recordatorio sobre el crédito parcial: en OSWorld 2.0, Claude Fable 5.1 obtiene un 77,9 % con puntuación parcial y un 41,7 % exigiendo la tarea entera bien hecha.V Cuando lo que queda es un estado en un sistema real, «casi bien» no es «hecho».
El laboratorio de abajo hace esta aritmética con tus números. Son cuentas, no mediciones: multiplicar probabilidades supone que los intentos son independientes y que todos los pasos aciertan igual, cosa que en un agente real no ocurre. Sirven para ver el orden de magnitud y decidir cuántas repeticiones necesitas; el porcentaje real solo sale de ejecutar la eval.
5Qué no medir
La tentación es ahorrarse la tarde y mirar un ranking público. Tres razones para no hacerlo.
Contaminación. OpenAI dejó de reportar SWE-bench Verified el 23-feb-2026: auditó el 27,6 % de las tareas y halló que el 59,4 % de las auditadas tenía tests defectuosos que rechazaban soluciones correctas —un suelo del 16,4 % de tareas rotas en todo el benchmark— y que todos los modelos punteros probados habían visto, mientras aprendían, al menos parte de los problemas y de sus soluciones.V Epoch AI lo califica de «Flawed» (3-sep-2026): riesgo alto de contaminación, resultados que cambian según el programa que rodea al modelo, y un atajo que permite sacar la máxima puntuación sin resolver de verdad la tarea.V
Saturación. Cuando el agente resuelve todas las tareas resolubles, el benchmark deja de discriminar.V Terminal-Bench 4.0 eliminó ocho tareas —dos saturadas, dos por problemas de calidad, dos por rechazos y dos con soluciones públicas— y se quedó en 66; su mantenedor lo explica sin adornos: estos benchmarks son simulaciones complicadas, tienen errores como cualquier programa y hay que mantenerlos.V El conjunto de telecom de τ²-bench aparece ya por encima del 99 % en los agregadores.S
Dependencia del harness. En SWE-bench Pro, el leaderboard estandarizado de Scale sitúa al líder en el 61,5 %, mientras Anthropic reporta un 81,2 % para Claude Fable 5.1 en su propia configuración (media de cinco intentos, esfuerzo máximo).V No son cifras comparables: describen sistemas distintos, no modelos distintos.
A eso se suman los calificadores mal hechos —el Agentic Benchmark Checklist (NeurIPS 2025) documentó que τ-bench contaba respuestas vacías como éxito y que más de la mitad de los benchmarks analizados tenía fallos de implementaciónS— y la grader awareness: Anthropic cuenta que, al principio del entrenamiento de Mythos 5.1, en la mayoría de las sesiones largas de programación el modelo se daba cuenta de que lo estaban evaluando.V Si el modelo razona sobre quién le pone la nota, parte de lo que mides es comportamiento de examen.
La regla que Anthropic se aplica a sí misma vale igual para ti: una nota no se da por buena hasta que alguien entra en el detalle de la prueba y se lee unas cuantas sesiones enteras.V Los benchmarks públicos sirven para decidir por dónde empezar a probar. No sirven para decidir si tu agente puede tocar tu producción.
6Cuándo parar
Una eval está terminada cuando sirve para decidir, no cuando está completa. Tres señales de que ya sirve:
Discrimina. Cambias el prompt, el modelo o una herramienta y el número se mueve de forma consistente entre repeticiones. Si no se mueve nunca, tienes pocos casos o son demasiado fáciles; si se mueve en todas direcciones, te faltan repeticiones y lo que ves es ruido.
Explica. Ante un fallo puedes señalar en la traza el primer paso que se torció, en vez de encogerte de hombros.
Tiene precio conocido. Sabes lo que cuesta una pasada completa, así que puedes ejecutarla en cada cambio sin abrir una negociación.
A partir de ahí la eval cambia de papel. Anthropic distingue las evals de capacidad —empiezan con tasas bajas y señalan hacia dónde mejorar— de las de regresión, que deben mantenerse cerca del 100 % para detectar retrocesos; una eval de capacidad saturada «se gradúa» a regresión.V Tus 30 casos de la primera tarde acabarán siendo tu red de regresión, y ese es su destino natural.
Lo que no conviene es pararse creyendo que la eval es toda la evidencia. Anthropic propone un «modelo de queso suizo» en el que las evals automáticas conviven con monitorización en producción, A/B tests, feedback de usuarios, revisión manual de trazas y estudios con humanos: ninguna capa atrapa todo.V Y conviene calibrar expectativas de esfuerzo: en los proyectos de Husain y Shankar, entre el 60 % y el 80 % del tiempo de desarrollo se va en análisis de errores y evaluación.V
Si al final de la tarde tienes un número que se mueve cuando tocas algo, un fallo concreto identificado en una traza y una idea de lo que cuesta repetir la medida, la tarde ha valido. Todo lo demás es ampliación.
7Pruébalo
8Llévatelo a tu caso
Para qué sirve esto en un equipo
SoporteCoge las 30 últimas incidencias que el agente resolvió mal, conviértelas en casos y califica el estado del ticket, no el texto de la respuesta.
OperacionesAntes de dejar que un agente escriba en producción, calcula pass^k con k igual a las ejecuciones diarias sin supervisión: es la cifra que decide si hace falta revisión humana.
ComprasPide al proveedor pass^k y coste por tarea sobre tus casos reales, no su posición en un benchmark público que mide otro harness.
Hasta dónde llega: una eval de una tarde detecta regresiones y fallos gruesos en los casos que tú has puesto. No cubre lo que no se te ocurrió, no mide robustez frente a un atacante ni seguridad, y sus números solo valen para la combinación exacta de modelo, prompt, herramientas y harness con la que los mediste.
¿Te compensa?
Marca las que se cumplan en tu caso.
Si quieres seguir
Pruébalo tú
Usa el laboratorio de arriba con tu propio caso.
Entiéndelo mejor
Las piezas que lo completan.
¿Dudas o correcciones?
Si algo no encaja con tu caso, o si encuentras un error, escríbeme: se corrige y se anota.