Introducción
Un agente de IA procesa una solicitud de reembolso. Responde en 600 milisegundos. El error rate es cero. La latencia está dentro del SLO. Y le dice al cliente que le corresponden 40 dólares cuando la política vigente establece 140, porque recuperó una versión del documento del trimestre anterior. Todos los dashboards están verdes. Ninguna alerta se disparó. El sistema no está roto. Está equivocado.
Esa distinción —entre «broken» y «wrong»— es exactamente la grieta que Amazon CloudWatch Omni apunta a cerrar. AWS lanzó esta herramienta esta semana con un objetivo concreto: observar agentes, aplicaciones e infraestructura en una sola vista, y medir la corrección del trabajo que un agente produce en cada run, no solo si el proceso que lo ejecutó terminó sin excepción. Para equipos de SRE y plataforma que ya operan con OpenTelemetry, ADOT y tracing distribuido, esto cambia qué se instrumenta y para qué.
Qué ocurrió
CloudWatch Omni integra trazas de agentes, servicios de aplicación e infraestructura en un único plano de observabilidad. No reemplaza lo que ya existía en CloudWatch (métricas, logs, dashboards, alarms), sino que suma una capa de evaluación semántica sobre el comportamiento del agente durante la ejecución.
El disparador del lanzamiento es un problema operativo real: los agentes de IA introducen variabilidad que los tests pre-deploy no capturan. El mismo agente, ejecutando el mismo código, puede resolver correctamente un pedido de reembolso y fallar en el siguiente. El resultado depende de cómo se formuló la pregunta, qué contexto recuperó del vector store, qué herramienta seleccionó, y qué generó el modelo. Por eso la pregunta «¿está haciendo lo correcto?» ya no se responde completamente antes del release. Parte de la respuesta tiene que venir de producción, de forma continua, run por run.
AWS posiciona Omni como su primer paso grande en esta dirección. No es un reemplazo de la observabilidad clásica: los agentes corren sobre servicios, bases de datos, redes, colas e infraestructura que siguen necesitando ser entendidos cuando algo falla. Lo que se agrega es un conjunto nuevo de preguntas.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para un equipo de plataforma que hoy instrumenta microservicios con ADOT y correlaciona traces con logs y métricas, la llegada de agentes a producción introduce una capa de causalidad que los dashboards tradicionales no resuelven. Un trace clásico muestra que un request pasó por el API Gateway, el servicio de pagos, y la base de datos. Un trace de un agente muestra además qué prompt se usó, qué documentos se recuperaron del RAG, qué herramienta invocó el modelo, y si la selección fue correcta.
El impacto operativo es concreto: un equipo puede detectar que un cambio de prompt no degradó la latencia (el p95 sigue en 600 ms) pero sí empeoró la calidad de las respuestas de retrieval. Sin evaluadores de corrección embebidos en la traza, esa degradación es invisible hasta que llega un ticket de soporte o una auditoría.
En seguridad, la implicación es distinta. Los permisos (IAM policies, scopes de OAuth) definen qué un agente puede hacer. No definen si lo que hizo en un run particular fue correcto. Un agente con permiso para emitir reembolsos puede emitir uno de 40 dólares cuando corresponde 140. La política lo autoriza; la corrección no la evalúa ningún control de acceso. A medida que las organizaciones amplían la autonomía de los agentes —pasando de aprobación manual de cada acción a revisión por muestreo—, la evidencia de calidad en producción se vuelve el mecanismo de control.
Detalles técnicos
CloudWatch Omni se construye sobre OpenTelemetry como estándar de instrumentación. La instrumentación de agentes utiliza OpenInference, una convención de spans y atributos para trazar cadenas de razonamiento, selección de herramientas y retrieval. La distribución de ADOT (AWS Distro for OpenTelemetry) entrega los collectors y exporters necesarios.
Los 17 evaluadores embebidos cubren dimensiones como:
- Correctness: ¿la respuesta coincide con la fuente de verdad?
- Faithfulness: ¿el agente inventó información o se atuvo a lo recuperado?
- Tool selection: ¿invocó la herramienta adecuada para la tarea?
- Routing: ¿el request llegó al servicio o sub-agente correcto?
Estos scores se emiten como atributos en el mismo span que las métricas de latencia, token count y status code. Eso permite correlacionar, por ejemplo, que un incremento en tokens por request (más contexto recuperado) no mejoró la correctness del agente.
Omni soporta agentes construidos sobre LangGraph, CrewAI, Strands y otros frameworks. Produce datasets a partir de tráfico de producción: los traces donde el agente falló se convierten en ejemplos para experimentar con una nueva versión del prompt, del modelo o de la configuración de retrieval, antes de redeployar.
AWS DevOps Agent se integra con el mismo telemetry para asistir en investigaciones de incidentes, y los desarrolladores ven en su IDE las mismas trazas que los operadores ven en producción.
Qué deberían hacer los administradores y equipos técnicos
Primero, evaluar si los agentes en producción (o en pipeline de lanzamiento) tienen instrumentación OpenTelemetry con spans que capturen tool calls, retrieval queries y output del modelo. Si hoy solo instrumentan latencia de endpoint y error rate, la observabilidad es ciega a la corrección. La convención OpenInference define los atributos mínimos: gen_ai.tool.name, gen_ai.prompt, gen_ai.completion, retrieval.documents.
Segundo, definir explícitamente qué constituye una respuesta correcta para cada caso de uso del agente. «Un reembolso correcto» no es una definición operativa. Un equipo necesita un evaluator que compare el monto devuelto contra la política vigente, que valide que el documento recuperado es la versión actual, y que marque escalación cuando el monto excede un umbral. Sin esa definición formal, no hay score que medir.
Tercero, configurar pipelines de datos donde los traces con score de correctness bajo se capturen como dataset. Antes de aplicar un fix, se ejecuta la nueva versión contra ese dataset y se compara el score agregado. Después del deploy, se monitorea si el comportamiento en producción efectivamente mejoró.
Cuarto, revisar la política de autonomía. Si hoy un agente requiere aprobación humana para cada acción, la evidencia de Omni permite transicionar hacia muestreo (revisar el 5% de los runs) y luego a revisión post-facto con alertas por degradación de score. La autonomía crece en la medida en que la evidencia de calidad es continua y auditable.
Conclusión
La observabilidad clásica responde «¿el sistema está corriendo como se diseñó?». La observabilidad de agentes agrega «¿el trabajo que está haciendo es bueno?». Son preguntas distintas, con datos distintos, y la mayoría de los equipos hoy solo instrumenta la primera. CloudWatch Omni es una apuesta concreta de AWS para cerrar esa brecha con evaluadores embebidos en trazas OpenTelemetry, datasets de producción y un modelo de autonomía dinámica. Es temprano —el artículo de Matt Garman lo reconoce abiertamente— pero la dirección es clara: a medida que los agentes ganan autoridad sobre procesos con consecuencias reales, la evidencia de corrección en cada run deja de ser opcional. Los equipos de plataforma y SRE que integren esa capa de medición ahora van a poder escalar la autonomía de sus agentes con menos riesgo operativo.
Fuentes
- https://aws.amazon.com/blogs/aws-insights/wrong-not-broken/
- https://www.theregister.com/
- https://www.oreilly.com/radar/