Accueil › Glossaire › Bedrock Agents

Amazon Bedrock Agents

Amazon Bedrock Agents est un service managé d’AWS qui permet de créer et déployer des agents IA autonomes dans vos applications. Les agents orchestrent les interactions entre les foundation models (FM), vos sources de données, vos APIs métier et les conversations utilisateur, sans que vous ayez à provisionner d’infrastructure ni à écrire de code d’orchestration.

Qu’est-ce qu’Amazon Bedrock Agents ?

Amazon Bedrock Agents fait partie de la plateforme Amazon Bedrock, le service managé d’AWS qui donne accès à des centaines de foundation models (FM) via une API unifiée. Là où Bedrock de base se contente d’appeler un modèle et de retourner une réponse, Bedrock Agents ajoute une couche d’orchestration autonome : l’agent peut décomposer une requête utilisateur en étapes, appeler des APIs externes, interroger des bases de connaissances, exécuter du code, et boucler jusqu’à ce que la tâche soit terminée.

L’approche est configuration-first, pas code-first. Vous créez un agent en quelques étapes dans la console AWS ou via l’API : vous choisissez un modèle, rédigez des instructions en langage naturel, définissez des action groups (les actions que l’agent peut effectuer) et associez des knowledge bases (les données sur lesquelles l’agent peut s’appuyer). AWS gère le prompt engineering, la mémoire, le monitoring, le chiffrement et les permissions IAM.

C’est un positionnement très différent de l’OpenAI Agents SDK ou du Claude Agent SDK qui sont des bibliothèques de code. Bedrock Agents cible les équipes enterprise qui veulent déployer des agents IA sans devenir expertes en orchestration LLM.

Architecture et boucle d’orchestration

Un agent Bedrock fonctionne selon une boucle d’orchestration en quatre phases :

1. Pré-traitement (Pre-processing). L’agent reçoit l’input utilisateur et l’analyse via le FM pour catégoriser la requête, valider qu’elle est dans le périmètre, et déterminer si elle nécessite des actions ou peut être traitée directement.

2. Orchestration. C’est le coeur du processus. L’agent interprète la requête, raisonne sur les étapes à suivre, et prédit quelle action group invoquer ou quelle knowledge base interroger. Si l’agent manque d’informations, il peut demander des précisions à l’utilisateur ou combiner plusieurs sources. Cette phase boucle : chaque résultat d’action (appelé « observation ») est réinjecté dans le prompt, et le FM décide s’il faut continuer ou terminer.

3. Génération de réponse Knowledge Base. Si l’agent interroge une knowledge base, les résultats de la recherche vectorielle (RAG) sont synthétisés et intégrés dans le contexte de l’agent.

4. Post-traitement (Post-processing). L’agent formate la réponse finale avant de la retourner à l’utilisateur.

À chaque phase, Bedrock expose un prompt template par défaut que vous pouvez personnaliser. C’est un levier puissant : vous pouvez injecter des exemples few-shot, modifier le format de raisonnement, ou ajouter des règles métier directement dans les templates d’orchestration.

Action Groups

Les action groups définissent les actions concrètes que votre agent peut effectuer. Chaque action group contient les paramètres que l’agent doit collecter auprès de l’utilisateur, la définition des APIs à appeler, et la logique de traitement.

Deux méthodes pour définir un action group :

Schéma OpenAPI : vous fournissez une spécification OpenAPI qui décrit les opérations API disponibles, leurs paramètres et leurs réponses. L’agent s’en sert pour comprendre quand et comment appeler chaque endpoint. C’est l’approche la plus structurée, idéale quand vous avez des APIs REST existantes.

Function detail schema : vous définissez des fonctions avec leurs paramètres directement dans la console. Plus simple et flexible que l’OpenAPI, cette approche convient quand vous voulez que l’agent collecte des informations sans nécessairement appeler une API REST formelle.

Dans les deux cas, le traitement effectif passe par une fonction Lambda que vous configurez. L’agent envoie les paramètres identifiés à Lambda, qui exécute la logique métier (appel API, requête base de données, calcul) et retourne le résultat. Alternativement, vous pouvez choisir le mode « return control » où l’agent retourne les paramètres à votre application cliente pour que celle-ci gère l’exécution.

Knowledge Bases

Les Knowledge Bases d’Amazon Bedrock permettent d’ancrer les réponses de l’agent dans vos données privées. Le mécanisme est du RAG (Retrieval-Augmented Generation) : vos documents sont découpés en chunks, transformés en embeddings vectoriels, stockés dans une base vectorielle, et interrogés à chaque fois que l’agent a besoin de contexte supplémentaire.

Plusieurs backends de stockage vectoriel sont supportés : Amazon OpenSearch Serverless, Amazon Aurora (PostgreSQL avec pgvector), Pinecone, Redis Enterprise, et MongoDB Atlas. Le choix impacte directement les coûts : OpenSearch Serverless démarre à environ $0.48/OCU-hour, tandis que pgvector sur Aurora Serverless v2 peut descendre à $0.06/ACU-hour pour les petites bases.

L’association d’une knowledge base à un agent se fait en quelques clics. L’agent décide automatiquement quand interroger la base en fonction du contexte de la conversation.

Bedrock Guardrails

Les Guardrails d’Amazon Bedrock ajoutent une couche de sécurité configurable au-dessus des protections natives du modèle. Ils sont compatibles avec tous les FM de Bedrock et s’intègrent nativement avec les Agents et les Knowledge Bases.

Les guardrails couvrent plusieurs dimensions : filtrage de contenu (violence, discours de haine, contenu sexuel), filtres de mots/phrases spécifiques, détection de données sensibles (PII), et un système innovant d’Automated Reasoning qui utilise la logique formelle pour vérifier la cohérence des réponses. AWS annonce que les Guardrails peuvent bloquer jusqu’à 88% du contenu nuisible et identifier les réponses correctes avec une précision allant jusqu’à 99% grâce aux vérifications de raisonnement automatisé.

En pratique, vous créez un guardrail dans la console Bedrock, configurez les niveaux de filtrage par catégorie, et l’associez à votre agent. Chaque évaluation de guardrail est facturée séparément (par unité de texte évaluée).

Multi-Agent Collaboration

Depuis sa disponibilité générale en mars 2025, la fonctionnalité multi-agent de Bedrock permet de créer des réseaux d’agents spécialisés qui collaborent pour résoudre des tâches complexes. L’architecture repose sur un agent superviseur qui coordonne des subagents spécialisés.

Deux modes de collaboration sont disponibles :

Supervisor mode : le superviseur décompose la tâche, assigne les sous-tâches aux subagents appropriés, et synthétise les résultats. Il peut communiquer avec les subagents en parallèle pour une exécution plus efficace.

Supervisor with routing mode : le superviseur agit comme un routeur intelligent qui redirige directement vers le subagent le plus approprié, sans décomposition de tâche préalable. Plus rapide mais moins flexible pour les tâches complexes.

La composabilité est un point fort : vos agents existants peuvent être intégrés comme subagents dans un système plus large. Vous pouvez construire progressivement votre architecture multi-agent en ajoutant des spécialistes au fur et à mesure.

Bedrock AgentCore : les briques avancées

Amazon Bedrock AgentCore, annoncé lors de re:Invent 2024 et enrichi en décembre 2025, est la couche d’infrastructure pour les agents de production. Il complète Bedrock Agents avec des services spécialisés :

AgentCore Runtime : un environnement d’exécution avec isolation complète des sessions, connectivité VPC, support PrivateLink, et capacité de gérer des workloads de quelques secondes à 8 heures en mode asynchrone.

AgentCore Gateway : convertit vos APIs et fonctions Lambda en outils compatibles agent, connecte des serveurs MCP existants, et intègre une recherche sémantique pour la découverte d’outils.

AgentCore Memory : une mémoire persistante qui permet aux agents de maintenir un historique d’interactions, d’apprendre des préférences utilisateur, et de faire du checkpointing d’état entre les sessions. La fonctionnalité de mémoire épisodique, annoncée en décembre 2025, permet aux agents d’apprendre de leurs expériences passées.

AgentCore Policy : un système de politiques en langage naturel pour définir les limites d’action des agents. Par exemple, « Bloquer tous les remboursements quand le montant dépasse 1 000 € » peut être implémenté comme une règle que le Gateway vérifie en temps réel, en millisecondes.

AgentCore Evaluations : une suite de 13 systèmes d’évaluation pré-construits qui mesurent la justesse, la sécurité, la précision de sélection d’outils et d’autres facteurs. Essentiel pour valider le comportement d’un agent avant la mise en production.

Mémoire et sessions

Bedrock Agents intègre une fonctionnalité de rétention de mémoire qui permet à un agent de se souvenir des interactions passées. Cette mémoire améliore la personnalisation (l’agent se souvient des préférences de l’utilisateur) et la précision des tâches multi-étapes (l’agent reprend là où il s’est arrêté).

La mémoire fonctionne au niveau de la session : chaque session maintient un historique de conversation que l’agent peut consulter. Pour une mémoire à long terme (cross-session), AgentCore Memory offre un stockage persistant centralisé.

La combinaison mémoire de session + mémoire épisodique AgentCore + knowledge bases crée un système de gestion de contexte à trois niveaux : mémoire à court terme (conversation en cours), mémoire à moyen terme (interactions récentes avec l’utilisateur), et mémoire à long terme (données organisationnelles).

Modèles disponibles

L’un des avantages majeurs de Bedrock Agents est le choix de modèles. Contrairement au Claude Agent SDK (verrouillé sur Claude) ou à l’OpenAI Agents SDK (optimisé pour OpenAI), Bedrock est agnostique :

Vous pouvez changer de modèle sans modifier votre logique d’agent. Bedrock propose aussi l’Intelligent Prompt Routing qui route automatiquement les requêtes vers le modèle le plus adapté (coût/qualité), avec des économies annoncées jusqu’à 30%.

Comparaison avec les alternatives

Bedrock Agents est le choix naturel pour les organisations déjà sur AWS qui veulent déployer des agents sans gérer d’infrastructure. Son avantage principal est la simplicité : en quelques minutes dans la console, vous avez un agent fonctionnel avec RAG, guardrails et multi-agent. La contrepartie est un contrôle plus limité sur l’orchestration par rapport aux SDK code-first, et un coût potentiellement plus élevé à cause des multiples couches (tokens FM + Lambda + stockage + guardrails).

Pricing et optimisation des coûts

Bedrock Agents n’a pas de tarif séparé publié. Le coût réel est la somme de plusieurs composantes :

Tokens FM : chaque étape d’orchestration génère des tokens d’entrée et de sortie. Un agent qui effectue 5 appels d’outils consomme environ 5 fois plus de tokens qu’un appel direct au modèle, car chaque étape inclut le raisonnement d’orchestration. Pour une tâche simple coûtant $0.01 en tokens directs, comptez $0.05 à $0.08 via l’agent.

Lambda : les action groups facturent les exécutions Lambda ($0.20 par million de requêtes + coût de compute). Pour les agents à haut volume, c’est un poste non négligeable.

Stockage Knowledge Bases : le coût du backend vectoriel. OpenSearch Serverless est le plus courant mais aussi le plus cher (minimum ~$345/mois). pgvector sur Aurora Serverless v2 offre une réduction potentielle de 87% pour les petites bases.

Guardrails : facturés par unité de texte évaluée. Chaque message qui passe par un guardrail ajoute un coût marginal.

Créer un agent Bedrock pas à pas

Via la console AWS

Étape 1 : ouvrez la console Amazon Bedrock, naviguez vers « Agents » et cliquez « Create new agent ». Donnez un nom et une description à votre agent.

Étape 2 : choisissez un foundation model. Claude Sonnet 4.6 est un bon choix par défaut pour le rapport qualité/coût. Amazon Nova Pro pour les cas sensibles au coût.

Étape 3 : rédigez les instructions de l’agent en langage naturel. Par exemple : « Vous êtes un agent de support client pour une boutique en ligne. Vous pouvez consulter le statut des commandes, initier des remboursements jusqu’à 50 €, et répondre aux questions sur nos produits. »

Étape 4 : ajoutez des action groups. Définissez une action « check_order_status » avec les paramètres nécessaires (order_id), et associez une fonction Lambda qui interroge votre base de commandes.

Étape 5 : associez une knowledge base contenant votre FAQ produit et vos conditions générales de vente.

Étape 6 : associez un guardrail pour filtrer le contenu inapproprié et détecter les PII.

Étape 7 : testez dans la console avec l’alias de test (TSTALIASID). Examinez les traces pour comprendre le raisonnement de l’agent à chaque étape.

Étape 8 : quand l’agent est prêt, créez un alias pointant vers une version figée et déployez-le dans votre application via l’API InvokeAgent.

Via le SDK AWS

Pour une approche programmatique, le SDK AWS (Python boto3, JavaScript, etc.) expose toutes les opérations nécessaires : create_agent, create_agent_action_group, associate_agent_knowledge_base, prepare_agent, create_agent_alias. L’agent est invoqué via invoke_agent du runtime Bedrock Agent.

Tracing et observabilité

Bedrock Agents inclut un système de tracing natif qui expose le raisonnement étape par étape de l’agent. À chaque invocation, vous pouvez examiner la trace complète : la catégorisation de la requête, le choix de l’action group, les paramètres extraits, le résultat de l’appel Lambda, la décision de continuer ou de terminer.

Ce tracing est essentiel en production pour déboguer les comportements inattendus. Si un agent choisit la mauvaise action ou extrait des paramètres incorrects, la trace vous montre exactement où le raisonnement a dévié, ce qui permet d’ajuster les instructions ou les prompt templates en conséquence.

Pour un monitoring plus avancé, AgentCore Evaluations offre 13 métriques pré-construites couvrant la justesse, la sécurité et la sélection d’outils.

Cas d’usage en production

Support client automatisé : un agent avec des action groups pour consulter les commandes, initier des remboursements et escalader vers un humain. La knowledge base contient la FAQ et les politiques de l’entreprise. Bedrock Guardrails empêche l’agent de divulguer des informations sensibles.

Analyse financière : Robinhood utilise Bedrock pour traiter 5 milliards de tokens par jour, en passant de 500 millions à ce volume en six mois, tout en réduisant les coûts IA de 80%. L’agent analyse les portefeuilles, compile des rapports et répond aux questions des utilisateurs en se basant sur des données temps réel.

Agriculture de précision : Syngenta a construit Cropwise AI avec Bedrock Agents pour fournir des recommandations de semences personnalisées, des prévisions de rendement et des optimisations de ressources basées sur des données géolocalisées.

Marketing automation : Epsilon utilise AgentCore pour automatiser les workflows de campagne, réduisant le temps de configuration de 30% et économisant 8 heures par semaine par équipe.

FinOps cloud : des agents multi-agent avec un superviseur qui délègue l’analyse des coûts AWS, les recommandations d’optimisation et la prévision budgétaire à des subagents spécialisés.

Limites et points d’attention

Le coût peut devenir opaque. Chaque étape d’orchestration multiplie les tokens consommés, et les couches additionnelles (Lambda, Knowledge Bases, Guardrails) s’additionnent. Surveillez activement vos coûts via CloudWatch et AWS Cost Explorer.

Le contrôle sur l’orchestration est plus limité qu’avec un SDK code-first. Les prompt templates offrent une personnalisation significative, mais vous ne pouvez pas modifier la boucle d’orchestration elle-même. Pour des workflows très custom, AgentCore avec votre propre framework sera plus adapté.

Les quotas de service (nombre d’action groups par agent, nombre de knowledge bases associées, etc.) peuvent contraindre les architectures complexes. Consultez les limites dans la documentation AWS.

Enfin, le vendor lock-in AWS est réel. Même si les FM sous-jacents sont portables (Claude est aussi disponible directement chez Anthropic), la logique d’orchestration, les action groups Lambda et les knowledge bases sont des constructs AWS. Une migration vers un autre cloud ou un framework auto-hébergé nécessitera un effort significatif de réécriture.