Los agentes fallan de dos maneras que se parecen desde afuera: no pueden hacer el trabajo o creen que lo hicieron bien

El mismo síntoma puede esconder causas opuestas. Un usuario dice «no reservó» y el sistema puede haber fallado porque perdió permiso para llamar a una herramienta, porque el modelo eligió la herramienta equivocada o porque entendió mal la intención y completó otra acción. Desde la interfaz, todos parecen un único incidente. Si el equipo no separa la cadena técnica del resultado semántico, empieza a investigar en el lugar equivocado. La primera disciplina operativa consiste en preguntar dos cosas diferentes: ¿cada componente pudo ejecutar lo previsto? y ¿lo ejecutado resolvió realmente la tarea del usuario?

El fallo técnico necesita evidencia objetiva. Credenciales vencidas, límites de API, problemas de red, timeouts, errores de formato o recursos inexistentes pueden detectarse con trazas y estados. La investigación debería reconstruir qué herramienta se llamó, con qué identidad, qué respondió y cuánto tardó. Un agente no debería reinterpretar libremente esos hechos. Si la API devolvió 403, es un evento concreto. El valor de la capa de observabilidad está en preservar esa certeza para que un diagnóstico semántico posterior no confunda una limitación externa con una mala decisión del modelo.

El fallo de resultado puede ocurrir con todo en verde. El agente puede invocar la herramienta correcta, recibir 200 OK y aun terminar mal: elegir la fecha equivocada, olvidar una restricción, crear un archivo que no cumple el formato o enviar una propuesta que no responde al objetivo. Estas fallas necesitan evaluaciones ligadas al resultado esperado. Algunas pueden comprobarse con reglas; otras requieren una rúbrica o revisión humana. El punto es que éxito de transporte no debe convertirse automáticamente en éxito de tarea. Son capas relacionadas, pero distintas.

La frontera intermedia son los fallos de orquestación. En sistemas con varios agentes, un supervisor puede entregar trabajo al especialista equivocado o perder una dependencia entre pasos. La infraestructura funciona y cada subagente puede ejecutar, pero el flujo global queda incompleto. Conviene registrar handoffs como eventos de primera clase: quién entregó qué objetivo, qué contexto viajó y qué criterio indicaba que la subtarea terminó. Esta trazabilidad permite saber si el error ocurrió dentro de un agente o en la coordinación entre ellos.

Una taxonomía mejora los reintentos. Si el error es un timeout, repetir puede funcionar. Si el agente eligió mal la herramienta, repetir exactamente la misma trayectoria solo gastará recursos. Si falta una aprobación, el sistema debe esperar y no regenerar. Clasificar causas permite definir políticas de recuperación específicas. También evita bucles donde una automatización insiste porque interpreta toda falta de éxito como indisponibilidad temporal. Un reintento inteligente empieza por saber qué clase de fallo ocurrió y qué condición tendría que cambiar para que el siguiente intento sea diferente.

Los indicadores deben convivir. Un tablero puede mostrar disponibilidad de herramientas, tasa de ejecución, Goal Success Rate, correcciones humanas y escalaciones. Ninguna métrica explica todo. Una subida de errores técnicos con calidad estable sugiere degradación de infraestructura; calidad baja con infraestructura sana apunta a lógica, contexto o modelo. Cuando ambas caen, quizá exista una dependencia compartida. La utilidad del tablero está en permitir comparaciones y tendencias, no en condensar toda la salud del sistema en un único porcentaje que oculta cuál dimensión necesita trabajo.

Lectura para Goatify. En nuestras automatizaciones, cada cierre debería registrar por separado transporte y resultado. «El correo se envió» se demuestra leyendo Sent; «el correo era el correcto» se valida contra destinatario, asunto y contenido esperado. «El JSON se subió» no equivale a «el feed es válido». Esta separación puede parecer redundante, pero reduce falsos éxitos y acelera soporte. Si construimos la taxonomía desde ahora, podremos reintentar con criterio, comunicar fallos con precisión y medir confiabilidad sin maquillar una tarea incorrecta detrás de llamadas técnicamente exitosas.