Optimiser les agents en production avec Amazon Bedrock AgentCore Observability

Amazon publie la deuxième partie de sa série consacrée à l'observabilité des agents IA construits sur Amazon Bedrock AgentCore, en s'appuyant sur la fonctionnalité AgentCore Observability et sur Amazon CloudWatch. Après un premier volet dédié au débogage des agents défaillants (boucles infinies, erreurs d'invocation d'outils), ce second article s'attaque à un problème différent : les agents qui fonctionnent correctement mais trop lentement, ou dont la consommation mémoire dérive au fil du temps. Les prérequis restent identiques à la partie 1 : un compte AWS avec accès à Bedrock AgentCore, la fonction CloudWatch Transaction Search activée, et un agent déjà déployé. Un exemple concret illustre le problème : trois invocations successives d'un même agent affichent une latence moyenne de 7,5 à 8,2 secondes par span, révélant un goulot d'étranglement systémique plutôt qu'un simple ralentissement ponctuel. Amazon fournit une requête CloudWatch type pour repérer ces cas, filtrant les opérations InvokeAgent dont la latence dépasse 3 000 millisecondes, triées par ordre décroissant et limitées à 50 résultats.

Ce type de dégradation est particulièrement insidieux car il ne déclenche aucune alerte d'erreur : le taux d'échec reste bas, mais les temps de réponse P95 grimpent progressivement, de 2 secondes à 5, puis 10, jusqu'à devenir inutilisables pour un cas d'usage interactif comme un chatbot de service client. Les utilisateurs finissent par abandonner leurs sessions sans que le système ne signale de panne. Pour les entreprises qui déploient des agents en production, cela signifie qu'un monitoring classique basé sur les taux d'erreur ne suffit plus : il faut définir des budgets de performance spécifiques à chaque cas d'usage et surveiller activement la dérive de latence avant qu'elle n'affecte l'expérience utilisateur.

Amazon détaille ensuite une méthode d'analyse en profondeur : une fois une requête lente identifiée par son RequestId, une seconde requête CloudWatch permet de décomposer la chronologie complète de l'exécution, opération par opération. L'exemple fourni montre une trace OpenTelemetry de 17 spans répartis sur trois cycles d'exécution successifs (executeeventloopcycle), où des outils comme customerlookup et order_history s'exécutent l'un après l'autre au lieu d'être parallélisés, chaque cycle attendant la fin du précédent. Ce schéma séquentiel démultiplie la latence à chaque nouvel appel d'outil. Les causes les plus fréquentes identifiées par Amazon incluent la récupération de mémoire, l'invocation d'outils, la génération de tokens, et l'absence de parallélisation des opérations indépendantes, un diagnostic également accessible via des requêtes CloudWatch ciblées sur la latence spécifique de récupération mémoire.