Harness AgentCore pour Amazon Bedrock : présentation, fonctionnement et fonctionnalités clés

Construire un agent IA qui fonctionne dans une démo est relativement simple. En construire un capable d'exécuter des tâches de manière fiable, d'utiliser des outils, de gérer le contexte et de fonctionner dans un environnement de production est nettement plus complexe. C'est là qu'intervient un harness d'agent.

Un harness d'agent se situe entre le modèle et les systèmes avec lesquels il doit interagir. Il gère la boucle d'agent, l'exécution des outils, le contexte, la mémoire, le sandboxing et les autres problématiques de runtime nécessaires pour transformer un LLM en un agent opérationnel.

Le Harness AgentCore pour Amazon Bedrock est un service géré propriétaire d'AWS qui fournit une boucle d'agent pré-intégrée et s'exécute au sein du Runtime AgentCore.

Dans ce guide, nous détaillerons le fonctionnement du Harness AgentCore, ses différences par rapport au Runtime AgentCore, et nous le comparerons à TrueForge sur des critères tels que la prise en charge des modèles, la gestion du contexte, le sandboxing, l'extensibilité, le déploiement et le contrôle de la boucle d'agent.

Qu'est-ce que le Harness AgentCore ?

Le harness AgentCore est un harness d'agent géré au sein d'Amazon Bedrock AgentCore. Lancé en preview publique en avril 2026, il est désormais disponible de manière générale (GA). La boucle d'orchestration vous est fournie, propulsée par Strands Agents, et vous décrivez l'agent au lieu de le développer.

En pratique : vous déclarez un modèle, un prompt système, un ensemble d'outils, des paramètres de mémoire et des limites d'exécution sous forme de configuration. AWS exécute la boucle. La plupart des modifications qui nécessiteraient habituellement d'éditer le code et d'effectuer un redéploiement se résument à un seul champ de configuration. Passer d'un fournisseur de modèle à un autre se fait en modifiant un champ. Ajouter un outil se fait également via un champ.

Chaque session de harness est avec état (stateful) par défaut et s'exécute dans une microVM isolée. L'agent dispose de son propre système de fichiers et de son propre shell, ce qui lui permet d'écrire un fichier, d'exécuter du code, et de conserver des mémoires et des fichiers d'une session à l'autre au lieu de démarrer à zéro à chaque fois.

Deux appels d'API suffisent pour démarrer. CreateHarness définit l'agent, InvokeHarness l'exécute. Il existe également un parcours via la CLI AgentCore et via la console si vous préférez cliquer plutôt que faire des requêtes curl.

Comment fonctionne le Harness AgentCore ?

Le Harness AgentCore est conçu autour d'une approche de l'exécution d'agents pilotée par la configuration.

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

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

À haut niveau, un Harness AgentCore 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 système et les consignes pour 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 (Skills) - des capacités et instructions supplémentaires qui peuvent être mises à disposition de l'agent
• Paramètres d'exécution - des contrôles sur la façon dont l'agent fonctionne

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 besoin de 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 dont la boucle elle-même est accessible.

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

Que contient-il de base ?

Le harness géré couvre un large périmètre sans nécessiter le moindre code :

La sélection de modèles s'étend à Bedrock, OpenAI, Gemini et LiteLLM, et vous pouvez changer de fournisseur en cours de session. Un shell intégré et des outils file_operations sont fournis en standard, tout comme les Agent Skills. La mémoire est disponible sous forme à court terme et à long terme, cette dernière couvrant la mémoire sémantique, de résumés, de préférences utilisateur et épisodique, avec un périmètre défini par utilisateur via un ID d'acteur.

Les autres primitives d'AgentCore s'intègrent sous forme de configuration plutôt que par des appels au SDK : Gateway, Browser, Code Interpreter et les outils de serveurs MCP distants. Les options de système de fichiers incluent un 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 de jetons d'identité pour les jetons OAuth et les clés d'API, et les sessions sont isolées avec la possibilité d'utiliser le réseau VPC. L'observabilité, le streaming des réponses, le versionnement et les endpoints fonctionnent tous sans code personnalisé.

Une exception importante à connaître : les outils inline 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 amène la plupart des utilisateurs à consulter la documentation, il convient donc d'être précis. Les deux résolvent des aspects différents du même problème, et le harness AWS AgentCore vient se superposer au Runtime.

Le harness AgentCore est une abstraction gérée qui s'exécute à l'intérieur du Runtime. CloudTrail enregistre même les opérations du harness sous AWS::BedrockAgentCore::Runtime, ce qui indique clairement où se situe la frontière.

Le Runtime AgentCore est un environnement d'hébergement serverless. Vous fournissez du code d'agent écrit dans n'importe quel framework (ou sans aucun framework), vous l'enveloppez avec le point d'entrée BedrockAgentCoreApp du SDK AgentCore, vous l'encapsulez 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 tuyauterie d'observabilité. La boucle d'orchestration reste la vôtre.

La logique est la même pour presque toutes les fonctionnalités. Sur le harness, tout se fait par configuration sans code. Sur le Runtime, les fonctionnalités sont prises en charge, mais vous devez maintenir leur 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 indiquées comme non prises en charge dans le harness :

Aucun choix de framework d'agent. La boucle est construite autour de Strands Agents. Si votre équipe s'est déjà développée sur LangGraph, CrewAI ou un autre framework, ce code n'est pas réutilisable.

Aucun modèle d'exécution hors boucle d'agent. Les applications structurées sous forme de graphes ou de workflows sont exclues. Si une seule étape de votre pipeline nécessite un modèle et que le reste est du code déterministe, le harness ne permet pas d'exprimer ce type de workflow.

Aucun hook (crochet). Vous ne pouvez pas injecter votre propre logique à des moments précis de la boucle. Cela exclut des cas d'usage comme les vérifications de conformité ou les règles métier qui doivent s'exécuter à un point exact du cycle d'exécution, au lieu de dépendre du 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 à double sens entre le client et l'agent.

Il existe un cinquième point qui relève plus d'un choix de conception que d'une fonctionnalité manquante, et qui s'avère critique pour les agents s'exécutant sur une longue durée : la gestion du contexte utilise la troncature.

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

Une approche alternative est la compaction : elle consiste à résumer l'historique ancien dans un enregistrement structuré et à conserver ce résumé. Au lieu d'abandonner purement et simplement les échanges précédents, l'agent conserve une version condensée de ce qui s'est passé, ce qui l'aide à maintenir sa continuité sur de longues exécutions.

Pour un agent de support rapide, la troncature peut s'avérer parfaitement suffisante. Pour une tâche de recherche ou de migration durant plusieurs heures, la différence devient beaucoup plus marquée : l'agent doit travailler avec une part de plus en plus réduite de son contexte initial à mesure que l'exécution se prolonge.

TrueForge : Une alternative open source au Harness AgentCore

TrueForge adopte une approche différente pour résoudre la problématique 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 central étant open source, les développeurs peuvent inspecter et modifier la boucle d'exécution au lieu de la traiter comme une boîte noire. Vous pouvez exécuter TrueForge localement, avec Docker Compose, ou le déployer via Helm.

Cela modifie considérablement l'arbitrage. Avec le Harness AgentCore, AWS gère la boucle et l'infrastructure sous-jacente pour vous. Avec TrueForge, vous obtenez un contrôle supérieur sur la manière dont l'agent s'exécute réellement.

Apportez votre propre modèle et vos propres outils

TrueForge est neutre vis-à-vis des modèles et fonctionne avec tout endpoint compatible OpenAI. Vous pouvez pointer le harness vers le fournisseur de modèles ou l'endpoint de votre choix sans modifier l'implémentation sous-jacente de l'agent.

Le même principe s'applique aux outils utilisés par l'agent. TrueForge prend en charge les serveurs MCP et vous permet d'apporter votre propre sandbox au lieu de lier l'agent à un environnement d'exécution géré unique.

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

Modèle → TrueForge → MCP / outils / sandbox

Vous pouvez modifier l'endpoint du modèle sans avoir à reconstruire l'agent autour d'un autre fournisseur.

Contrôlez la boucle d'agent

L'une des différences majeures par rapport au Harness AgentCore réside dans le fait que la boucle de TrueForge est open source.

Cela signifie que les développeurs peuvent inspecter la manière dont le harness gère l'exécution et la modifier dès qu'ils ont besoin d'un comportement non disponible sous forme d'option de configuration.

C'est particulièrement utile lorsqu'un agent requiert une logique personnalisée concernant :

• L'exécution des outils
• Les meures d'approbation
• 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 reste directement accessible et modifiable.

Gestion du contexte

TrueForge adopte également une approche différente pour la gestion du contexte.

Au lieu de compter uniquement sur la troncature lorsque le contexte devient trop volumineux, TrueForge utilise la compaction associée à des techniques comme le chargement différé des outils, le Mode Code et le déchargement des réponses.

L'objectif est de réduire le volume de contexte devant rester dans la conversation active tout en conservant les informations indispensables à la poursuite du travail de l'agent.

Pour les agents s'exécutant sur la durée, cette distinction est essentielle. Un agent analysant une vaste base de code ou effectuant une tâche de recherche en plusieurs étapes peut accumuler une quantité importante de sorties d'outils et de contexte intermédiaire. La simple suppression des anciens messages peut rendre ces informations indisponibles ; la compaction permet d'en préserver une représentation condensée.

La sandbox sous forme d'outil

TrueForge aborde également le sandboxing sous un autre angle.

Avec le Harness AgentCore, la session s'exécute entièrement dans une microVM isolée. TrueForge traite plutôt la sandbox comme un outil pouvant être instancié uniquement lorsque l'agent doit exécuter du code.

Cela signifie que la sandbox n'a pas besoin de servir d'environnement permanent pour toute la session de l'agent. Elle devient une capacité supplémentaire que l'agent peut invoquer uniquement lorsque c'est nécessaire.

La couche Runtime pour les agents IA en production

Exécutez des agents en production avec un runtime open source pour vos modèles, outils MCP, sandboxing, approbations et observabilité.

Explorer TrueForge

Voir sur GitHub

Où se positionne TrueForge ?

La différence se résume fondamentalement à une question de contrôle.

Le Harness AgentCore est conçu pour offrir aux développeurs une voie gérée pour exécuter des agents sans devoir construire eux-mêmes la boucle d'orchestration. TrueForge est conçu pour les développeurs qui souhaitent que le harness reste personnalisable et indépendant d'un fournisseur cloud ou d'un framework d'agent spécifique.

TrueForge s'avère donc particulièrement pertinent lorsque vous devez contrôler la boucle d'agent, modifier la gestion du contexte, choisir votre propre endpoint de modèle ou exécuter le harness sur votre propre infrastructure.

Un simple npx @truefoundry/trueforge vous permet d'obtenir un agent fonctionnel en environ une minute, ou découvrez comment TrueForge gère le contexte sur de longues exécutions.

FAQ

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

A : Le harness AgentCore est le harness d'agent géré d'AWS au sein d'Amazon Bedrock AgentCore, disponible de manière générale depuis 2026. La boucle d'orchestration est fournie et propulsée par Strands Agents ; vous déclarez donc l'agent sous forme de configuration (modèle, prompt système, outils, mémoire et limites d'exécution) au lieu d'écrire la boucle vous-même. Les sessions sont avec état par défaut et s'exécutent dans une microVM isolée disposant de son propre système de fichiers et shell.

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

A : Le Runtime assure l'hébergement serverless et le harness 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 l'encapsulez sous forme de conteneur ARM64, vous le poussez sur ECR et vous écrivez l'orchestration vous-même. Avec le harness, il n'y a ni conteneur ni boucle à coder. AWS enregistre les opérations du harness sous AWS::BedrockAgentCore::Runtime, ce qui illustre parfaitement l'imbrication des deux services.

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

A : Pas sur le harness. AWS indique que le choix du framework d'agent n'est pas pris en charge, car la boucle s'appuie exclusivement sur Strands Agents. Vous pouvez exécuter LangGraph, CrewAI ou du code personnalisé sur le Runtime AgentCore (car le Runtime est agnostique par conception), mais passer au harness implique de renoncer à ce code. C'est la raison principale pour laquelle les équipes attachées à un framework spécifique restent sur le Runtime.

Q : Puis-je exécuter un harness d'agent dans mon propre VPC ou on-premise ?

A : Avec un harness auto-hébergé, oui. TrueForge s'exécute à partir d'une seule commande npx en local, ou via Docker Compose et Helm pour des déploiements d'équipe avec Postgres, Redis, réplicas et authentification OIDC. La plateforme gérée de TrueFoundry s'exécute également en auto-hébergé, on-premise, en environnement air-gapped ou hybride, garantissant qu'aucune donnée ne quitte votre domaine. Le harness AgentCore prend en charge le réseau VPC, mais s'exécute au sein d'AWS.

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

A : En passant par une couche de gateway, dès lors que la gestion de clés par équipe devient ingérable. L'AI Gateway de TrueFoundry rassemble plus de 1 000 LLM derrière une seule API compatible OpenAI, en ajoutant seulement 3 à 4 ms de latence et en supportant plus de 350 RPS sur un seul vCPU. Elle offre le contrôle d'accès (RBAC), la gestion des budgets, des guardrails et la rotation des identifiants, tout en fournissant des traces OpenTelemetry vers Grafana, Datadog ou Prometheus. Les agents sur AgentCore, TrueForge ou n'importe quelle autre solution sont ainsi gouvernés de manière centralisée.

Lectures associées

• Harness d'agent vs Framework d'agent : quelles sont les vraies différences ? : la distinction fondamentale traitée dans cet article
• Meilleurs harness d'agent en 2026 : comparaison des 5 meilleures options : un panorama complet du marché
• Meilleurs harness d'agent open source : les options open source si vous écartez les services gérés
• Alternatives à Claude Managed Agents : le même arbitrage appliqué au harness géré d'Anthropic
• Amazon Bedrock Agents vs Le Control Plane : l'architecture globale au sein d'AWS

Conclusion

Le Harness AgentCore et TrueForge adoptent des approches fondamentalement différentes pour la création d'agents IA.

Le Harness AgentCore masque la complexité de la boucle d'agent. Vous définissez le modèle, les instructions, les outils, la mémoire et les autres éléments de configuration, et AWS gère l'exécution. Cela peut simplifier la mise en production d'un agent, en particulier si vous évoluez déjà dans l'écosystème AWS et que les contraintes d'un harness géré vous conviennent.

TrueForge donne davantage de contrôle aux développeurs. Open source, il peut s'exécuter sur votre propre infrastructure et permet de modifier la boucle d'agent sous-jacente. Vous pouvez choisir votre endpoint de modèle, vos serveurs MCP et votre sandbox, et utiliser le harness comme une base flexible plutôt que comme une couche d me d'orchestration rigide.

Le choix dépend donc moins du nombre de fonctionnalités offertes que du niveau de contrôle que vous souhaitez conserver sur le runtime de l'agent.

Si vous souhaitez qu'AWS gère l'orchestration et l'infrastructure, le Harness AgentCore apporte cette abstraction. Si vous préférez inspecter, personnaliser et exécuter le harness vous-même, TrueForge constitue une alternative open source adaptée.

Pour les équipes qui évaluent les infrastructures d'agents, la question essentielle n'est pas simplement : quel harness d'agent devrions-nous utiliser ? Elle est plutôt : quelles parties de la pile d'agent souhaitons-nous confier à la plateforme, et quelles parties souhaitons-nous maîtriser nous-mêmes ?

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