Evaluar agentes más allá del éxito de la tarea

Un agente puede completar correctamente una tarea y, aun así, ser una mala solución para producción.

Puede haber utilizado cinco llamadas cuando una era suficiente, consultar herramientas sin necesidad, ignorar una respuesta inválida, consumir un presupuesto excesivo o afirmar que todo salió bien después de que una operación fallara. También puede haber alcanzado el resultado correcto por casualidad: una estrategia frágil que solo funciona mientras las condiciones sean favorables.

Por eso, el éxito de la tarea es una métrica necesaria, pero insuficiente. Evaluar un agente únicamente con una variable binaria —completó o no completó— confunde el resultado con la calidad del proceso.

Una evaluación operativa debe responder preguntas más exigentes: ¿tomó buenas decisiones?, ¿usó las herramientas adecuadas?, ¿validó sus resultados?, ¿reconoció la incertidumbre?, ¿se recuperó ante un fallo?, ¿respetó los permisos?, ¿cuánto costó?, ¿qué riesgos introdujo y qué tan reproducible fue su comportamiento?

Resultado y proceso son dimensiones distintas

La primera separación necesaria es entre las métricas de resultado y las métricas de proceso.

Las métricas de resultado determinan si se alcanzó el objetivo observable. Por ejemplo:

• si una reserva fue creada correctamente;
• si un cambio de código pasó las pruebas relevantes;
• si un reporte contiene los datos solicitados;
• si una incidencia fue clasificada y escalada correctamente;
• si el estado final del sistema coincide con el criterio esperado.

Estas métricas deben ser verificables. La opinión textual del propio agente no es suficiente para declarar éxito. Cuando sea posible, el estado final debe validarse contra una fuente externa, una prueba automatizada, una transacción confirmada o una condición explícita del dominio.

Las métricas de proceso describen cómo llegó el agente a ese resultado. Incluyen el número de pasos, la cantidad de llamadas a modelos y herramientas, la selección de acciones, los reintentos, las desviaciones, los errores, la latencia, el consumo de recursos y la forma en que reaccionó ante información incompleta.

Un agente que resuelve una tarea con una llamada bien elegida y otro que la resuelve después de veinte reintentos no deberían recibir la misma evaluación, aunque el estado final sea idéntico.

La trayectoria es parte del producto

La trayectoria de un agente puede representarse como una secuencia de estados y acciones:

s0 → a1 → o1 → s1 → a2 → o2 → ... → sn

El estado incluye el contexto disponible, los permisos, los datos observados y las condiciones del entorno. Cada acción puede ser una llamada a una herramienta, una consulta a un modelo, una respuesta al usuario o una decisión de detenerse. La observación es el resultado real de esa acción, no la interpretación que el agente esperaba obtener.

Registrar esta secuencia permite distinguir entre una estrategia robusta y una solución accidental. Algunas señales útiles son:

• Eficiencia: pasos y llamadas necesarios para completar la tarea.
• Redundancia: consultas repetidas, herramientas duplicadas o relecturas sin valor adicional.
• Desviación: acciones que no contribuyen al objetivo o que alejan al agente del estado deseado.
• Dependencia de reintentos: proporción del resultado atribuible a reintentos automáticos.
• Fragilidad: sensibilidad a pequeños cambios en los datos, el orden de las respuestas o la disponibilidad de una herramienta.
• Reversibilidad: capacidad de deshacer o contener una acción cuando la decisión fue incorrecta.

La eficiencia no significa minimizar pasos a cualquier costo. Una validación adicional puede ser más valiosa que una trayectoria mínima si reduce el riesgo de una acción irreversible. La métrica correcta es la eficiencia condicionada por la calidad y la seguridad, no la velocidad aislada.

Evaluar el uso de herramientas como una capacidad independiente

Los agentes no solo generan texto. Seleccionan herramientas, construyen parámetros, interpretan respuestas y modifican sistemas externos. Cada una de esas capacidades merece evaluación propia.

Una evaluación completa del uso de herramientas debería revisar:

• Selección: si eligió la herramienta adecuada para el objetivo.
• Parámetros: si utilizó argumentos válidos, completos y suficientemente restringidos.
• Orden: si respetó las dependencias entre acciones.
• Validación: si comprobó que la herramienta realmente produjo el resultado esperado.
• Permisos: si actuó dentro del alcance autorizado y pidió confirmación cuando correspondía.
• Contención: si evitó herramientas innecesarias, acciones destructivas o consultas demasiado amplias.

El resultado correcto no compensa una acción peligrosa. Si un agente elimina datos innecesarios, expone información privada o ejecuta una operación con permisos excesivos antes de llegar al estado esperado, la trayectoria debe considerarse defectuosa aunque la prueba final sea positiva.

En sistemas reales conviene registrar también la diferencia entre una acción propuesta y una acción ejecutada. Esta distinción ayuda a evaluar políticas de autorización, aprobaciones humanas y controles de seguridad sin atribuirle al agente efectos que fueron bloqueados por la infraestructura.

La honestidad operacional requiere calibración

Un agente debe distinguir entre tres estados que suelen mezclarse:

• la tarea fue completada y existe evidencia suficiente;
• se obtuvo un resultado parcial o ambiguo;
• no existe evidencia suficiente para afirmar que la tarea terminó correctamente.

Esta distinción es especialmente importante cuando una herramienta responde con un error, un timeout, datos incompletos o un estado que contradice la expectativa del agente. Decir que una operación fue completada sin confirmación no es un problema de estilo; es un fallo operacional.

La calibración mide si la confianza expresada corresponde a la frecuencia real de aciertos. Si un agente declara una confianza de 80 por ciento en un conjunto de casos, aproximadamente ocho de cada diez afirmaciones deberían ser correctas. Puede medirse mediante métricas como el error de calibración esperado, la pérdida de Brier o curvas de confiabilidad. El trabajo de Guo y colaboradores sobre calibración de redes neuronales sigue siendo una referencia útil para entender esta separación entre precisión y confianza.

En agentes, la calibración debe evaluarse junto con la abstención. Un sistema confiable no intenta completar todas las tareas. También reconoce cuándo debe pedir información, solicitar aprobación, escalar a una persona o detenerse de forma segura.

Una métrica útil no es solo cuántas tareas resolvió, sino cuántas decisiones de abstención fueron apropiadas. Abstenerse ante una operación de alto riesgo sin evidencia suficiente puede ser mejor comportamiento que producir una respuesta aparentemente completa.

La recuperación ante fallos debe probarse deliberadamente

Las tareas exitosas no demuestran que un agente sepa recuperarse. La recuperación necesita escenarios diseñados para provocar fallos controlados.

Una suite de evaluación debería introducir, entre otros casos:

• timeouts y respuestas lentas;
• respuestas inválidas o con esquemas incompletos;
• herramientas temporalmente indisponibles;
• cambios de estado entre dos acciones;
• datos contradictorios provenientes de distintas fuentes;
• permisos insuficientes;
• resultados parciales después de una operación;
• errores transitorios que sí justifican un reintento;
• errores permanentes que deben detener el flujo.

La evaluación debe observar al menos cuatro etapas: detección, diagnóstico, recuperación y terminación segura. No basta con que el agente intente otra vez. Es necesario comprobar si identificó la causa probable, si cambió de estrategia, si evitó repetir indefinidamente la misma acción y si dejó el sistema en un estado conocido.

La prevención de bucles es una propiedad crítica. Un agente que reintenta una llamada fallida hasta agotar el presupuesto puede parecer persistente en una demo, pero es operacionalmente peligroso. Deben existir límites por herramienta, por tarea y por tiempo, además de una política explícita para escalar o abortar.

El costo real es mayor que el número de tokens

El costo de una trayectoria incluye mucho más que los tokens consumidos por el modelo. Una aproximación más realista puede expresarse así:

Costo total esperado = costo de modelos + costo de herramientas + infraestructura + latencia operativa + intervención humana + costo esperado de errores.

El costo de modelos contempla tokens de entrada y salida, llamadas de evaluación y modelos auxiliares. El costo de herramientas incluye APIs externas, búsquedas, navegadores, bases de datos y operaciones con precio variable. La infraestructura incorpora cómputo, almacenamiento, colas y observabilidad. La latencia puede convertirse en costo cuando bloquea a usuarios o procesos dependientes. La intervención humana debe incluir revisiones, correcciones y escalaciones.

El componente más difícil de ignorar es el costo esperado de los errores. Una acción incorrecta puede requerir compensaciones, recuperación de datos, atención al cliente o pérdida de confianza. Por eso, una trayectoria ligeramente más precisa no necesariamente es mejor si requiere varias veces más recursos o incrementa de forma desproporcionada el riesgo.

En producción conviene definir presupuestos explícitos: máximo de llamadas, tiempo límite, costo máximo por tarea, número de reintentos y nivel de intervención permitido. La evaluación debe reportar calidad ajustada por costo y no únicamente una tasa de éxito.

Un marco reproducible de evaluación

Para comparar versiones de un agente, la ejecución debe producir trazas completas y estructuradas. Una traza mínima debería incluir:

• identificador de la tarea y datos de entrada;
• estado inicial y estado posterior a cada acción;
• eventos de razonamiento observables sin depender de cadenas internas no garantizadas;
• herramienta seleccionada y parámetros enviados;
• respuesta recibida, código de error y latencia;
• versión del modelo, prompt, herramientas y políticas;
• permisos disponibles y aprobaciones requeridas;
• reintentos, fallos y decisiones de abstención;
• criterios de éxito verificables;
• consumo de tokens, infraestructura y tiempo total.

La reproducibilidad exige versionar no solo el modelo. También deben fijarse las definiciones de herramientas, los datos de prueba, las políticas de permisos, las condiciones del entorno y los evaluadores. Si el mundo externo cambia entre ejecuciones, debe registrarse qué cambió y cómo afecta la comparación.

Los criterios de éxito deben ser independientes del texto generado siempre que sea posible. Para una operación transaccional, validar el estado de la base de datos suele ser más confiable que evaluar la explicación final. Para un cambio de código, ejecutar pruebas y revisar el diff puede aportar más evidencia que calificar el resumen del agente.

Qué cubren los benchmarks existentes

Los benchmarks públicos son útiles, pero no deben tratarse como una medida completa de preparación para producción.

AgentBench evalúa modelos como agentes en múltiples entornos, incluyendo tareas de interacción con bases de datos, sistemas operativos y navegación. Su valor principal es mostrar que el desempeño cambia significativamente según el entorno y que la capacidad de responder preguntas no equivale a la capacidad de actuar. Sin embargo, sus resultados agregados no cubren necesariamente todos los costos, permisos y riesgos de un sistema empresarial.

τ-bench se enfoca en interacciones entre agentes, herramientas y usuarios en dominios como comercio y aerolíneas. Es especialmente relevante para evaluar cumplimiento de políticas y consistencia en flujos con herramientas. También muestra por qué una sola ejecución exitosa no es suficiente: la variabilidad entre trayectorias y la consistencia bajo múltiples intentos importan.

BrowserGym proporciona un entorno para definir y comparar agentes que interactúan con navegadores. Permite estudiar acciones web en tareas más cercanas a interfaces reales, aunque el éxito en un navegador no representa automáticamente seguridad, recuperación o costo en sistemas productivos.

WorkArena evalúa agentes en tareas de trabajo del conocimiento sobre ServiceNow. Su importancia está en medir flujos empresariales con interfaces, dependencias y objetivos concretos, pero su cobertura está limitada por el dominio y por las características del entorno.

SWE-bench evalúa la capacidad de resolver issues reales de repositorios de software mediante cambios que deben pasar pruebas. Es una referencia importante para agentes de programación, aunque pasar las pruebas no garantiza que el cambio sea mantenible, seguro, eficiente o apropiado para el contexto completo del producto.

Estos benchmarks cubren dimensiones valiosas: éxito, interacción con herramientas, navegación, políticas o ejecución de cambios. Lo que suelen omitir, o reportar de forma incompleta, son el costo total, la calibración, la calidad de la abstención, los fallos catastróficos, la intervención humana, la reversibilidad y la distribución completa de las trayectorias.

Un scorecard multidimensional

Una evaluación operativa puede organizarse en un scorecard con dimensiones separadas:

• Resultado: porcentaje de tareas completadas y calidad verificable del estado final.
• Trayectoria: pasos, eficiencia, redundancia, desviaciones y dependencia de reintentos.
• Herramientas: selección, parámetros, orden, validación y cumplimiento de permisos.
• Calibración: correspondencia entre confianza y acierto, calidad de la abstención y honestidad ante evidencia insuficiente.
• Recuperación: detección de fallos, diagnóstico, cambio de estrategia, límites de reintento y terminación segura.
• Seguridad: acciones no autorizadas, exposición de datos, operaciones irreversibles y severidad de los peores casos.
• Coste: tokens, llamadas, infraestructura, latencia, intervención humana y costo esperado de errores.
• Reproducibilidad: variación entre ejecuciones, sensibilidad al entorno y estabilidad ante cambios menores.

Estas dimensiones pueden combinarse en una vista ejecutiva, pero no deben reducirse a un único número durante el análisis. Un promedio ponderado puede ocultar un fallo catastrófico: por ejemplo, una alta tasa de éxito puede compensar estadísticamente una pequeña proporción de acciones destructivas. En sistemas operativos, esa compensación es inaceptable.

Por eso deben reportarse distribuciones, percentiles, intervalos de confianza, casos extremos y severidad de los fallos. El p95 de latencia, el peor costo por tarea, la tasa de bucles, la frecuencia de afirmaciones sin evidencia y el número de operaciones irreversibles son tan relevantes como el promedio.

De la métrica al sistema de evaluación

Una arquitectura de evaluación madura separa al menos cuatro componentes:

1. Generador de tareas: crea casos representativos, variaciones y escenarios adversariales.
2. Entorno controlado: ofrece herramientas, datos, permisos y fallos reproducibles.
3. Recolector de trazas: captura eventos, estados, costos y versiones sin depender únicamente de logs textuales.
4. Evaluadores: verifican el estado final y califican la trayectoria mediante reglas, pruebas, simuladores o revisión humana.

El evaluador no debería ser el mismo agente que ejecutó la tarea. La autoevaluación puede servir como señal adicional, pero no como evidencia principal. Para decisiones críticas se necesitan verificadores externos, invariantes de dominio y controles de autorización.

También es útil mantener un conjunto de regresión. Cada cambio en el modelo, el prompt, una herramienta o una política debe volver a ejecutarse contra tareas normales, casos límite y escenarios de fallo. Mejorar la tasa de éxito mientras empeora la calibración o aumenta el costo no es una mejora completa.

La pregunta correcta para producción

El éxito de la tarea seguirá siendo importante. Sin él, ninguna optimización de proceso tiene sentido. Pero es solo la primera pregunta.

La pregunta completa es: ¿el agente resolvió la tarea de manera segura, eficiente, explicable, calibrada y recuperable?

Un agente confiable no es el que siempre intenta actuar ni el que produce la respuesta más convincente. Es el que sabe qué hacer, cuándo usar una herramienta, cómo validar lo que ocurrió, cuándo corregir el rumbo y cuándo detenerse. También es el que puede operar dentro de un presupuesto y dejar una traza suficiente para entender sus decisiones.

Las capacidades de los agentes se vuelven útiles cuando pueden convertirse en sistemas observables y evaluables. Pasar de medir únicamente resultados a medir trayectorias es el paso necesario para construir agentes que no solo funcionen en una demostración, sino que puedan operar de forma responsable dentro de productos reales.

Fuentes y lecturas recomendadas

• Yanchao Liu et al., AgentBench: Evaluating LLMs as Agents, arXiv.
• Shunyu Yao et al., τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains, arXiv.
• Shuyan Deng et al., BrowserGym: A Framework for Defining and Benchmarking Web Agents, arXiv.
• WorkArena, How Capable Are Web Agents at Solving Common Knowledge Work Tasks?, arXiv.
• Carlos E. Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, arXiv.
• Chuan Guo et al., On Calibration of Modern Neural Networks, arXiv.