Amazon lanza CloudWatch Omni para medir si un agente acierta, no solo si falla

Amazon ha presentado CloudWatch Omni, una herramienta de observabilidad que reúne en una misma vista las trazas de agentes de IA, los servicios de la aplicación y la infraestructura. El argumento que da la compañía para justificarla es sencillo: un agente puede responder en 600 milisegundos con una tasa de error de cero y, aun así, decirle a un cliente que se le deben 40 dólares cuando la política marca 140, porque recuperó la versión del documento del trimestre anterior. Paneles en verde, nada roto y el resultado está mal.

El anuncio viene acompañado de una tesis sobre qué debe medir un sistema de observabilidad cuando hay agentes de por medio. Durante veinte años, dice Amazon, la operación de software se ha organizado alrededor de una sola pregunta: ¿está roto? Métricas, logs y trazas, con tracing distribuido capaz de seguir una petición por docenas de servicios. Todo eso descansa en una asunción razonable: que un fallo acaba apareciendo como algo que una máquina puede medir. Con los agentes, buena parte del comportamiento que importa se decide mientras el software se ejecuta, y ahí esa asunción se rompe.

De "¿está roto?" a "¿es correcto?"

El mismo agente, con el mismo código, puede acertar una petición y fallar la siguiente. Depende de cómo se formuló la pregunta, qué contexto se recuperó, por qué camino pasó entre sus herramientas y qué generó el modelo. La consecuencia práctica es que la corrección no se puede validar del todo antes de desplegar: parte de la respuesta tiene que venir de producción, de forma continua y run a run.

CloudWatch Omni intenta cubrir eso con 17 evaluadores integrados que puntúan el comportamiento del agente. La idea es que esas puntuaciones convivan en la misma traza con la latencia y el consumo de tokens, de manera que un equipo pueda ver que un cambio de prompt no ralentizó nada pero empeoró de forma apreciable las respuestas de recuperación.

Amazon reconoce ahí un segundo problema, que no se resuelve con producto: la calidad hay que definirla antes de poder medirla. ¿Qué cuenta como una decisión de reembolso correcta? ¿Cuándo debe escalar el agente? Las personas trabajan con mucho juicio tácito, pero un evaluador necesita algo más concreto, y construir las evaluaciones obliga a convertir parte de ese juicio en una definición operativa.

El resto de la propuesta es de investigación de incidentes. Cuando un reembolso sale mal, puede ser que el modelo razonara mal o que un servicio de pagos tres saltos más abajo estuviera con una configuración vieja; el sistema busca reconstruir una única cadena de causa y efecto desde la pregunta del cliente hasta los servicios de debajo. También permite consultas que solo se hacen cuando algo raro ya ha pasado, del estilo de por qué la precisión de reembolsos cayó esta semana para los clientes europeos. Y los runs malos pueden convertirse en un conjunto de datos con el que probar el arreglo antes de desplegarlo.

La parte más discutible es la que relaciona autonomía y evidencia. Los permisos marcan el límite exterior, pero no dicen si una decisión concreta fue acertada, y Amazon sostiene que la autoridad que una organización concede a sus agentes acaba dependiendo de cuánto ve de lo que hacen. Incluso plantea que esa relación sea dinámica en el futuro: más margen cuando el agente acumula historial y menos cuando la calidad se degrada. La compañía admite que no están ahí, solo que empiezan a existir las piezas para construirlo.

Todo esto lo firma AWS sobre su propio producto, sin cifras de adopción y sin cifras independientes, así que el contenido es tan interesante como el envase. Queda por ver si los 17 evaluadores cubren lo que un equipo necesita medir de verdad o si cada uno acabará escribiendo los suyos.