AWS ha publicado una guía técnica para enviar telemetría desde agentes de IA que se ejecutan fuera de su nube a Amazon Bedrock AgentCore Observability. El enfoque cubre entornos locales, máquinas de desarrollo, Google Cloud Platform y Microsoft Azure, ofreciendo a los equipos una forma de usar los paneles de AWS sin mover las cargas de trabajo de los agentes a AWS.

La guía es importante porque AgentCore Observability no supervisa de forma nativa a los agentes implementados fuera del tiempo de ejecución de AWS AgentCore. La solución alternativa documentada por AWS combina AWS Distro for OpenTelemetry (ADOT), Amazon CloudWatch y credenciales de AWS Identity and Access Management (IAM) para recopilar trazas, métricas y registros desde entornos externos.

Extender AgentCore más allá de los tiempos de ejecución alojados en AWS

AWS presenta Amazon Bedrock AgentCore como una plataforma para construir, conectar y optimizar agentes creados con diferentes marcos y modelos. Su capacidad de observabilidad está diseñada para exponer detalles como la ejecución del agente, las llamadas a herramientas, la actividad del modelo y el uso de tokens.

Según el AWS Machine Learning Blog, la compatibilidad nativa se centra en agentes que se ejecutan en el tiempo de ejecución de AgentCore en AWS Cloud. Los agentes desplegados en Amazon Elastic Kubernetes Service, Amazon Elastic Container Service o AWS Lambda pueden usar patrones de integración nativos de AWS, mientras que las cargas de trabajo fuera de AWS requieren configuración adicional.

La configuración recién documentada no traslada esas cargas de trabajo. En su lugar, ADOT se ejecuta junto a la aplicación del agente e instrumenta los marcos compatibles y las llamadas al modelo. La telemetría resultante se exporta a un endpoint de Amazon CloudWatch OpenTelemetry Protocol, donde puede alimentar los paneles de AgentCore Observability.

Los ejemplos de AWS hacen referencia a agentes creados con Strands Agents, LangGraph y CrewAI. Eso hace que la guía sea relevante para equipos que estandarizan distintos marcos de agentes, en lugar de tratar la observabilidad como una función vinculada a una única pila de aplicaciones.

Cómo funciona la canalización de telemetría multicloud

La configuración tiene tres partes principales. Primero, ADOT proporciona instrumentación automática para la aplicación. AWS afirma que la distribución de OpenTelemetry puede parchear boto3 para las llamadas a Amazon Bedrock e instrumentar el marco Strands para que se emitan spans relacionados con el razonamiento y datos semánticos de IA generativa.

Segundo, el entorno externo necesita credenciales IAM con permiso para enviar telemetría a los servicios de AWS. Los permisos enumerados en la guía incluyen acceso para métricas de CloudWatch, creación e ingestión de registros y operaciones de trazas de AWS X-Ray. La configuración también requiere conectividad HTTPS saliente hacia endpoints de AWS.

Tercero, las variables de entorno definen la configuración de enrutamiento y autenticación de OpenTelemetry. La telemetría se autentica con AWS Signature Version 4, o SigV4, antes de enviarse al endpoint de CloudWatch. CloudWatch proporciona entonces la capa de ingesta y almacenamiento, mientras que AgentCore Observability ofrece paneles adaptados a la actividad de los agentes.

AWS también identifica CloudWatch Transaction Search como un requisito previo que debe habilitarse una vez por cuenta. La guía utiliza acceso al modelo de Amazon Bedrock y Claude Haiku en su ejemplo, aunque el procedimiento central consiste en exportar telemetría desde agentes externos y no en introducir un nuevo modelo.

Evidencia, afirmaciones y límites pendientes

La principal evidencia de este desarrollo es la propia publicación técnica del blog y las instrucciones de configuración de AWS. El elemento separado de AWS en el grupo de cobertura proporcionado no contiene texto adicional del artículo, testimonio de clientes ni validación independiente. Como resultado, las afirmaciones sobre el valor de los paneles, el alcance de la compatibilidad con marcos y los beneficios operativos deben tratarse como orientación informada por el proveedor y no como resultados medidos de forma independiente.

AWS describe la telemetría como una visibilidad de las cadenas de razonamiento, las invocaciones de herramientas y las salidas del modelo. Dice que esa visibilidad puede ayudar a los equipos a identificar alucinaciones, respuestas dañinas o fuera de tema, seguir el consumo de tokens y auditar el comportamiento. Son casos de uso de observabilidad plausibles, pero la publicación no ofrece resultados de referencia que muestren precisión de detección, sobrecarga de latencia, ahorro de costes o el número de despliegues que usan la configuración.

También hay un límite importante en el anuncio. El enfoque crea una ruta de supervisión multiplataforma; no convierte a AgentCore Observability en un servicio totalmente local o neutral respecto a la nube. Los agentes externos siguen enviando su telemetría a los servicios de AWS, y los equipos deben gestionar los permisos IAM asociados, el acceso de red, la configuración de CloudWatch y las políticas de tratamiento de datos.

Esa distinción importará para las organizaciones cuyas normas de residencia de datos, arquitectura de seguridad o estrategia de adquisición limiten la transmisión de prompts, salidas o detalles de trazas a una nube de terceros. La guía ofrece una ruta técnica, no evidencia de que se haya abordado cada requisito empresarial.

Qué significa para los creadores de IA y los equipos empresariales

Para los desarrolladores, el principal beneficio es la coherencia operativa. Un equipo puede ejecutar un agente en una máquina local durante el desarrollo, en un centro de datos privado para producción o en otro proveedor de nube mientras envía los datos de ejecución a una única superficie de supervisión de AWS. Eso puede reducir la necesidad de crear paneles separados para cada ubicación de despliegue.

Los datos también podrían apoyar la depuración práctica. Las trazas pueden conectar una sesión de usuario con llamadas al modelo, invocaciones de herramientas y pasos posteriores, lo que facilita investigar fallos en flujos de trabajo más complejos que un simple intercambio de prompt y respuesta. El uso de tokens puede proporcionar una base para la supervisión de costes, especialmente cuando los agentes llaman repetidamente a modelos o herramientas.

Para los compradores empresariales, sin embargo, la centralización introduce compensaciones. Las claves de acceso IAM y la telemetría que contiene entradas o salidas del modelo deben protegerse, delimitarse y gobernarse. Los equipos deberán decidir qué campos es seguro exportar, cuánto tiempo deben conservarse los registros y si CloudWatch y AgentCore Observability encajan en sus límites de cumplimiento.

La configuración también crea cierto grado de dependencia de AWS incluso cuando el cómputo permanece en otro lugar. Los creadores que utilizan infraestructura de GCP, Azure o local pueden conservar la flexibilidad de despliegue, pero la capa de control de supervisión, el modelo de autenticación y la ruta de almacenamiento descritos por AWS siguen vinculados a los servicios de AWS. Eso puede resultar atractivo para organizaciones centradas en AWS y menos convincente para empresas que persiguen una pila de OpenTelemetry neutral respecto al proveedor.

Qué vigilar a continuación

La señal más inmediata será si AWS amplía la compatibilidad nativa de AgentCore Observability más allá del tiempo de ejecución de AgentCore o sigue dependiendo de la integración basada en ADOT para cargas de trabajo externas. La documentación sobre instrumentación adicional de marcos y proveedores de modelos mostrará hasta qué punto funciona el patrón más allá de los ejemplos de la publicación.

Los equipos que evalúen el enfoque también deberían vigilar información concreta sobre costes de telemetría, latencia de exportación, controles de muestreo, opciones de retención y redacción de datos. Los informes independientes de implementación ayudarían a establecer si la configuración es práctica a escala de producción, y no solo reproducible como un ejemplo guiado.

Por último, el mercado observará si otros proveedores de nube responden con una supervisión de agentes multiplataforma comparable. A medida que los agentes de IA se distribuyen por infraestructuras privadas y múltiples nubes, la observabilidad podría convertirse en un factor decisivo sobre dónde ejecutan los equipos sus cargas de trabajo.

Perspectiva de Creati.ai

AWS no está anunciando que los agentes externos ahora se ejecuten de forma nativa dentro de AgentCore Observability. Está documentando un puente que utiliza ADOT y CloudWatch para ampliar la visibilidad del servicio a cargas de trabajo desplegadas en otros lugares. Eso supone una mejora operativa significativa, pero su utilidad depende de si los equipos aceptan a AWS como la capa de control de la telemetría.

Para los creadores, la conclusión más sólida es arquitectónica: la supervisión de agentes debe seguir al flujo de trabajo a través de modelos, herramientas y entornos de despliegue. El enfoque de AWS reduce el esfuerzo de integración para las organizaciones ya invertidas en sus servicios, mientras que las credenciales y el enrutamiento de datos necesarios hacen que la seguridad, la portabilidad y el coste sean cuestiones centrales en cualquier despliegue en producción.