Fallos silenciosos: cuando un agente responde pero no resuelve

El 24 de julio de 2026, AWS describió un problema que las métricas de disponibilidad no detectan: un agente puede responder sin un error técnico y, aun así, fracasar en la tarea. Puede consultar la fuente equivocada, repetir una llamada, detenerse antes de actuar o afirmar que completó una acción que el sistema de destino no confirma. Si solo se mide latencia, coste y códigos de error, esos casos parecen éxitos.\n\n## Medir el objetivo, no solo la respuesta\n\nLa documentación de AgentCore Insights analiza trazas de sesiones y agrupa fallos por causa. Incluye errores de herramienta, alucinaciones, acciones incorrectas, problemas de contexto, repetición y terminación prematura. El punto útil no depende de AWS: antes de desplegar un agente, hay que definir qué resultado verificable cuenta como éxito. “Respondió” no basta; “la cita quedó creada”, “el informe contiene la fuente correcta” o “el pedido recibió confirmación” sí son comprobables.\n\n## Seguir el recorrido\n\nUna sesión conserva el contexto de una conversación; una traza muestra una interacción; un span registra una operación como una llamada a herramienta. Esa jerarquía, explicada por AWS, permite bajar de una queja a la decisión o llamada que cambió el resultado. Guarda el objetivo, herramientas, entradas, salidas, respuesta y confirmación del sistema de destino. Filtra siempre datos sensibles.\n\n## Cinco comprobaciones\n\nPrimero, revisa una muestra de sesiones marcadas como correctas y verifica el efecto fuera del texto del agente. Segundo, etiqueta la causa: dato, permiso, instrucción, herramienta o decisión. Tercero, agrupa causas repetidas. Cuarto, cambia una sola cosa —una descripción, un permiso, una validación—. Quinto, compara la variante con casos equivalentes antes de declararla mejor. Los evaluadores automáticos ayudan, pero también pueden errar; conserva ejemplos revisados por personas.\n\nUn agente fiable no es el que nunca emite una excepción. Es el que deja evidencia suficiente para detectar una respuesta fluida que no resolvió el trabajo. La pregunta que conviene automatizar es: ¿qué prueba que el objetivo del usuario se completó?