AWS propone vigilar agentes con dos capas: salud de infraestructura y calidad real de la tarea

La propuesta publicada. AWS presentó el 11 de septiembre una arquitectura de referencia para monitorear sistemas multiagente en producción mediante dos capas distintas. Amazon Bedrock AgentCore Evaluations puntúa interacciones vivas en dimensiones como utilidad, corrección y logro del objetivo, mientras AWS DevOps Agent investiga incidentes de infraestructura analizando registros, métricas y trazas. El ejemplo utiliza un sistema de reservas aéreas con cuatro agentes especializados. AWS no afirma que esa combinación elimine los fallos; su argumento es que una sola clase de observabilidad deja zonas ciegas importantes cuando el comportamiento depende de múltiples modelos, herramientas y handoffs.

El problema central son los fallos silenciosos. Una aplicación tradicional suele revelar problemas con errores explícitos, excepciones o degradación de latencia. Un agente puede ejecutar todas sus llamadas sin devolver un error técnico y aun así fallar el objetivo del usuario: elegir una herramienta equivocada, perder contexto o enrutar trabajo al especialista incorrecto. También puede ocurrir lo contrario: una política IAM ausente o un throttling del modelo puede degradar el comportamiento sin producir un error claro en la superficie. AWS plantea que estas dos familias de fallos necesitan señales y procesos de investigación distintos.

AgentCore Evaluations observa el resultado conductual. La capa de evaluación usa trazas de ejecución para puntuar muestras de interacciones y puede trabajar en línea o bajo demanda. AWS señala que las evaluaciones se ejecutan de forma asíncrona para no añadir latencia visible al usuario y que los equipos pueden configurar evaluadores propios además de los integrados. La compañía advierte también que el enfoque LLM-as-a-judge no constituye una verdad absoluta y debe calibrarse con expertos del dominio. Esa cautela es relevante: una puntuación automática sirve como señal de cambio, pero no reemplaza un conjunto de casos con criterio humano.

DevOps Agent investiga la infraestructura. La segunda capa examina CloudWatch, IAM, tiempos de invocación y relaciones entre servicios para proponer una causa raíz y pasos de remediación. En el ejemplo, un output vacío puede conectarse con un permiso faltante; una subida de timeouts puede relacionarse con límites de una región o modelo. El objetivo es evitar que un operador recorra manualmente decenas de logs antes de encontrar el componente responsable. La utilidad depende de que las trazas y permisos permitan reconstruir la cadena, por lo que la instrumentación sigue siendo una condición del diagnóstico.

Los sistemas multiagente complican el mapa. En un patrón tipo swarm, el supervisor puede entregar una tarea a otro agente y ese agente decidir quién continúa. El grafo real cambia según la solicitud y no siempre vuelve al mismo punto de coordinación. Esto hace más difícil instrumentar una ruta fija. AWS propone mantener trazas suficientemente ricas para reconstruir la secuencia y luego superponer métricas de calidad. La idea evita reducir un sistema agentic a disponibilidad del servidor: una plataforma puede estar verde en infraestructura mientras el porcentaje de tareas terminadas cae de forma material.

La arquitectura abre una disciplina de operación. Separar salud técnica y salud de resultado permite establecer alertas diferentes. Una caída de Goal Success Rate puede activar revisión de prompts, herramientas o datos; un error de autenticación necesita otro equipo y otro remedio. También mejora la experimentación: si se cambia un modelo o una estrategia de orquestación, puede observarse si la calidad sube sin empeorar costos o estabilidad. La producción se convierte en fuente de evidencia para la siguiente versión, siempre que las métricas se definan alrededor del objetivo del usuario y no solo de la actividad interna.

Lectura Goatify. Para Goatify, la noticia ofrece una regla de arquitectura inmediata: nunca confundir «la automatización corrió» con «la automatización resolvió». Nuestras habilidades deberían tener una capa de ejecución que confirme llamadas, permisos y destinos, y una capa de resultado que compruebe si el objetivo terminó correctamente. Cuando ambas señales se guardan separadas, el soporte puede responder con precisión: sabemos si falló la infraestructura o la lógica del agente. Esa diferencia reduce tiempo de diagnóstico y, más importante, evita mostrar estados verdes cuando la experiencia real del cliente ya está degradada.