AWS détaille le parcours de migration d’AgentCore alors que les clients mettent des charges de travail agentiques en production

AWS explique comment les équipes peuvent faire passer des agents expérimentaux en production avec Amazon Bedrock AgentCore, à l’aide de deux articles du Machine Learning Blog montrant à la fois un parcours de migration par étapes et un flux de travail d’entreprise déjà en production.

Le premier guide migre un agent de support client LangGraph vers AgentCore Runtime, Gateway et Memory avant de reconstruire éventuellement sa boucle de planification avec Strands Agents. Le second décrit un pipeline automatisé de documentation d’architecture pour un courtier interdealer mondial qui analyse du code .NET, génère des schémas et publie une documentation consultable via Amazon Bedrock Knowledge Bases et AWS CodePipeline.

Pris ensemble, ces articles présentent AgentCore moins comme un framework d’agent unique que comme une couche opérationnelle autour d’agents construits avec différents frameworks et modèles. Le message vise les équipes disposant de prototypes fonctionnels mais qui doivent encore gérer l’isolation des sessions, l’état durable, l’authentification des outils, les correctifs d’infrastructure, l’observabilité et la montée en charge du déploiement.

La voie progressive d’AWS du prototype à l’agent hébergé

Le guide de migration commence avec un agent LangGraph existant qui classe les messages clients, escalade les clients mécontents et utilise des outils pour consulter les commandes, traiter les retours et rechercher les questions fréquentes. Ses appels au modèle passent déjà par Amazon Bedrock, mais AWS insiste sur le fait que cela ne résout pas les responsabilités de production environnantes.

Dans la première étape, le graphe de l’agent reste inchangé. AgentCore Runtime héberge le processus, Gateway gère certaines connexions aux outils, et Memory stocke l’état de la conversation au fil des tours, des processus et des jours. AWS indique que cette étape supprime plusieurs tâches opérationnelles sans changer la manière dont l’agent décide quoi faire.

Une deuxième étape remplace la boucle de routage écrite à la main par une planification pilotée par le modèle via Strands Agents. Les équipes peuvent s’arrêter après la première étape si elles souhaitent un hébergement managé, des outils et un état conservant leur orchestration existante. AWS décrit également une troisième étape d’agent d’exécution AgentCore, mais l’article documente cette étape plutôt que de l’implémenter dans l’exemple.

La distinction est importante pour les développeurs. Runtime ne remplace pas automatiquement la logique de raisonnement d’une application. Il fournit l’environnement dans lequel cette logique s’exécute. Choisir un modèle de planification plus autonome est une décision architecturale distincte, et AWS présente l’approche progressive comme un moyen d’isoler ces changements.

Le travail opérationnel ciblé par AgentCore

AWS associe les services AgentCore au travail qui a tendance à s’accumuler autour des agents de production. Runtime prend en charge le calcul managé, l’isolation des sessions et la mise à l’échelle sur l’infrastructure AWS. Les équipes peuvent connecter le runtime à un cloud privé virtuel, mais AWS précise que la conception réseau, la protection de la périphérie, l’autorisation, les politiques IAM, les règles de pare-feu applicatif Web et la rotation des secrets restent de la responsabilité du client.

Gateway gère l’accès aux outils et appelle des cibles comme AWS Lambda sous son propre rôle d’exécution. L’exemple du guide signe les appels avec des informations d’identification AWS IAM plutôt qu’avec des jetons tiers. AgentCore inclut également une capacité d’identité pour courtier les informations d’identification et renouveler les jetons d’accès OAuth lorsqu’un agent doit appeler une API au nom d’un utilisateur, bien que cette capacité ne soit pas utilisée dans le tutoriel.

Memory répond à la limite de conserver l’état de la conversation dans un dictionnaire local au processus. Cette approche peut échouer lorsqu’un processus redémarre ou lorsque plusieurs réplicas doivent accéder à la même conversation. AWS indique que son exemple déplace le stockage des points de contrôle vers AgentCore Memory afin que l’état puisse persister d’un tour à l’autre, d’un processus à l’autre et d’un jour à l’autre.

L’observabilité est un autre domaine mis en avant par AWS. Les journaux, métriques et traces de Runtime sont envoyés à Amazon CloudWatch sans que le client ait à configurer le pipeline sous-jacent. Toutefois, le guide ne suggère pas qu’AgentCore élimine toutes les opérations. La gestion des dépendances reste de la responsabilité du client avant la phase d’agent d’exécution ultérieure, et l’infrastructure gérée par AWS ne supprime pas le besoin de décisions de sécurité au niveau de l’application.

Un exemple de production au-delà du support client

Le deuxième article AWS applique AgentCore à un autre type de charge de travail : la documentation d’architecture. Selon AWS, un courtier interdealer mondial exécute le système en production depuis le premier trimestre 2026 pour maintenir la documentation de sa plateforme de trading électronique. Le client n’est pas nommé dans l’article, de sorte que l’affirmation d’adoption ne peut pas être évaluée de manière indépendante à partir des éléments fournis.

Le flux de travail commence lorsque des modifications de code arrivent dans un dépôt AWS CodeCommit. AWS CodeBuild récupère le code .NET, le package et invoque un agent Strands hébergé sur AgentCore. L’agent se concentre sur le code de production en excluant les tests, les artefacts de build et les fichiers générés, puis analyse les interfaces, les classes abstraites, les implémentations et les dépendances.

L’agent génère une syntaxe de diagrammes Mermaid, valide les diagrammes, les convertit en SVG et peut itérer en cas d’erreurs de validation. Les fichiers SVG résultants, le source Mermaid et les métadonnées sont stockés dans Amazon S3. Amazon Bedrock Knowledge Bases ingère ensuite ces artefacts, en utilisant Amazon Titan Text Embeddings v2 pour prendre en charge la recherche sémantique et la génération augmentée par récupération.

Les développeurs et les parties prenantes peuvent interroger la documentation résultante en langage naturel, y compris des questions sur les flux de service ou des classes spécifiques. AWS présente le raffinement itératif et l’auto-correction comme un avantage de fiabilité par rapport à une génération en une seule passe, mais il s’agit toujours d’une description de la solution par AWS plutôt que d’un benchmark rapporté indépendamment.

Preuves, affirmations et contraintes

Les deux sources sont des articles techniques rédigés par AWS, de sorte que les capacités produit, les diagrammes d’architecture et les étapes d’implémentation sont contrôlés par l’éditeur. Ils sont utiles pour comprendre comment AWS prévoit le déploiement d’AgentCore, mais ils n’établissent pas de comparaisons de performances indépendantes avec d’autres plateformes d’agents.

L’article de migration fournit un niveau de détail de mise en œuvre inhabituellement concret. AWS indique que, dans son exemple figé, 45 lignes ont été modifiées dans l’agent, 22 lignes de code de support ont été ajoutées et 85 lignes sont restées inchangées. Ces chiffres décrivent cet exemple particulier ; ils ne doivent pas être considérés comme une estimation générale de migration pour des systèmes de production présentant d’autres modèles d’état, outils, contrôles de sécurité ou architectures réseau.

L’article sur la documentation d’architecture fournit une affirmation d’usage en production mais aucun nom de client, volume de charge, mesure de précision, données de coût ou taux d’échec. Il ne quantifie pas non plus la quantité de travail manuel de documentation supprimée. Les acheteurs évaluant cette approche auront besoin de preuves issues de leurs propres dépôts et pipelines de déploiement avant d’en attendre des résultats similaires.

Les prérequis techniques sont également importants. Le tutoriel exige un compte AWS avec accès aux modèles Amazon Bedrock, Python 3.12, des identifiants AWS CLI capables de créer des ressources AgentCore, Lambda, Amazon S3 et IAM, ainsi que CloudWatch Transaction Search activé pour afficher les traces. Ces exigences placent clairement la migration dans les limites AWS en matière de sécurité, d’autorisations et de disponibilité régionale des modèles.

Ce que signifie AgentCore pour les développeurs et les entreprises

Pour les équipes d’ingénierie, la proposition de valeur la plus claire est la séparation des responsabilités. Une équipe peut conserver un workflow LangGraph existant tout en transférant l’hébergement, la médiation des outils et l’état durable vers des services managés. Cela réduit l’ampleur d’une migration d’infrastructure et permet à l’équipe de comparer le comportement à une base de référence enregistrée.

Pour les équipes qui réécrivent de toute façon un agent, l’étape de planification basée sur Strands offre un autre compromis. La planification pilotée par le modèle peut réduire la logique de routage écrite à la main, mais elle peut aussi introduire une variabilité supplémentaire dans la sélection et l’exécution des outils. Le guide AWS souligne un point important : passer à Runtime n’oblige pas à accepter ce compromis.

Les acheteurs d’entreprise devraient se concentrer sur les limites qu’AgentCore laisse en place. IAM, la configuration VPC, les règles WAF, les secrets et les politiques d’autorisation doivent toujours être conçus et gouvernés. Amazon Bedrock Guardrails peut filtrer les contenus nuisibles, vérifier l’alignement avec les documents sources et bloquer les tentatives d’injection de prompt, selon AWS, mais ces contrôles ne remplacent pas les tests d’application ni les règles d’approbation spécifiques aux workflows.

L’exemple de documentation d’architecture montre aussi où AgentCore peut s’insérer opérationnellement : non seulement dans le support conversationnel, mais dans des pipelines déclenchés par des événements qui inspectent du code, appellent des outils, génèrent des artefacts, valident les résultats et les publient pour la recherche. Cela élargit le groupe d’acheteurs concernés aux équipes de plate-forme, de productivité développeur, de conformité et d’architecture.

Ce qu’il faudra surveiller ensuite

Les prochains signaux seront des mesures indépendantes du coût d’exploitation, de la latence, du comportement de mise à l’échelle et de la gestion des défaillances d’AgentCore sur des charges de travail plus importantes. L’exemple AWS établit un modèle de migration, pas un benchmark de production universel.

Les équipes devront également surveiller la manière dont AgentCore s’intègre avec des fournisseurs de modèles non AWS, des systèmes d’identité externes et des piles d’observabilité existantes. Le guide indique que la plate-forme prend en charge n’importe quel framework ou modèle, mais le parcours démontré repose fortement sur les services AWS, IAM, Lambda, CloudWatch, S3 et Bedrock.

Enfin, les preuves d’adoption seront importantes. Le déploiement du courtier non nommé est un point de référence utile, mais davantage d’études de cas clients identifiables, de métriques de charge de travail et d’évaluations de sécurité faciliteraient l’appréciation de savoir si AgentCore réduit la charge opérationnelle ou la déplace simplement au sein de la plate-forme AWS.

Point de vue de Creati.ai

AWS avance un argument d’infrastructure crédible : industrialiser un agent implique bien plus que choisir un modèle ou écrire une boucle d’outils. La migration par étapes est particulièrement pratique parce qu’elle sépare les changements d’hébergement et de gestion d’état de la décision plus lourde de laisser un modèle piloter la planification.

Les preuves proviennent encore presque exclusivement d’AWS. L’importance d’AgentCore dépendra de la capacité des équipes à démontrer un effort opérationnel plus faible sans perdre le contrôle de l’identité, du réseau, de la fiabilité et des coûts. Pour l’instant, les articles montrent un schéma de déploiement AWS clair et une référence de production précoce, pas un avantage concurrentiel décisif.