L’évaluation des compétences d’Amazon Bedrock AgentCore révèle ce que les agents éloquents dissimulent

Amazon a présenté l’évaluation des compétences d’Amazon Bedrock AgentCore le 22 septembre, en ajoutant trois contrôles qui examinent le comportement des agents au-delà de leur réponse finale soignée. Cette annonce cible un angle mort persistant des tests. Un agent peut sembler correct après avoir choisi la mauvaise compétence, ignoré des étapes requises ou improvisé autour d’une procédure métier.

Les nouveaux évaluateurs séparent deux questions que les équipes regroupent souvent dans un score unique. L’agent a-t-il sélectionné une compétence adaptée, et l’a-t-il suivie après l’avoir chargée ? Strands Evals ajoute un troisième contrôle déterministe pour les équipes qui savent déjà quelle compétence nommée un test doit invoquer.

Cette distinction met sous pression les systèmes d’évaluation centrés uniquement sur la qualité des réponses. L’utilité, la pertinence et l’exactitude restent importantes, mais elles ne peuvent pas révéler chaque défaillance d’orientation ou d’exécution. Le véritable enjeu oppose désormais la notation de la réponse finale à des preuves au niveau de la trajectoire sur la manière dont un agent est parvenu à cette réponse.

L’évaluation des compétences d’Amazon Bedrock AgentCore décompose une défaillance en trois

AWS transforme l’utilisation des compétences en séquence mesurable, au lieu de considérer la réponse finale comme une preuve suffisante de réussite.

Une compétence est un package d’instructions réutilisable qui enseigne à un agent une procédure spécialisée. Elle comprend généralement un fichier SKILL.md décrivant son objectif, ses indications d’activation et les étapes obligatoires. Un environnement d’exécution présente les compétences disponibles, tandis que l’agent décide laquelle charger pour une demande donnée.

Cette structure permet aux développeurs de sortir des procédures détaillées d’un prompt système qui s’allonge. Une entreprise peut créer des compétences distinctes pour le rapprochement de factures, l’occultation de contrats, l’escalade d’incidents ou la revue de pull requests. L’agent charge les instructions pertinentes lorsqu’il en a besoin, plutôt que de transporter chaque procédure dans chaque interaction.

La portabilité fait partie de son attrait. Le format ouvert Agent Skills offre aux environnements d’agents compatibles une méthode commune pour empaqueter des instructions spécialisées. Une compétence peut donc servir d’artefact opérationnel, et non simplement de fragment de prompt lié à un seul appel de modèle.

Toutefois, les instructions modulaires introduisent une chaîne de décisions. L’agent doit reconnaître l’intention de l’utilisateur, trouver une compétence adaptée, l’invoquer, en lire le contenu et accomplir les étapes prescrites. Un bon paragraphe final ne prouve pas que cette chaîne a fonctionné.

AWS et l’équipe Strands répartissent désormais cette chaîne entre trois évaluateurs, selon la publication du 22 septembre sur l’évaluation des compétences.

Skill Selection Accuracy demande si chaque compétence invoquée était adaptée à la tâche. Il renvoie un résultat binaire pour chaque compétence invoquée. Cela rend visibles les erreurs d’orientation lorsqu’un agent charge des instructions destinées à un autre flux de travail.

Skill Instruction Following examine dans quelle mesure l’agent a exécuté les étapes prescrites d’une compétence invoquée. Ses cinq évaluations sont Fully Followed, Mostly Followed, Partially Followed, Minimally Followed et Not Followed. Leurs valeurs numériques documentées vont de 1.0 à 0.0 par paliers de 0.25.

Skill Invoked fournit une assertion plus restreinte et déterministe dans Strands Evals. Il vérifie si l’agent a bien chargé une compétence nommée. Contrairement aux deux autres évaluateurs, il ne demande pas à un modèle de juger de l’adéquation ou du respect des instructions.

Ces mesures répondent à des questions différentes. Une compétence obligatoire liée à la paie pourrait ne jamais être chargée, entraînant une défaillance d’orientation. Elle pourrait être chargée pour une demande de voyage sans rapport, entraînant une défaillance de sélection. Elle pourrait être chargée correctement mais omettre une étape d’approbation, entraînant une défaillance de suivi des instructions.

Cette séparation constitue le changement central. Les équipes n’ont plus à interpréter chaque résultat faible comme un vague problème de qualité d’agent. Elles peuvent associer chaque schéma à un composant différent et à une correction plus ciblée.

Une invocation manquante oriente vers les règles de découverte, les descriptions ou la logique d’orientation. Une invocation inappropriée suggère des périmètres de compétences qui se chevauchent. Une compétence correctement sélectionnée avec un faible niveau de respect des instructions attire l’attention sur ses étapes, sa structure, les outils disponibles ou le modèle sous-jacent.

Cette annonce ne remplace pas l’évaluation existante de la qualité. Elle ajoute une couche conçue pour les agents dont le comportement dépend de procédures chargées dynamiquement. L’exactitude des résultats reste essentielle, mais elle devient un élément d’un dossier de test plus vaste.

Les réponses éloquentes ne suffisent plus comme preuve

L’argument le plus fort en faveur de l’évaluation des trajectoires est simple : différentes défaillances internes peuvent produire une prose tout aussi convaincante.

Imaginons qu’un employé demande à un agent d’occulter un contrat avant son partage externe. L’agent peut retirer les noms les plus évidents et renvoyer un document à l’apparence propre. Pourtant, la compétence approuvée peut aussi exiger la vérification des métadonnées, des commentaires masqués, des modifications suivies et des références aux pièces jointes.

Un réviseur qui ne voit que le document final peut manquer ces contrôles ignorés. La réponse peut paraître compétente tout en enfreignant la procédure de traitement réelle de l’organisation. Skill Instruction Following est conçu pour comparer le comportement enregistré à chaque étape prescrite.

Le même problème apparaît dans les opérations financières. Un agent de rapprochement de factures peut produire le bon total après un raisonnement informel. Si la compétence exige de valider l’identité du fournisseur et l’autorisation d’achat, le résultat demeure incomplet sur le plan procédural.

La conformité rend cette distinction particulièrement importante. Les organisations se soucient rarement uniquement de savoir si une réponse isolée s’est avérée acceptable. Elles ont aussi besoin de preuves que des contrôles reproductibles ont été appliqués dans l’ordre et le contexte requis.

Les tests logiciels traditionnels offrent des attentes précises pour les fonctions déterministes. Les agents se comportent différemment, car le même prompt peut conduire à des formulations, des appels d’outils et des chemins de raisonnement variés. AWS avait auparavant soutenu qu’une seule exécution réussie montre ce qui peut arriver, et non ce qui arrive habituellement.

Cette variabilité rend séduisants les scores agrégés de réponse. Une équipe peut calculer la moyenne de l’exactitude ou de l’utilité sur un jeu de données et suivre l’évolution du chiffre. Pourtant, une moyenne masque l’endroit où un flux de travail a échoué et si la même étape continue de disparaître.

Les résultats par compétence offrent une unité de diagnostic plus utile. Lorsqu’un agent invoque plusieurs compétences au cours d’une session, les évaluateurs renvoient des résultats pour chaque invocation. Un faible résultat agrégé peut donc être attribué à la compétence précise qui l’a fait baisser.

Cette approche modifie aussi la manière dont les équipes rédigent les compétences. Un paragraphe vague peut être compréhensible pour un auteur humain, mais difficile à évaluer de façon cohérente. Des étapes numérotées et observables donnent au juge des preuves plus claires et facilitent l’identification des omissions.

Cela ne signifie pas que chaque pensée interne devient disponible. L’évaluation repose sur les trajectoires et les traces enregistrées, y compris les messages visibles, les actions de chargement de compétences et les appels d’outils. Le raisonnement privé du modèle n’est ni requis ni exposé.

Les preuves pertinentes sont opérationnelles. L’agent a-t-il chargé la compétence ? Quelle compétence a-t-il choisie ? Les actions enregistrées montrent-elles qu’il a accompli les vérifications prescrites ? Ces preuves sont plus exploitables que les spéculations sur un raisonnement caché.

Ce changement rappelle la différence entre la vérification d’un calcul terminé et l’audit des contrôles qui l’entourent. Les deux perspectives comptent, mais elles répondent à des questions distinctes. L’une mesure l’artefact, l’autre le processus qui l’a produit.

Pour les équipes qui développent des agents internes, le processus comporte souvent le risque organisationnel le plus élevé. Une réponse éloquente peut satisfaire un utilisateur une fois. Une étape d’approbation, de divulgation ou de validation ignorée peut compromettre le flux de travail chaque fois que les mêmes conditions se reproduisent.

Les nouveaux évaluateurs facilitent l’identification de ce déficit procédural. Ils exercent également une pression sur les autres plateformes d’agents pour qu’elles exposent des trajectoires compatibles. Sans événements de compétences observables, une équipe ne peut pas distinguer avec certitude une invocation manquante d’une extraction défaillante.

Strands Evals intègre les contrôles au développement

Strands Evals offre aux développeurs une couche de test locale pour l’orientation et l’exécution des compétences avant que le trafic de production ne devienne la suite de tests.

Strands Evals est un framework open source destiné à l’évaluation des agents et des applications de modèles de langage. Ses capacités publiées incluent la notation des sorties, l’analyse des trajectoires, l’évaluation des outils, les simulations, les expériences et l’évaluation fondée sur les traces.

Le référentiel d’évaluation du projet documente désormais les trois contrôles de compétences. Les développeurs peuvent exécuter Skill Selection Accuracy et Skill Instruction Following sur une session enregistrée ou une trajectoire brute de messages.

Les évaluateurs fondés sur un juge lisent la trajectoire au lieu de réexécuter l’agent. Cela permet d’enquêter après une défaillance et de comparer des sessions sauvegardées. Cela sépare également l’exécution coûteuse de l’agent de l’analyse répétée d’un même enregistrement.

Skill Invoked répond à un besoin de test différent. Si un cas de régression comporte une exigence d’orientation connue, les développeurs peuvent affirmer que la compétence attendue a été chargée. Le contrôle est déterministe et ne requiert pas de modèle juge.

Cela le rend adapté à une barrière de publication. Une demande au support client concernant la fermeture d’un compte devrait charger systématiquement la compétence de fermeture approuvée. Si une description révisée empêche l’invocation, le test de régression peut échouer avant le déploiement.

La précision de sélection reste utile lorsque plusieurs compétences peuvent raisonnablement s’appliquer. Elle demande si une compétence invoquée correspond à la tâche, au lieu de comparer uniquement avec un nom fixe. Cette souplesse convient aux catalogues comportant des procédures connexes et des variations d’orientation légitimes.

Le suivi des instructions teste ensuite l’étape suivante. L’évaluateur identifie les étapes prescrites dans la compétence chargée et qualifie chacune de couverte, partielle ou ignorée. Il utilise ces jugements pour produire l’évaluation globale à cinq niveaux.

Cette combinaison crée une matrice de test compacte.

Un score de sélection élevé associé à un faible suivi des instructions signifie que l’orientation a fonctionné, mais pas l’exécution. L’agent a trouvé la bonne procédure, puis a ignoré ou seulement partiellement exécuté ses exigences.

Une faible sélection associée à un suivi rigoureux des instructions signifie que l’agent a suivi la procédure chargée, mais que cette procédure ne correspondait pas à la demande. Améliorer la formulation interne de la compétence ne résoudrait pas cette erreur d’orientation.

Une invocation manquante exige un traitement particulier. AWS indique que les deux évaluateurs fondés sur un juge ne renvoient pas de score lorsqu’aucune compétence n’a été invoquée. Les équipes devraient les associer à Skill Invoked lorsqu’une compétence nommée est obligatoire.

Ce comportement évite un succès trompeur. Un évaluateur ne peut pas juger le respect d’instructions qui n’ont jamais été chargées. Toutefois, un résultat vide peut disparaître dans un tableau de bord, à moins que la suite de tests ne traite explicitement la non-invocation comme une défaillance.

Strands impose aussi une charge d’instrumentation à l’environnement d’exécution. Son extracteur doit reconnaître les compétences disponibles et sélectionnées à partir de la trajectoire. Le projet prend en charge plusieurs environnements connus, ainsi que le modèle générique de lecture d’un fichier SKILL.md.

Les développeurs devraient vérifier l’extraction avant de faire confiance à un score. Un environnement d’exécution dont les signaux de compétences ne sont pas reconnus peut produire des résultats vides même lorsque l’agent a utilisé une compétence. Il s’agit d’un déficit d’observabilité, et non d’une preuve de comportement correct.

Cette réserve compte pour les équipes qui intègrent des couches d’orchestration personnalisées. La qualité de l’évaluation dépend d’un enregistrement fidèle des événements. Un attribut de trace manquant peut ressembler à une action d’agent absente, à moins que les équipes ne valident d’abord le contrat de télémétrie.

Le workflow de développement comporte donc deux étapes. D’abord, confirmer que l’évaluateur peut voir le catalogue, l’invocation, le contenu de la compétence et les actions ultérieures. Ensuite, mesurer si ces actions correspondent à la tâche et respectent les instructions.

Pour les équipes d’ingénierie qui maintiennent des workflows techniques locaux, ce changement renforce également l’intérêt d’une base de connaissances d’ingénierie consultable. Les compétences peuvent encoder des procédures, tandis que des sources maintenues fournissent les faits sur lesquels ces procédures s’appuient.

AgentCore fait entrer l’évaluation des compétences dans les traces de production

AgentCore étend les mêmes questions de routage et de respect des instructions, des tests organisés aux sessions préparées et au trafic réel échantillonné.

Amazon Bedrock AgentCore Evaluations est un service géré destiné à évaluer le comportement des agents en développement comme en production. Il utilise des traces OpenTelemetry, qui enregistrent des événements structurés tels que les appels au modèle, l’utilisation d’outils et les opérations d’agent.

OpenTelemetry est important, car il réduit la dépendance à un unique framework d’agents. La documentation d’AgentCore indique que le service prend notamment en charge les intégrations Strands et LangGraph via l’instrumentation OpenTelemetry et OpenInference.

Cette architecture confère à la mise à jour un rôle plus large qu’une fonctionnalité réservée à Strands. Strands Evals traite les cas de test et les trajectoires de développement enregistrées. AgentCore peut évaluer des traces compatibles provenant d’agents déployés, y compris des sessions produites en dehors du framework Strands.

AWS propose trois modes d’évaluation. L’évaluation à la demande examine des sessions sélectionnées ou valide une modification récente. L’évaluation par lots traite plusieurs sessions stockées afin d’établir une référence ou de comparer une révision du catalogue.

L’évaluation en ligne échantillonne en continu le trafic de production. Les équipes choisissent des évaluateurs, une source de données, des filtres et un taux d’échantillonnage. AgentCore applique alors ces évaluations à mesure que les traces correspondantes arrivent.

Les modes d’évaluation répondent à différentes questions opérationnelles. Un développeur peut examiner une session ayant échoué, noter une population stockée ou surveiller un comportement qui n’apparaît qu’auprès d’utilisateurs réels.

Cette progression répond à une lacune fréquente dans les tests d’agents. Les prompts organisés reflètent ce que les concepteurs s’attendent à voir demander. Les requêtes de production contiennent des abréviations, un contexte manquant, des formulations inhabituelles et des combinaisons qu’un auteur de tests n’avait pas anticipées.

Les catalogues de compétences évoluent également au fil du temps. Une nouvelle compétence peut chevaucher une description existante et modifier le routage, même si les étapes internes d’aucune des deux compétences n’ont changé. AWS décrit ce phénomène comme une dérive du catalogue.

L’évaluation en ligne peut révéler cette dérive par une baisse des scores de sélection. Les équipes peuvent ensuite examiner quelle compétence a commencé à attirer des requêtes inadaptées. La correction peut consister à préciser une description ou à clarifier les limites entre des compétences voisines.

Les longues sessions soulèvent une autre préoccupation. Un agent peut suivre une compétence de manière fiable au début d’une conversation, puis perdre le fil des étapes à mesure que le contexte s’accumule. Les traces de production exposent ces situations plus naturellement que des prompts de test isolés.

Le service géré prend aussi en charge l’échantillonnage ciblé. La documentation AWS indique que les équipes peuvent évaluer un pourcentage de sessions ou appliquer des filtres conditionnels. Les opérateurs peuvent ainsi se concentrer sur les workflows sensibles sans traiter chaque interaction.

Cependant, l’échantillonnage modifie la signification du tableau de bord. Une évaluation à faible volume ou étroitement filtrée peut manquer des défaillances rares. Les équipes doivent enregistrer quel trafic a été retenu et éviter de présenter un score échantillonné comme une couverture complète.

Le parcours de production dépend également d’une télémétrie correcte. AgentCore organise les interactions en sessions, traces et spans. Une session contient une conversation, une trace couvre un échange et les spans représentent des opérations individuelles.

L’évaluation des compétences nécessite suffisamment d’informations pour reconstruire ce qui était disponible, ce qui a été chargé et ce qui s’est produit ensuite. Si l’instrumentation omet le contenu de la compétence ou le signal d’invocation, le juge ne dispose pas des éléments requis pour parvenir à un résultat défendable.

Les recommandations AgentCore d’AWS décrivent un format de trace unifié, noté au moyen d’évaluateurs fondés sur des modèles. Cette standardisation simplifie les opérations, mais elle ne peut pas récupérer des événements que l’application n’a jamais enregistrés.

Les équipes de sécurité devront également examiner le contenu des traces. Le texte des compétences peut contenir des procédures internes, et les enregistrements de conversations peuvent inclure des données utilisateur sensibles. L’évaluation accroît la valeur de la télémétrie tout en augmentant les enjeux liés aux contrôles d’accès et aux choix de conservation.

Le résultat est un modèle de cycle de vie plutôt qu’un test unique. Les développeurs peuvent établir localement des garde-fous déterministes, comparer des sessions stockées avant la publication et surveiller un comportement échantillonné après le déploiement. Chaque couche détecte une catégorie différente de défaillance.

Les nouveaux scores doivent eux aussi être évalués

Les juges fondés sur des modèles ajoutent des détails de diagnostic, mais ne transforment pas le respect des procédures en fait objectif.

Skill Selection Accuracy et Skill Instruction Following s’appuient sur un modèle juge. Le juge lit la tâche, les éléments disponibles et les instructions de la compétence avant de produire une note. Sa sortie reste une interprétation de la trajectoire enregistrée.

Cette interprétation peut varier lorsque les étapes sont ambiguës. Une compétence peut indiquer : « vérifiez le statut du client avant de poursuivre », sans définir quels éléments de vérification sont acceptables. Un juge peut considérer qu’une consultation de base de données suffit, tandis qu’un autre attend une confirmation explicite.

L’échelle de respect à cinq niveaux apporte de la nuance, mais elle peut aussi créer une fausse précision. Une note de 0,75 paraît exacte, même lorsque la distinction sous-jacente entre Mostly Followed et Partially Followed dépend d’un jugement.

Les équipes doivent donc calibrer l’évaluateur à partir d’exemples revus par des humains. L’objectif n’est pas un accord parfait sur chaque cas limite. Il s’agit d’un barème stable qui reflète les véritables priorités procédurales de l’organisation.

Les compétences doivent rendre les étapes importantes observables. « Prendre en compte la politique pertinente » est difficile à vérifier. « Récupérer la politique actuelle, comparer la requête à trois conditions d’éligibilité et enregistrer le résultat » produit des éléments plus clairs.

Les cas négatifs comptent autant que les cas positifs. Un benchmark de sélection doit inclure des requêtes qui ressemblent au domaine d’une compétence, mais ne devraient pas l’invoquer. Sinon, une description large peut obtenir un bon score en s’activant pour chaque tâche voisine.

Les tests au niveau du catalogue sont également essentiels. Évaluer une compétence isolément dit peu sur le routage lorsque dix choix similaires apparaissent ensemble. L’environnement de test pertinent doit ressembler au catalogue que les agents verront réellement.

La vérification déterministe Skill Invoked a sa propre limite. Elle prouve qu’une compétence nommée a été chargée, non que ce chargement était approprié ou utile. Une équipe peut atteindre une invocation parfaite tout en sélectionnant la compétence pour de mauvaises requêtes.

De même, un fort respect des instructions ne garantit pas une réponse correcte. Une compétence défectueuse peut prescrire les mauvaises étapes. L’agent peut les exécuter fidèlement et produire malgré tout un résultat dangereux ou inexact.

C’est pourquoi l’évaluation au niveau de la réponse doit rester complémentaire à l’évaluation des compétences. Les équipes ont toujours besoin de contrôles de justesse, de fidélité, de nocivité, de paramètres d’outils et de validations propres au domaine. Le respect des procédures n’est qu’une dimension de la fiabilité.

Les modèles de prompts officiels rendent la logique de notation inspectable. Ils montrent que le juge de respect identifie les étapes, étiquette les éléments probants et associe le résultat à cinq notes.

La transparence aide les équipes à comprendre l’évaluateur, mais elle ne remplace pas la validation. Les organisations doivent comparer les résultats du juge à l’examen d’experts avant d’utiliser les scores pour des décisions de publication sensibles.

Le coût et la latence façonnent également l’utilisation en production. L’évaluation fondée sur un juge exige un traitement supplémentaire par le modèle après l’exécution initiale de l’agent. L’échantillonnage et les filtres peuvent maîtriser cette charge, mais réduisent aussi la couverture.

Les équipes doivent éviter de fusionner tous les évaluateurs dans un score unique. Un seul nombre composite recrée l’ambiguïté que cette mise à jour cherche à éliminer. La sélection, l’invocation, le respect des instructions et la qualité de sortie doivent rester visibles comme des signaux distincts.

La mise à jour laisse également les questions de gouvernance hors de son périmètre. Elle ne décide pas qui peut rédiger une compétence, approuver une révision ou définir une procédure obligatoire. L’évaluation ne peut révéler un écart qu’après qu’une organisation a établi une référence faisant autorité.

Un workflow mature versionnera les compétences en même temps que les tests et les changements de barème. Sans cela, les équipes ne pourront pas déterminer si un score a évolué parce que l’agent a changé, les instructions ont changé ou l’évaluateur a changé.

Amazon présente ces contrôles comme des outils de diagnostic, et non comme une preuve indépendante de conformité. C’est la bonne limite. Ils rendent le comportement des agents plus vérifiable, tandis que la responsabilité reste entre les mains des personnes qui définissent et valident le workflow.

Trois signaux indiqueront si l’évaluation des compétences fonctionne

Le prochain test consistera à déterminer si les équipes peuvent transformer les preuves par compétence en publications plus sûres, diagnostics plus rapides et meilleurs catalogues de compétences.

Le premier signal sera l’adoption de garde-fous de routage déterministes au cours du développement. Les équipes doivent identifier les workflows pour lesquels une compétence nommée est obligatoire et ajouter des assertions Skill Invoked aux suites de régression.

Si ces garde-fous détectent les modifications du catalogue avant le déploiement, l’argument en faveur de tests tenant compte des compétences se renforcera. Si des problèmes d’extraction produisent fréquemment des résultats vides, l’instrumentation restera l’obstacle immédiat.

Le deuxième signal sera de savoir si les scores de sélection en production révèlent une dérive du catalogue. Les nouvelles compétences arrivent souvent avec des descriptions larges parce que leurs auteurs veulent qu’elles se déclenchent de manière fiable. Ces descriptions peuvent détourner des requêtes de procédures existantes.

Un système de production utile devrait indiquer quelles invocations sont devenues inappropriées après une mise à jour du catalogue. Les équipes devraient ensuite pouvoir relier cette baisse à une description précise, un chevauchement ou un schéma de requêtes.

Des preuves de diagnostic reproductible renforceraient l’affirmation centrale d’AWS. Des tableaux de bord qui n’affichent qu’un agrégat plus faible sans identifier la compétence concernée l’affaibliraient.

Le troisième signal sera l’accord entre Skill Instruction Following et l’examen d’experts. Les organisations doivent comparer les étiquettes étape par étape du juge avec les évaluations de personnes qui comprennent la procédure.

Un accord constant justifierait une utilisation plus large dans les garde-fous de publication et la surveillance en ligne. Des désaccords fréquents indiqueraient que les étapes des compétences, les éléments des traces ou le barème de l’évaluateur nécessitent un travail supplémentaire.

Les équipes devraient commencer avec un petit catalogue et un ensemble de tests volontairement varié. Incluez des correspondances claires, des quasi-correspondances, des requêtes ne nécessitant aucune compétence et des workflows à compétences multiples. Exécutez chaque scénario plus d’une fois, car le comportement des agents reste non déterministe.

Consignez séparément quatre résultats : si la compétence attendue a été chargée, si chaque invocation était appropriée, si les étapes requises ont été suivies et si le résultat final était correct. Cette structure préserve la valeur diagnostique des nouveaux évaluateurs.

Examinez ensuite les désaccords au lieu de les diluer dans une moyenne. Une réponse correcte avec des étapes ignorées peut révéler un risque opérationnel latent. Une mauvaise réponse après une exécution fidèle peut révéler une compétence défectueuse plutôt qu’un modèle faible.

La surveillance de production devrait commencer par les workflows sensibles ou à fort volume. Utilisez délibérément les filtres et l’échantillonnage, et documentez ce que la population évaluée exclut. Conservez une revue experte pour les défaillances graves et les notes contestées.

L’évaluation des compétences Amazon Bedrock AgentCore est importante parce qu’elle modifie ce qui compte comme preuve. Une sortie fluide reste précieuse, mais elle ne suffit plus à établir qu’un agent a suivi la procédure de l’organisation.

La question pratique vous appartient désormais : votre équipe peut-elle expliquer quelle compétence un agent a sélectionnée, pourquoi ce choix était pertinent et quelles étapes requises la trace prouve qu’il a réalisées ? Sinon, intégrez ces éléments de preuve au prochain cycle de test avant d’ajouter davantage de compétences.