Cómo evaluar un modelo agentic por trabajo completado y no solo por benchmarks

1. Define cinco tareas que realmente facturarías. Evita empezar por acertijos o prompts aislados. Elige workflows que representen el producto: investigar fuentes y escribir un artículo, revisar un documento y proponer cambios, publicar un recurso, preparar una campaña o clasificar un conjunto de leads. Cada tarea debe tener entrada estable, herramientas permitidas y un resultado verificable. Así, cuando compares dos modelos, no preguntas cuál “parece más inteligente”, sino cuál termina mejor el trabajo que tu cliente compra. Las pruebas propias complementan benchmarks públicos porque reflejan tu orquestación, tus conectores y tus estándares.

2. Escribe criterios de aceptación antes de correr. Define qué significa aprobar: número de fuentes verificadas, campos obligatorios, cero duplicados, estructura correcta, acción externa confirmada o límite máximo de errores. Incluye criterios de seguridad y de estilo cuando sean relevantes. No cambies la rúbrica después de ver qué modelo ganó; eso introduce sesgo. Si la tarea tiene una fase crítica, como sobrescribir un archivo vivo, exige evidencia posterior. Un agente que dice “hecho” sin demostrar el estado final no debe recibir la misma puntuación que uno que completa y verifica la operación.

3. Registra el run completo. Para cada modelo, guarda tokens, cache reads cuando estén disponibles, número de tool calls, costo de servicios externos, tiempo total, reintentos y cantidad de intervención humana. Anthropic destaca cambios de economía de Fable 5.1 que pueden ser especialmente relevantes en trabajo agentic; tu prueba debe capturar ese efecto en condiciones reales. También anota si el agente se quedó atrapado en ciclos o produjo trabajo que luego hubo que rehacer. La métrica central es costo y tiempo por tarea aceptada, no costo de la primera respuesta.

4. Separa calidad de autonomía. Un modelo puede producir una salida excelente con mucha supervisión o una salida suficientemente buena de forma autónoma. Ambas capacidades sirven para productos distintos. Puntúa por separado exactitud, profundidad, seguimiento de instrucciones, uso de herramientas, recuperación de errores y claridad de comunicación. Añade una penalización cuando el sistema ejecuta una acción fuera de alcance aunque el resultado final sea correcto. La autonomía valiosa no es solo avanzar; es avanzar dentro de límites. Ese detalle evita que un agente agresivo parezca superior porque toma atajos que un producto serio no debería permitir.

5. Repite y observa variabilidad. Una sola ejecución puede favorecer por azar a un modelo. Corre cada tarea varias veces con entradas equivalentes y mide dispersión. Revisa si los fallos aparecen siempre en la misma fase: retrieval, razonamiento, herramienta, verificación o formato. Si un modelo es excelente en investigación pero débil en control de navegador, puede seguir siendo el mejor componente para una habilidad específica. No necesitas un campeón único para toda Goatify. Una arquitectura con routing puede usar diferentes modelos según el contrato, siempre que el costo de complejidad adicional esté justificado.

6. Convierte la evaluación en decisión de producto. Al final, crea una tabla con costo por tarea aceptada, latencia, tasa de éxito, intervención humana y principales modos de fallo. Define umbrales para elegir modelo, nivel de esfuerzo o fallback. Vuelve a correr la suite cuando cambie un modelo, su precio o una herramienta crítica. Así evitas migraciones por hype y también detectas mejoras reales rápidamente. El benchmark más defensible es el que refleja tus clientes. Si una actualización reduce costo y aumenta éxito en esas tareas, tienes una razón de negocio para adoptarla y una cifra interna para sostener la decisión.