Tu AI Agent "Funciona" Hasta Que le Das una Tarea Real — y No Tienes Ni Idea de Cuánto Falla
Construyes un agent. Lo pruebas con tres prompts. Responde bien. Lo despliegas.
*Eso no es una evaluación. Es un wish cast. *
El 95% de los agents que veo en producción no tienen un solo test estructurado. El criterio de calidad es "el LLM devolvió JSON válido" o "no se colgó en el primer intento".
Eso no mide nada.
Un evaluation harness no es un lujo de equipo grande. Es lo único que separa un agent que resuelve problemas de uno que parece resolverlos hasta que un cliente real lo descubre.
Si no puedes medir cómo falla tu agent, no puedes mejorarlo. Y si no puedes mejorarlo, no deberías tenerlo en producción.
---
El Problema: Medir un AI Agent NO es Medir un API Endpoint
Los desarrolladores tratamos los agents como software determinista porque es lo que sabemos medir.
❌ El enfoque equivocado:
- "El agent devolvió una respuesta → test passed"
- "No se cayó en 100 ejecuciones → es estable"
- "El JSON tiene la estructura correcta → funciona"
✅ Lo que realmente necesitas medir:
- ¿La respuesta resuelve el problema del usuario?
- ¿El agent tomó la decisión óptima o solo una que no rompe nada?
- ¿El coste por tarea es sostenible o estás quemando tokens en loops infinitos?
- ¿El reliability cae cuando aumentas la complejidad de las tasks?
Un API endpoint o devuelve 200 o 500. Un AI agent puede devolver una respuesta perfectamente formateada que esté completamente equivocada. Y tu monitorización tradicional no te va a avisar.
El problema de fondo es que los LLMs son probabilísticos. Dos ejecuciones con el mismo input pueden producir resultados diferentes. Una puede ser brillante. La siguiente, un desastre. Sin evaluación, no sabes cuál es cuál.
---
El Harness de Evaluación en 4 Capas
Después de enviar agents a producción para gestorías, despachos legales y servicios de emergencias, he destilado el patrón que funciona. Lo llamo el Harness de Evaluación en 4 Capas.
No necesitas herramientas caras. Necesitas un pipeline que mida lo que importa.
Capa 1: Accuracy por Tarea (Unit Testing para LLMs)
La primera capa mide si el agent produce la salida correcta para un conjunto de tareas conocidas.
Creas un golden dataset: pares de input → output esperado. No necesitas miles. Con 50–100 casos bien diseñados cubres el 80% de los escenarios.
Cada test case verifica:
- ¿El agent seleccionó la tool correcta?
- ¿Extrajo las entidades correctas?
- ¿El orden de las acciones es el óptimo?
El umbral mínimo que uso: 85% de accuracy en acciones críticas. Por debajo, el agent no debería ver producción.
Capa 2: Reliability (Consistencia en Ejecución)
Un agent puede ser preciso una vez y fallar estrepitosamente la siguiente. La capa de reliability mide eso.
Ejecutas cada test case múltiples veces (10–20 iteraciones) y mides la varianza.
Lo que buscas:
- Success rate > 90% en todas las iteraciones
- Baja varianza en duración — si un execution tarda 2s y el siguiente 30s, tienes un problema de tool orchestration
- Path consistency — las tools se llaman en el mismo orden lógico
El reliability score compuesto debería estar por encima de 0,80 para considerar el agent estable.
Capa 3: Coste Real por Tarea
Aquí es donde la mayoría se lleva las sorpresas. No miden lo que cuesta cada ejecución porque piensan "son céntimos por llamada".
El problema no es una llamada. Son 10.000.
El coste real de un agent incluye:
- Tokens de input (contexto + historial)
- Tokens de output (respuestas generadas)
- Tool calls fallidas que consumen tokens y no producen resultado
- Loops de retry que multiplican el coste
Regla que aplico: si el coste por tarea supera 3x el coste de la ejecución ideal (sin retrys, sin tool calls fallidas), el agent tiene un problema de diseño, no de modelo.
No estás midiendo para ahorrar céntimos. Estás midiendo para detectar patrones de ineficiencia que indican que el agent está tomando malas decisiones.
Capa 4: Evaluación por Escenario Real (End-to-End)
La última capa es la más importante y la que casi nadie hace. No pruebas unitarias. Pruebas flujos completos que imitan lo que un usuario real va a pedir.
Un golden dataset de escenarios. No prompts aislados. Secuencias completas:
- Escenario 1: "Soy un autónomo que quiere darse de alta, necesito saber los pasos y los documentos"
- Escenario 2: "Ya estoy dado de alta, necesito presentar el modelo 130 del primer trimestre"
- Escenario 3: "Me han llegado dos facturas de proveedores, una con IVA y otra sin, ¿cómo las registro?"
Para cada escenario, defines:
- Criterio de éxito objetivo: ¿el agent completó el flujo completo?
- Número de intervenciones humanas necesarias: ¿pidió ayuda? ¿se desvió?
- Tiempo hasta resolución: ¿es más rápido que un humano haciendo la misma tarea?
- Calidad de la respuesta: ¿la respuesta es correcta, completa y accionable?
El threshold de producción: success rate > 80% en escenarios completos con menos de 1 intervención humana por cada 5 escenarios.
---
Por Qué el 90% de los Harnesses Fracasan
He visto a equipos construir evaluation systems y abandonarlos a las dos semanas. Siempre por las mismas razones.
❌ Miden lo que es fácil, no lo que importa. Miden latencia y estructura de JSON. No miden calidad de decisión.
❌ El dataset de prueba es estático. Crean 20 casos, los corren una vez, y nunca los actualizan. Cuando el agent cambia, las evaluaciones quedan obsoletas.
❌ No automatizan la evaluación. Tienen scripts sueltos que ejecutan manualmente. La evaluación debería correr en cada deploy.
❌ El criterio de éxito es binario. "Funciona o no funciona". Un agent puede fallar el 30% de las veces y parecer que funciona en las demos.
La solución: trata el evaluation harness como parte del código. Versiona los test cases. Automatiza las ejecuciones en CI/CD. Y define thresholds claros que bloqueen deploys si no se cumplen.
---
Cómo Implementarlo sin Morir en el Intento
No necesitas una plataforma cara. Necesitas tres cosas:
- Un directorio de test cases en tu repo, versionado con Git
- Un script de evaluación que corre contra tu agent
- Un reporte que se genera en cada ejecución
El thresholds.json define qué significa "pasar" la evaluación:
Si blockDeployOnFailure es true y alguna métrica no pasa, el deploy se cancela. Es la única forma de que la evaluación no sea un PDF bonito que nadie lee.
---
El Coste de No Evaluar
Voy a ser directo.
Si no mides cómo falla tu agent, estás apostando tu producto a que el LLM acierte siempre. Y los LLMs no aciertan siempre.
Un agent sin evaluation harness no es un producto. Es un experimento con usuarios reales como cobayas.
*El 95% de los agents en producción están rotos y nadie lo sabe porque nadie mide. *
Empieza con 50 casos de prueba. Automatiza las ejecuciones. Bloquea los deploys que no pasen.
No es opcional. Es la diferencia entre vender un producto que resuelve problemas y vender humo que eventualmente explota.
Construye el harness. Mide. Repite.
Eso es lo que separa a los que envían software de verdad de los que solo parece que lo hacen.
Artículos relacionados
- Evaluation Harness para AI Agents: El Sistema que Mide Si Tu Agent Realmente Funciona
- Por Qué El 90% de los AI Agents Se Rompen en Producción y Cómo Arreglarlo
- AI Agents: El 99% de los Tests Unitarios No Detecta el Fallo Real — Cómo Construir un Evaluation Harness que Mida lo que Importa
- Cómo Evaluar AI Agents en 2026: El Harness de 4 Buckets que Detecta Errores Silenciosos
- El 95% de los AI Agents No Son Agents: Cómo Construir el 5% Que Realmente Funciona en 2026
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
