Harnais Amazon Bedrock AgentCore : ce que c'est, comment il fonctionne et fonctionnalités clés

Créer un agent IA qui fonctionne dans une démonstration est relativement simple. En concevoir un capable d'exécuter des tâches de manière fiable, d'utiliser des outils, de gérer le contexte et d'opérer dans un environnement de production est beaucoup plus complexe. C'est là qu'intervient un harnais d'agent .

Un harnais d'agent s'interpose entre le modèle et les systèmes avec lesquels il doit interagir. Il gère la boucle de l'agent, l'exécution des outils, le contexte, la mémoire, le sandboxing et d'autres aspects liés à l'exécution nécessaires pour transformer un LLM en un agent opérationnel.

Amazon Bedrock AgentCore Harness est un service propriétaire géré par AWS qui fournit une boucle d'agent préconfigurée et s'exécute au sein d'AgentCore Runtime.

Dans ce guide, nous détaillerons le fonctionnement d'AgentCore Harness, ses différences avec AgentCore Runtime, et comment il se compare à TrueForge en termes de prise en charge des modèles, de gestion du contexte, de sandboxing, d'extensibilité, de déploiement et de contrôle sur la boucle de l'agent.

Qu'est-ce qu'AgentCore Harness ?

AgentCore Harness est un harnais d'agent géré au sein d'Amazon Bedrock AgentCore. Lancé en préversion publique en avril 2026, il est désormais disponible de manière générale. La boucle d'orchestration vous est fournie, propulsée par Strands Agents, ce qui vous permet de décrire l'agent plutôt que de le construire.

Concrètement, cela signifie que vous déclarez un modèle, une instruction système, un ensemble d'outils, des paramètres de mémoire et des limites d'exécution sous forme de configuration. AWS gère la boucle. La plupart des changements qui nécessiteraient normalement une modification du code et un redéploiement se résument désormais à un simple champ de configuration. Passer d'un fournisseur de modèle à un autre se fait via un champ. Ajouter un outil se fait via un champ.

Chaque session de harnais est par défaut avec état et s'exécute dans une microVM isolée. L'agent dispose de son propre système de fichiers et de son propre shell ; il peut donc écrire des fichiers, exécuter du code et conserver des souvenirs et des fichiers d'une session à l'autre au lieu de repartir de zéro à chaque fois.

Deux appels API suffisent pour démarrer. CreateHarness définit l'agent, InvokeHarness l'exécute. Il existe également une interface en ligne de commande (CLI) AgentCore et une console si vous préférez cliquer plutôt que d'utiliser curl.

Comment fonctionne AgentCore Harness ?

AgentCore Harness repose sur une approche de l'exécution des agents basée sur la configuration.

Au lieu d'écrire une boucle d'agent telle que :

response = model.generate(...)
if response.has_tool_call():
    result = execute_tool(response.tool_call)
    messages.append(result)
else:
    return response

vous définissez les composants dont l'agent a besoin et laissez le harness gérer la boucle.

De manière générale, un AgentCore Harness se compose de :

• Modèle - le modèle utilisé par l'agent pour le raisonnement et la génération
• Instructions - le comportement au niveau du système et les instructions destinées à l'agent
• Outils - les capacités que l'agent peut invoquer, y compris les serveurs MCP et les outils AgentCore
• Mémoire - l'état qui peut être conservé au fil des interactions
• Compétences - des capacités et instructions supplémentaires pouvant être mises à la disposition de l'agent
• Paramètres d'exécution - les contrôles régissant le fonctionnement de l'agent

Le harness coordonne ensuite ces composants lors de l'exécution.

Par exemple, si un agent doit effectuer des recherches sur un sujet, il peut raisonner sur la tâche, appeler un outil pour récupérer des informations, intégrer le résultat dans son contexte et poursuivre la boucle jusqu'à obtenir une réponse finale.

Grâce à cette abstraction, les développeurs n'ont pas à construire eux-mêmes chaque partie de la couche d'orchestration.

Cependant, cela signifie également que le modèle d'exécution est largement déterminé par le harness. Si vous devez modifier la boucle sous-jacente ou introduire une logique d'orchestration personnalisée, vous disposez de moins de flexibilité qu'avec un harness open-source où la boucle elle-même est accessible.

Vous ne voyez jamais la boucle. C'est tout l'intérêt du produit, et c'est aussi la source de la plupart de ses contraintes.

Qu'est-ce qui est inclus ?

Le harness géré couvre un large éventail de fonctionnalités sans nécessiter de code :

La sélection de modèles s'étend à Bedrock, OpenAI, Gemini et LiteLLM, et vous pouvez changer de fournisseur en cours de session. Le shell intégré et les file_operations outils sont fournis en standard, tout comme les compétences d'agent (Agent Skills). La mémoire est disponible sous forme à court et à long terme, cette dernière couvrant la mémoire sémantique, de résumé, de préférences utilisateur et épisodique, avec une portée par utilisateur définie par l'ID de l'acteur.

Les autres primitives d'AgentCore s'intègrent via la configuration plutôt que par des appels SDK : Gateway, navigateur, interpréteur de code et outils de serveur MCP distants. Les options de système de fichiers incluent le stockage de session géré par le service, un point d'accès EFS ou un point d'accès S3 Files.

Côté sécurité, l'authentification entrante prend en charge IAM SigV4 et OAuth, l'authentification sortante passe par le coffre-fort de jetons d'identité pour les jetons OAuth et les clés API, et les sessions sont isolées avec la mise en réseau VPC disponible. L'observabilité, les réponses en streaming, le versionnage et les points de terminaison fonctionnent tous sans code personnalisé.

Une exception à noter : les outils intégrés et côté client nécessitent toujours que vous écriviez et mainteniez une implémentation, même sur le harness.

Harness AgentCore vs Runtime AgentCore

C'est la comparaison qui envoie la plupart des utilisateurs vers la documentation, il est donc utile d'être précis. Les deux résolvent des parties différentes du même problème, et le harness aws agentcore est superposé à l'autre.

Le harness AgentCore est une abstraction gérée qui s'exécute au sein du Runtime. CloudTrail enregistre même les opérations du harness sous AWS::BedrockAgentCore::Runtime, ce qui indique où se situe réellement la limite.

Le Runtime AgentCore est un environnement d'hébergement serverless. Vous apportez le code de votre agent écrit dans n'importe quel framework ou sans framework, vous l'enveloppez avec le point d'entrée BedrockAgentCoreApp du SDK AgentCore, vous le packagez dans un conteneur ARM64, vous le poussez vers Amazon ECR et vous le déployez. Le Runtime gère l'isolation, la mise à l'échelle, les sessions, le contrôle d'accès et la plomberie de l'observabilité. La boucle d'orchestration vous appartient.

Le modèle est identique pour presque toutes les fonctionnalités. Sur le harness, il s'agit de configuration sans code. Sur le Runtime, c'est pris en charge, mais vous maintenez l'implémentation.

Ce que le harness AgentCore ne peut pas faire

AWS publie ces limitations dans sa propre grille de fonctionnalités. Quatre capacités sont marquées comme non prises en charge dans le harness :

Aucun choix de framework d'agent. La boucle est construite autour des agents Strands. Si votre équipe a déjà développé des solutions sur LangGraph, CrewAI ou un autre framework, ce code n'est pas compatible.

Aucun modèle autre que la boucle d'agent. Les applications basées sur des graphes ou des workflows ne sont pas prises en charge. Si une seule étape de votre pipeline nécessite un modèle et que le reste repose sur du code déterministe, le harness ne permet pas d'exprimer ce workflow.

Aucun hook. Vous ne pouvez pas injecter votre propre logique à des points précis de la boucle. Cela exclut les cas d'utilisation tels que les contrôles de conformité ou les règles métier qui doivent s'exécuter à un moment précis du cycle, plutôt qu'au moment où le modèle décide d'appeler un outil.

Aucun streaming bidirectionnel. Le harness ne prend pas en charge le streaming bidirectionnel, ce qui limite les applications nécessitant une communication continue et bilatérale entre le client et l'agent.

Il existe un cinquième point qui relève davantage d'un choix de conception que d'une fonctionnalité manquante, et il est d'autant plus important pour les agents à exécution longue : la gestion du contexte utilise la troncature.

Lorsque la fenêtre de contexte est pleine, le contenu le plus ancien est supprimé. Cela permet à l'agent de rester dans ses limites de contexte, mais signifie également que les informations antérieures peuvent disparaître.

Une approche alternative est la compaction: résumer l'historique ancien dans un enregistrement structuré et conserver ce résumé. Au lieu de simplement supprimer les échanges précédents, l'agent préserve une version condensée des événements, ce qui l'aide à maintenir une continuité sur des exécutions plus longues.

Pour un agent de support rapide, la troncature peut être parfaitement adéquate. Pour une tâche de recherche ou de migration de plusieurs heures, la différence peut devenir beaucoup plus notable : l'agent doit travailler avec une partie réduite de son contexte initial à mesure que l'exécution se prolonge.

Quand utiliser le harness AgentCore

C'est une solution adaptée lorsque :

• Votre infrastructure est déjà sur AWS et vous comptez y rester, et que votre équipe de sécurité souhaite que les agents soient régis par IAM, VPC et CloudTrail.
• Vous avez besoin d'un agent cette semaine et préférez le configurer plutôt que de le construire
• Vous utilisez déjà AgentCore Memory, Gateway, Browser ou Code Interpreter, car le harness transforme tous ces éléments en champs de configuration plutôt qu'en appels SDK
• Le travail de l'agent est une véritable boucle, sans pipeline déterministe imposé
• Outils internes, où la rapidité de livraison prime sur la portabilité

Il s'agit d'un réel ensemble d'avantages, et pour une équipe dédiée à AWS qui développe un agent interne, le harness amazon bedrock agentcore vous permettra d'y parvenir plus rapidement que tout ce que vous pourriez assembler vous-même.

TrueForge : une alternative open source au harness AgentCore

‍

TrueForge adopte une approche différente du problème du harness d'agent. Au lieu de fournir une boucle d'orchestration fixe et gérée, TrueForge est un harness d'agent open source sous licence MIT que vous pouvez exécuter sur votre propre infrastructure.

Le serveur principal est open source, ce qui permet aux développeurs d'inspecter et de modifier la boucle d'exécution plutôt que de la considérer comme une boîte noire. Vous pouvez exécuter TrueForge localement, avec Docker Compose, ou le déployer via Helm.

Cela modifie considérablement la donne. Avec le harness AgentCore, AWS gère la boucle et l'infrastructure environnante pour vous. Avec TrueForge, vous bénéficiez d'un meilleur contrôle sur la manière dont l'agent s'exécute réellement.

Utilisez vos propres modèles et outils

TrueForge est neutre vis-à-vis des modèles et fonctionne avec des points de terminaison compatibles avec OpenAI. Vous pouvez orienter le harness vers le fournisseur de modèle ou le point de terminaison de votre choix sans modifier l'implémentation sous-jacente de l'agent.

Il en va de même pour les outils utilisés par l'agent. TrueForge prend en charge les serveurs MCP et vous permet d'utiliser votre propre environnement de bac à sable (sandbox) plutôt que de lier l'agent à un environnement d'exécution géré unique.

Cela rend la couche du harness indépendante du modèle et de l'infrastructure sous-jacents :

Modèle → TrueForge → MCP / outils / bac à sable

Vous pouvez changer le point de terminaison du modèle sans avoir à reconstruire l'agent autour d'un autre fournisseur.

Contrôlez la boucle de l'agent

L'une des différences majeures par rapport à AgentCore Harness est que la boucle TrueForge est open source.

Cela signifie que les développeurs peuvent examiner la manière dont le harness gère l'exécution et le modifier lorsqu'ils ont besoin d'un comportement non disponible via les options de configuration.

Ceci est utile lorsqu'un agent nécessite une logique personnalisée pour :

• L'exécution d'outils
• Les approbations
• La gestion du contexte
• Les sous-agents
• Le sandboxing
• Les politiques d'exécution
• L'orchestration personnalisée

Plutôt que d'attendre qu'un harness géré expose un hook ou une option de configuration spécifique, l'implémentation sous-jacente est modifiable.

Gestion du contexte

TrueForge adopte également une approche différente en matière de gestion du contexte.

Au lieu de s'appuyer uniquement sur la troncature lorsque le contexte devient trop volumineux, TrueForge utilise la compaction ainsi que des techniques telles que le chargement différé des outils, le mode Code et le déchargement des réponses.

L'objectif est de réduire la quantité de contexte devant rester dans la conversation active tout en conservant les informations dont l'agent a besoin pour poursuivre son travail.

Pour les agents à exécution longue, cette distinction est importante. Un agent travaillant sur une base de code étendue ou une tâche de recherche en plusieurs étapes peut accumuler une quantité considérable de sorties d'outils et de contexte intermédiaire. Supprimer simplement les anciens messages peut rendre ces informations indisponibles ; la compaction offre un moyen de conserver une représentation condensée à la place.

Le bac à sable comme outil

TrueForge aborde également le bac à sable différemment.

Avec AgentCore Harness, la session s'exécute au sein d'une microVM isolée. TrueForge, quant à lui, traite le bac à sable comme un outil pouvant être provisionné lorsque l'agent a réellement besoin d'exécuter du code.

Cela signifie que le bac à sable n'a pas besoin d'être l'environnement de toute la session de l'agent. Il devient une capacité supplémentaire que l'agent peut invoquer si nécessaire.

Cela reflète une différence de philosophie plus large :

AgentCore Harness : environnement géré autour de l'agent.

TrueForge : runtime ouvert où des capacités telles que le bac à sable peuvent être intégrées à l'agent.

Positionnement de TrueForge

La distinction repose en fin de compte sur le contrôle.

AgentCore Harness est conçu pour offrir aux développeurs un moyen géré d'exécuter des agents sans avoir à créer eux-mêmes la boucle d'orchestration. TrueForge est conçu pour les développeurs qui souhaitent que le harnais lui-même reste personnalisable et indépendant d'un fournisseur cloud ou d'un framework d'agent particulier.

Cela rend TrueForge particulièrement pertinent lorsque vous devez contrôler la boucle de l'agent, modifier la gestion du contexte, choisir votre propre point de terminaison de modèle ou exécuter le harnais sur votre propre infrastructure.

‍

FAQ

Q : Qu'est-ce que le harnais AgentCore ?

R : Le harnais AgentCore est le harnais d'agent géré par AWS au sein d'Amazon Bedrock AgentCore, disponible de manière générale depuis 2026. La boucle d'orchestration est fournie et alimentée par Strands Agents ; vous déclarez donc l'agent sous forme de configuration, couvrant le modèle, l'invite système, les outils, la mémoire et les limites d'exécution, plutôt que d'écrire la boucle vous-même. Les sessions sont avec état par défaut et s'exécutent dans une microVM isolée avec leur propre système de fichiers et leur propre shell.

Q : Quelle est la différence entre le harnais AgentCore et le Runtime AgentCore ?

R : Le Runtime est un hébergement sans serveur et le harnais est une boucle gérée qui s'exécute à l'intérieur. Avec le Runtime, vous apportez votre propre code d'agent dans n'importe quel framework, vous le packagez sous forme de conteneur ARM64, vous le poussez vers ECR et vous écrivez l'orchestration vous-même. Avec le harnais, il n'y a ni conteneur ni boucle à écrire. AWS enregistre les opérations du harnais sous AWS::BedrockAgentCore::Runtime, ce qui constitue le signal le plus clair de la relation entre les deux.

Q : Puis-je utiliser LangGraph ou un autre framework avec le harnais d'agent fourni par AgentCore ?

R : Pas avec le harnais. AWS considère le choix d'un framework d'agent comme non pris en charge, car la boucle est constituée par Strands Agents. Vous pouvez exécuter LangGraph, CrewAI ou du code personnalisé sur le Runtime d'AgentCore, car le Runtime est conçu pour être agnostique vis-à-vis des frameworks, mais passer au harnais signifie abandonner ce code. C'est la raison principale pour laquelle les équipes engagées sur un framework restent sur le Runtime.

Q : Puis-je exécuter un harnais d'agent dans mon propre VPC ou sur site ?

R : Avec un harnais auto-hébergé, oui. TrueForge s'exécute à partir d'une seule commande npx en local, ou via Docker Compose et Helm pour les déploiements d'équipe avec Postgres, Redis, des réplicas et une connexion OIDC. La plateforme gérée de TrueFoundry peut également être exécutée en auto-hébergé, sur site, en environnement isolé (air-gapped) ou hybride, afin qu'aucune donnée ne quitte votre domaine. Le harnais AgentCore prend en charge le réseau VPC, mais il s'exécute sur AWS.

Q : Comment gouverner les modèles et les serveurs MCP pour un grand nombre d'agents ?

R : Via une couche de passerelle, une fois que les clés par équipe ne suffisent plus à l'échelle. L' AI Gateway de TrueFoundry place plus de 1 000 LLM derrière une API compatible OpenAI avec environ 3 à 4 ms de latence ajoutée et plus de 350 RPS sur un seul vCPU, avec RBAC, budgets, garde-fous et rotation des identifiants, ainsi que des traces OpenTelemetry vers Grafana, Datadog ou Prometheus. Les agents sur AgentCore, TrueForge ou tout autre système sont gouvernés de la même manière.

Lectures associées

• Harnais d'agent vs Framework d'agent : quelles sont les réelles différences ?: la distinction de catégorie sous-jacente à cet article
• Meilleurs harnais d'agent en 2026 : comparatif des 5 meilleures options: état des lieux du secteur
• Meilleur harnais d'agent open source: les options ouvertes, si vous écartez les solutions gérées
• Alternatives aux agents gérés Claudela même décision avec le harnais géré d'Anthropic
• Amazon Bedrock Agents face au plan de contrôlela question plus large de l'architecture AWS

Conclusion

Le harnais AgentCore est un bon produit avec une limite clairement définie. Il supprime la boucle, le conteneur et la majeure partie du travail d'orchestration, et en échange, il impose le choix du framework, les hooks, les modèles hors boucle et la stratégie de contexte. AWS est transparent à ce sujet, ce qui facilite la prise de décision par rapport à l'accoutumée.

La question n'est donc pas de savoir si le harnais est bon, mais si vous souhaitez maîtriser la boucle sur laquelle vos agents s'exécutent. Si la réponse est oui, ou si les tâches de longue durée sont votre quotidien, un harnais ouvert justifie la journée de configuration supplémentaire.

npx @truefoundry/trueforge vous permet d'obtenir un agent opérationnel en une minute environ, ou découvrez comment TrueForge gère le contexte lors d'exécutions longues.

‍

‍