AWS a publié un guide technique expliquant comment envoyer la télémétrie d’agents IA exécutés en dehors de son cloud vers Amazon Bedrock AgentCore Observability. L’approche couvre les environnements sur site, les machines de développement, Google Cloud Platform et Microsoft Azure, offrant aux équipes un moyen d’utiliser les tableaux de bord AWS sans déplacer les charges de travail des agents elles-mêmes vers AWS.

Cette consigne est importante car AgentCore Observability ne surveille pas nativement les agents déployés en dehors du runtime AWS AgentCore. Le contournement documenté par AWS associe AWS Distro for OpenTelemetry (ADOT), Amazon CloudWatch et les identifiants AWS Identity and Access Management (IAM) pour collecter les traces, métriques et journaux depuis des environnements externes.

Étendre AgentCore au-delà des runtimes hébergés par AWS

Amazon Bedrock AgentCore est présenté par AWS comme une plateforme permettant de construire, connecter et optimiser des agents conçus avec différents frameworks et modèles. Sa capacité d’observabilité est conçue pour exposer des détails tels que l’exécution de l’agent, les appels d’outils, l’activité du modèle et l’utilisation des jetons.

Selon le AWS Machine Learning Blog, la prise en charge native se concentre sur les agents exécutés sur le runtime AgentCore dans AWS Cloud. Les agents déployés sur Amazon Elastic Kubernetes Service, Amazon Elastic Container Service ou AWS Lambda peuvent utiliser des modèles d’intégration natifs AWS, tandis que les charges de travail en dehors d’AWS nécessitent une configuration supplémentaire.

La configuration nouvellement documentée ne déplace pas ces charges de travail. À la place, ADOT s’exécute aux côtés de l’application agent et instrumente les frameworks pris en charge ainsi que les appels de modèle. La télémétrie résultante est exportée vers un point de terminaison Amazon CloudWatch OpenTelemetry Protocol, où elle peut alimenter les tableaux de bord AgentCore Observability.

Les exemples AWS font référence à des agents construits avec Strands Agents, LangGraph et CrewAI. Cela rend le guide pertinent pour les équipes qui standardisent sur différents frameworks d’agents plutôt que de considérer l’observabilité comme une fonctionnalité liée à une seule pile applicative.

Comment fonctionne le pipeline de télémétrie multicloud

La configuration comporte trois éléments principaux. D’abord, ADOT fournit l’auto-instrumentation de l’application. AWS indique que la distribution OpenTelemetry peut patcher boto3 pour les appels Amazon Bedrock et instrumenter le framework Strands afin que les spans liés au raisonnement et les données de convention sémantique pour l’IA générative soient émis.

Ensuite, l’environnement externe a besoin d’identifiants IAM autorisés à envoyer de la télémétrie vers les services AWS. Les autorisations listées dans le guide incluent l’accès aux métriques CloudWatch, la création et l’ingestion de journaux, ainsi que les opérations de trace AWS X-Ray. La configuration nécessite également une connectivité HTTPS sortante vers les points de terminaison AWS.

Troisièmement, les variables d’environnement définissent les paramètres de routage et d’authentification OpenTelemetry. La télémétrie est authentifiée avec AWS Signature Version 4, ou SigV4, avant d’être envoyée au point de terminaison CloudWatch. CloudWatch fournit ensuite la couche d’ingestion et de stockage, tandis qu’AgentCore Observability propose des tableaux de bord adaptés à l’activité des agents.

AWS identifie également CloudWatch Transaction Search comme prérequis à activer une fois par compte. Le guide utilise l’accès au modèle Amazon Bedrock et Claude Haiku dans son exemple, même si la procédure centrale consiste à exporter la télémétrie depuis des agents externes plutôt qu’à introduire un nouveau modèle.

Preuves, affirmations et limites restantes

La principale preuve de ce développement est l’article technique du blog AWS lui-même et ses instructions de configuration. L’élément AWS distinct dans le lot de couverture fourni ne contient aucun texte supplémentaire, aucun témoignage client ni aucune validation indépendante. Par conséquent, les affirmations concernant la valeur des tableaux de bord, l’étendue de la prise en charge des frameworks et les avantages opérationnels doivent être considérées comme des conseils fournis par l’éditeur et non comme des résultats mesurés indépendamment.

AWS décrit la télémétrie comme offrant une visibilité sur les chaînes de raisonnement, les appels d’outils et les sorties de modèle. Selon l’entreprise, cette visibilité peut aider les équipes à identifier les hallucinations, les réponses nuisibles ou hors sujet, à suivre la consommation de jetons et à auditer le comportement. Ce sont des cas d’usage plausibles de l’observabilité, mais l’article ne fournit pas de résultats de benchmark montrant la précision de détection, la surcharge de latence, les économies de coûts ou le nombre de déploiements utilisant cette configuration.

L’annonce comporte aussi une limite importante. L’approche crée un chemin de supervision multiplateforme ; elle ne fait pas d’AgentCore Observability un service entièrement local ou neutre vis-à-vis du cloud. Les agents externes envoient toujours leur télémétrie vers les services AWS, et les équipes doivent gérer les autorisations IAM associées, l’accès réseau, la configuration CloudWatch et les politiques de traitement des données.

Cette distinction compte pour les organisations dont les règles de résidence des données, l’architecture de sécurité ou la stratégie d’achat limitent la transmission d’invites, de sorties ou de détails de traces vers un cloud tiers. Le guide propose une voie technique, pas la preuve que chaque exigence d’entreprise a été satisfaite.

Ce que cela signifie pour les créateurs d’IA et les équipes d’entreprise

Pour les développeurs, le principal avantage est la cohérence opérationnelle. Une équipe peut exécuter un agent sur une machine locale pendant le développement, dans un centre de données privé pour la production, ou chez un autre fournisseur cloud, tout en envoyant les données d’exécution vers une seule interface de supervision AWS. Cela peut réduire le besoin de créer des tableaux de bord distincts pour chaque emplacement de déploiement.

Les données peuvent aussi aider au débogage pratique. Les traces peuvent relier une session utilisateur aux appels de modèle, aux appels d’outils et aux étapes en aval, ce qui facilite l’enquête sur les défaillances dans des flux de travail plus complexes qu’un simple échange invite-réponse. L’utilisation des jetons peut fournir une base de suivi des coûts, en particulier lorsque les agents appellent à plusieurs reprises des modèles ou des outils.

Pour les acheteurs d’entreprise, cependant, la centralisation introduit des compromis. Les clés d’accès IAM et la télémétrie contenant des entrées ou sorties de modèle doivent être protégées, limitées et gouvernées. Les équipes devront décider quels champs peuvent être exportés en toute sécurité, combien de temps les enregistrements doivent être conservés et si CloudWatch et AgentCore Observability correspondent à leurs exigences de conformité.

La configuration crée aussi un certain degré de dépendance à AWS même lorsque les calculs restent ailleurs. Les créateurs utilisant une infrastructure GCP, Azure ou sur site peuvent conserver leur flexibilité de déploiement, mais la console de supervision, le modèle d’authentification et le chemin de stockage décrits par AWS restent liés aux services AWS. Cela peut être attrayant pour les organisations centrées sur AWS et moins convaincant pour les entreprises qui poursuivent une pile OpenTelemetry neutre vis-à-vis du fournisseur.

Ce qu’il faut surveiller ensuite

Le signal le plus immédiat sera de savoir si AWS étend la prise en charge native d’AgentCore Observability au-delà du runtime AgentCore ou continue de s’appuyer sur une intégration basée sur ADOT pour les charges de travail externes. La documentation sur l’instrumentation supplémentaire des frameworks et les fournisseurs de modèles montrera à quel point le modèle fonctionne au-delà des exemples de l’article.

Les équipes qui évaluent l’approche devraient également surveiller des informations concrètes sur les coûts de télémétrie, la latence d’exportation, les contrôles d’échantillonnage, les options de rétention et la rédaction des données. Des rapports d’implémentation indépendants aideraient à déterminer si la configuration est pratique à l’échelle de la production, plutôt que seulement reproductible sous forme d’exemple guidé.

Enfin, le marché observera si d’autres fournisseurs de cloud réagissent avec une supervision d’agents comparable sur plusieurs environnements. À mesure que les agents IA se répartissent entre infrastructures privées et plusieurs clouds, l’observabilité pourrait devenir un facteur décisif dans le choix de l’endroit où les équipes exécutent leurs charges de travail.

Perspective Creati.ai

AWS n’annonce pas que les agents externes s’exécutent désormais nativement dans AgentCore Observability. L’entreprise documente plutôt un pont utilisant ADOT et CloudWatch pour étendre la visibilité du service à des charges de travail déployées ailleurs. C’est une amélioration opérationnelle significative, mais son utilité dépend de l’acceptation d’AWS comme plan de contrôle de la télémétrie.

Pour les créateurs, l’enseignement le plus fort est architectural : la supervision des agents doit suivre le flux de travail à travers les modèles, les outils et les environnements de déploiement. L’approche AWS réduit l’effort d’intégration pour les organisations déjà investies dans ses services, tandis que les identifiants et l’acheminement des données requis placent les questions de sécurité, de portabilité et de coût au centre de tout déploiement en production.