Tu AI Agent Puede Devolver "Éxito" y Haber Fracasado por Completo — Ningún Test Unitario lo Verá Jamás
Tu agent llama a la API. Recibe un HTTP 200. Ejecuta la tool call. Todo parece perfecto.
*Y la tarea ha fallado por completo. *
El agent escribió en el registro equivocado. La acción no tuvo el efecto esperado sobre el estado del sistema. El outcome en el mundo real no coincidió con lo que el output sugería.
Y ningún test unitario, ningún try-catch, ningún framework de testing tradicional va a detectarlo.
Este es el punto ciego estructural del desarrollo de agents en 2026: la mayoría se despliegan sin evaluación estructurada, y sus errores son silenciosos, sistémicos e invisibles. La sabiduría convencional dice que el problema es el modelo — "cambia de modelo, afina el prompt, añade más herramientas". Es exactamente el mismo error categorial que comete el 80% de los SaaS al estructurar sus planes a ciegas: optimizar la cifra en vez de instrumentar el dato.
No necesitas un mejor modelo. Necesitas un harness que clasifique los fallos antes de que puedas medirlos, y que los mida antes de que puedas mejorarlos.
La jerarquía es clasificar → medir → optimizar. Y casi nadie hace los dos primeros pasos.
---
El Punto Ciego Estructural de los Tests Unitarios
Un test unitario verifica que el código devuelve el output correcto. Un agent acierta o falla a nivel de outcome en el mundo real.
Esas dos cosas viven en planos distintos, y ahí reside el problema.
Mira este ejemplo. Tu agent tiene una tool que registra clientes potenciales en un CRM:
Ahora mira lo que pasa en producción real:
El test unitario pasó porque verifica el output del código. El agent falló porque el outcome no ocurrió en el mundo.
*Esa brecha entre output y outcome es exactamente el espacio que ningún framework de testing tradicional cubre. *
Y los agents que construyes hoy fallan ahí constantemente. No excepcionalmente — constantemente.
---
Por Qué el Try-Catch es un Error Categorial
Aquí está el giro contraintuitivo que cambia todo lo que sabes sobre errores en agents:
El try-catch modela el fallo como flujo de control excepcional. Pero la clase de fallo dominante en agents no es excepcional.
El sistema completa la ejecución. No lanza nada. No se interrumpe. Y el error vive en el resultado.
El agent nunca lanza una excepción. Devuelve un objeto de resultado "exitoso" que contiene la catástrofe completa sin que nadie se entere.
La recuperación de errores en agents no es un try-catch genérico. Es una máquina de estados por fase — planificar → ejecutar → generar — con un clasificador de errores explícito que decide cómo y cuándo recuperarse:
La decisión de recuperar — reintentar, replanificar, escalar, abortar — pertenece a la taxonomía de evaluación, no al manejador de excepciones.
Esa distinción es la que separa un harness real de un script con try/except.
---
El Framework: El Harness de 4 Buckets para Evaluación de AI Agents
No hay atajo. Este es el proceso completo que convierte tu agent de "creo que funciona" a "medido y justificable".
Paso 1 — Diseña la taxonomía de fallos específica de tu dominio
Los buckets no se copian. Se derivan de los señales observables de tu propio agent.
En un agent de código, el bucket dominante podrías ser selección de herramienta incorrecta. En un agent de soporte, probablemente sea política alucinada. Si copias una taxonomía genérica, obtienes buckets que no clasifican nada de tu realidad.
Define cada bucket en términos de evidencia concreta en tus logs. No en términos abstractos.
| Bucket | Señal observable en tus logs |
|---|---|
| ✅ Correcto | Outcome verificado = esperado |
| 🔧 Herramienta errónea | Tool call ≠ tool requerida para la subtarea |
| 🔁 Bucle oculto | Estado no cambió pese a inputs válidos |
| 🌀 Alucinación de acción | Razón de la acción no verificable en el contexto |
Paso 2 — Construye un suite de tareas doradas
30 a 50 tareas representativas por tipo de tarea. Cada una con un outcome esperado verificable y criterios de aprobación explícitos.
El golden set es el suelo del harness. Sin él, no hay nada que medir.
Paso 3 — Instrumenta el agent
Logs estructurados por fase — plan, tool calls, outputs — que hagan cada ejecución reproducible y clasificable a posteriori.
Sin esto, los buckets no tienen datos que clasificar:
Paso 4 — Ejecuta el harness sobre cada candidato
Cada vez que cambias de modelo, de prompt o de versión de herramientas, ejecutas el harness completo. Calculas precisión, fiabilidad y consumo de recursos por tipo de tarea, comparando contra el baseline.
Paso 5 — Convierte el harness en un gate de despliegue
Ejecución en cada cambio. Tracking de métricas en el tiempo. Rollback automático ante regresiones:
Esto es lo que convierte "creo que funciona" en una afirmación medida.
---
"¿La evaluación con LLM no es subjetiva?"
Te escucho. "¿Quién decide que una ejecución falló?"
La respuesta es un enfoque híbrido que no depende de un juez único:
- Comprobaciones deterministas de outcome: aserciones sobre el estado final, verificación de tool calls.
- LLM-as-judge calibrado contra etiquetas humanas en un subset del golden set.
Los 4 buckets son una capa de clasificación, no un juez único. Las reglas deterministas cazan el 80% de los fallos silenciosos (el ejemplo del registro equivocado). El LLM-as-judge cubre el resto, y se calibra contra personas reales — no contra otro LLM.
---
"¿No es overkill para un prototipo?"
El harness arranca con un smoke suite de 10 tareas y los 4 buckets. El coste es incremental.
Se amortiza en la primera regresión silenciosa que detecta antes de llegar a producción. Y para un agent de prototipo, la pregunta relevante no es "¿puede hacer esto?" sino "¿puedo justificar que haga esto en producción?"
Un agent sin harness no puede justificarse. No puede mejorarse con evidencia. No puede defenderse contra regresiones.
---
La Lección que se Transfiere Completa
El paralelismo con el pricing es el argumento profundo de todo esto. El 80% de los SaaS estructura sus planes a ciegas — optimizan la cifra en vez de instrumentar el uso. Los equipos de agents optimizan el prompt en vez de instrumentar los outcomes.
Ambos fracasos son epistemológicos, no numéricos. Ambos comparten la misma jerarquía rota: optimizar antes de medir, medir antes de clasificar.
Primero se mide. Luego se optimiza. Siempre en ese orden.
Lo que te llevas
- Los tests unitarios detectan crashes y violaciones de contrato, no fallos silenciosos de outcome — son complementarios al harness, no sustitutos.
- El try-catch es un error categorial: el fallo dominante en agents no es excepcional, vive en el resultado.
- Los 4 buckets convierten los logs ruidosos en una señal agregable por tipo de tarea, comparable entre candidatos y trackeable en el tiempo.
- Medir consumo por tarea (tokens, tool calls, latencia) añade la tercera dimensión: no basta con que sea correcto, tiene que ser eficiente y fiable en cada tipo de tarea.
- El harness es el único mecanismo que hace seguros los rollbacks y las actualizaciones de modelo.
El futuro de los agents no lo deciden los modelos más grandes ni los prompts más largos. Lo deciden los equipos que instrumentan sus outcomes, miden por tipo de tarea y convierten cada regresión silenciosa en una señal accionable.
El harness no es un gasto de ingeniería. Es la diferencia entre un agent que demuestra valor y un agent que finge tenerlo.
Artículos relacionados
- Evaluation Harness para AI Agents: El Sistema que Mide Si Tu Agent Realmente Funciona
- 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
- Error Recovery en AI Agents 2026: El 95% se Rompe en el Primer Error Real — y No, un Try-Catch No Va a Salvarlos
- Evaluación de AI Agents 2026: El Try-Catch es un Error Categorial — y el 95% de tus Agents se Rompe en Silencio
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
