Amazon Web Services a mis son service d'agent géré d'origine pour Amazon Bedrock en mode maintenance en vue d'une nouvelle adoption. Le service anciennement connu sous le nom d'Amazon Bedrock Agents est désormais documenté sous le nom Amazon Bedrock Agents Classic, et AWS indique qu'il n'est plus ouvert aux nouveaux clients à partir du 30 juillet 2026.
Cela ne signifie pas que les déploiements existants cessent de fonctionner. AWS indique que les clients actuels peuvent continuer à utiliser Bedrock Agents Classic et indique séparément que les modèles, les bases de connaissances et les garde-corps Amazon Bedrock ne sont pas affectés par le changement. Mais la direction pour les nouvelles charges de travail d'agent est claire : AWS recommande Amazon Bedrock AgentCore comme chemin comparable pour les applications d'agent nouvelles ou migrées.
Pour les équipes qui s'appuient sur Bedrock, il s'agit de plus qu'un simple changement de nom de service. Il déplace l'architecture par défaut des agents hébergés par AWS de l'ancienne interface Bedrock Agents vers un environnement d'exécution et une pile d'outils plus récents centrés sur AgentCore. Pour les plates-formes qui fournissent une passerelle API AI, une couche de routage LLM ou une infrastructure d'agent d'entreprise, la coupure crée une question de compatibilité et de migration qui se situe à côté de la sélection de modèle ordinaire.
Ce qui a changé le 30 juillet
La documentation AWS identifie désormais les agents Amazon Bedrock comme Amazon Bedrock Agents Classic. Les mêmes instructions relatives au mode de maintenance indiquent que Bedrock Agents Classic est fermé aux nouveaux clients à partir du 30 juillet 2026, tandis que les clients existants peuvent continuer à l'utiliser.
La signification pratique dépend du compte AWS du client et de son utilisation actuelle. Les systèmes de production existants construits sur Classic ne doivent pas supposer un arrêt immédiat sur la seule base de l'avis de maintenance public. Cependant, les nouvelles équipes, les nouveaux comptes et les organisations normalisant la future infrastructure d'agent devraient traiter Classic comme un chemin existant plutôt que comme le service d'agent Bedrock par défaut.
AWS oriente les clients nouveaux et migrant vers Bedrock AgentCore. La société décrit AgentCore comme prenant en charge l'orchestration gérée et un ensemble plus large de capacités d'agent de production, y compris l'exposition des outils via le Model Context Protocol, la mémoire, l'identité, l'observabilité et le traçage. Ces fonctionnalités suggèrent qu'AWS passe d'un générateur d'agents gérés plus restreint à un environnement d'exécution d'agent plus général pour les applications utilisant des outils de longue durée.
Une limite est également importante : le changement concerne la couche d'orchestration des agents gérés de Bedrock, et non l'ensemble de la plate-forme Bedrock. AWS indique que les modèles Bedrock, les bases de connaissances et les garde-corps ne sont pas affectés. Une équipe peut toujours utiliser les composants d'inférence ou de récupération de modèle Bedrock et de sécurité même si elle doit revoir le service d'orchestration d'agents qui l'entoure.
Pourquoi c'est important pour les créateurs d'agents
L'infrastructure d'agent est devenue plus difficile à traiter comme une fine enveloppe autour d'un appel de modèle. Un agent de production a souvent besoin d'autorisations d'outils, de règles de mémoire, de mappage d'identité, de journalisation, d'évaluation et d'attribution des coûts. Lorsque la couche d'orchestration gérée change, les développeurs peuvent avoir besoin de revoir la façon dont les invites, les schémas d'outils, la récupération, les garde-fous et la surveillance sont connectés ensemble.
Cela est particulièrement vrai pour les entreprises qui ont adopté Bedrock Agents Classic comme alternative gérée à la création de leur propre orchestration. Si ces entreprises créent désormais des environnements supplémentaires, intègrent de nouvelles unités commerciales ou reconstruisent de nouveaux comptes AWS, elles peuvent rencontrer une disponibilité et une architecture recommandée différentes de celles utilisées par leurs déploiements existants.
La coupure affecte également les fournisseurs et les équipes de plate-forme internes qui résument le substrat rocheux derrière une interface unifiée. Une plateforme multi-cloud ou multi-modèle ne peut pas traiter cela simplement comme une « voie vers un modèle AWS ». Il peut avoir besoin de savoir si un client invoque une inférence de modèle simple, un workflow de base de connaissances, une stratégie Guardrails, un agent classique ou une charge de travail hébergée par AgentCore. Il s'agit de surfaces opérationnelles différentes avec des risques de migration différents.
Pour les utilisateurs de Model Gate et les clients de passerelles similaires, la leçon est que le routage des API LLM n'est plus seulement une question de prix, de latence et de qualité du modèle. Le placement des agents est également important. Une passerelle peut aider à centraliser la gestion des clés API, les analyses d'utilisation, les contrôles d'équipe et la visibilité des dépenses, mais elle doit toujours respecter les capacités et l'état du cycle de vie des services du fournisseur sous-jacents.
Qui est concerné
Le groupe le plus directement concerné est celui des clients AWS qui planifient de nouvelles versions d'agents gérés sur Bedrock. S’ils n’ont jamais utilisé Bedrock Agents Classic, ils doivent s’attendre à ce qu’AgentCore soit le chemin recommandé. Les équipes qui exécutent déjà des agents Classic peuvent continuer à les utiliser, selon AWS, mais doivent planifier la maintenance du service lors de la prise de décisions sur la feuille de route à long terme.
Les architectes cloud sont concernés car les architectures de référence peuvent nécessiter une mise à jour.La documentation, les modules Terraform, les chemins d'or internes et les examens de sécurité qui supposent que Bedrock Agents Classic est la couche d'agent géré standard doivent être vérifiés par rapport aux API, au modèle d'identité, aux fonctionnalités d'observabilité et aux exigences opérationnelles d'AgentCore.
Les équipes de sécurité et de gouvernance sont également concernées. L'accent mis par AgentCore sur l'identité, l'exposition des outils, l'observabilité et le traçage reflète les problèmes que les entreprises tentent désormais de résoudre : quel utilisateur ou service agit, quels outils un agent peut appeler, quelles données il peut récupérer, comment une décision peut être auditée et comment les boucles d'outils incontrôlables ou les appels de modèles coûteux sont détectés.
Les fournisseurs de logiciels s'appuyant sur Bedrock peuvent avoir besoin d'une double période de support. Les clients existants peuvent toujours utiliser Classic, tandis que les nouveaux clients peuvent avoir besoin d'AgentCore. Cela peut signifier des tests supplémentaires, des indicateurs de fonctionnalités, une logique de déploiement spécifique au client et une documentation plus claire sur le chemin d'agent Bedrock pris en charge.
Conséquences pratiques et questions ouvertes
La première étape pratique est l'inventaire. Les équipes doivent identifier si elles utilisent Bedrock Agents Classic, des API de modèle Bedrock simples, des bases de connaissances, des garde-corps ou une orchestration personnalisée en dehors de Bedrock. La notification du mode maintenance affecte ces catégories différemment.
La deuxième étape consiste à cartographier les dépendances de migration plutôt que de supposer un lift-and-shift direct. Les charges de travail des agents peuvent dépendre des définitions d'outils, de la configuration de récupération, des modèles d'invite, des autorisations IAM, des journaux d'audit et de la gestion des erreurs spécifiques à l'application. Le passage à AgentCore peut être une opportunité d'améliorer l'observabilité et les contrôles d'identité, mais cela peut toujours nécessiter un travail d'intégration.
La troisième étape est l'examen des coûts et de la gouvernance. Les nouveaux environnements d'exécution des agents facilitent souvent la connexion de davantage d'outils et l'exécution de flux de travail plus autonomes. Cela augmente la valeur de l'analyse de l'utilisation, de l'attribution au niveau des demandes et des contrôles budgétaires. Dans un environnement de passerelle, les équipes doivent décider quels appels transitent par une couche de stratégie centrale et lesquels restent dans l'orchestration gérée par AWS.
Certains détails restent spécifiques au compte. Des commentaires indépendants suggèrent que l'éligibilité peut dépendre de l'utilisation antérieure du compte et que certains modèles post-cutoff nouvellement publiés pourraient ne pas être disponibles via Classic. Ces points doivent être vérifiés par rapport au compte AWS du client et à la documentation actuelle du mode maintenance d'AWS avant d'être traités comme une politique.
Le signal plus large est assez clair : AWS ne quitte pas les agents Bedrock, mais il éloigne le nouveau travail des agents de l'interface d'origine des agents Bedrock. Pour les développeurs et les équipes de plateforme, l'hypothèse sûre est que les futurs investissements dans les agents AWS se concentreront sur AgentCore, tandis que Bedrock Agents Classic deviendra un problème de compatibilité pour les déploiements existants.