Harness agentiques : de la boucle LLM à l’agent en production

Les premières versions d’un agent IA peuvent être remarquablement simples : un prompt, un appel au modèle, un ou deux outils et une boucle qui se poursuit jusqu’à ce que le modèle fournisse une réponse finale.

Cette simplicité est utile. Elle permet aux équipes de valider rapidement un cas d’usage et de vérifier si un modèle sait choisir le bon outil ou décomposer une tâche en étapes pertinentes.

Mais elle masque aussi la partie la plus difficile de la conception d’agents : que se passe-t-il entre le moment où un modèle propose une action et celui où cette action est exécutée dans un système réel ?

Un composant doit interpréter le résultat, vérifier les droits d’accès, appeler l’outil, gérer les échecs, enregistrer le résultat, reconstituer le contexte et décider si la tâche doit se poursuivre. Il peut aussi être nécessaire de mettre l’exécution en pause, de la reprendre, de l’observer ou de l’auditer.

C’est le rôle du harness agentique.

Qu’est-ce qu’un harness agentique ?#

Un harness agentique est la structure d’exécution qui entoure un modèle de langage et en fait un agent capable d’accomplir des tâches. Il pilote les appels au modèle et aux outils, gère le contexte et l’état de la conversation, applique les règles de validation et peut faire progresser l’agent dans une tâche à plusieurs étapes.

Le modèle peut interpréter une demande, raisonner à partir des informations disponibles et proposer l’action suivante. Le harness transforme cette proposition en une étape d’exécution contrôlée.

Une boucle d’agent typique suit le schéma suivant :

1. Construire les données d’entrée du modèle à partir de la demande, des instructions, de l’état actuel et du contexte auquel l’agent est autorisé à accéder.
2. Appeler le modèle.
3. Interpréter le résultat.
4. Renvoyer une réponse finale si la tâche est terminée.
5. Exécuter un outil si le modèle le demande.
6. Transférer la tâche si un autre agent ou un composant spécialisé doit prendre le relais.
7. Ajouter le résultat à l’état de l’exécution.
8. Appeler de nouveau le modèle jusqu’à ce qu’une condition d’arrêt soit remplie.

Plusieurs frameworks d’agents implémentent explicitement ce schéma : le runner appelle le modèle, classe son résultat, exécute les appels d’outils ou les transferts demandés, ajoute les résultats, puis lance une nouvelle itération jusqu’à obtenir un résultat final ou atteindre une limite d’exécution.

Le harness ne remplace pas le modèle et ne raisonne pas nécessairement à sa place. Il coordonne les interactions entre le modèle, les outils, l’état, les règles et les services environnants. Il fait également respecter des limites que le modèle ne doit pas pouvoir contourner.

On peut résumer simplement leur relation :

Le modèle propose une action.
Le harness l’interprète et orchestre la suite.

Ce que gère concrètement le harness#

La boucle entre modèle et outils n’est que le cœur du système. Pour faire fonctionner une véritable application, le harness doit prendre en charge plusieurs autres responsabilités.

1. Construction du contexte#

À chaque étape, le modèle a besoin des bonnes informations : les instructions de l’agent, la demande actuelle de l’utilisateur, l’historique de la session, les résultats des outils, la mémoire, les documents, les artefacts ou l’état métier intermédiaire.

Tout transmettre au modèle ajoute du bruit, augmente la latence et consomme davantage de tokens. En transmettre trop peu empêche l’agent de mener correctement sa tâche à bien.

Le harness assemble donc le contexte nécessaire à l’étape en cours. Avant d’appeler le modèle, il peut réunir les instructions propres à la session, les outils, la mémoire, l’état de la tâche, l’historique de la conversation et d’autres sources de contexte.

La construction du contexte ne relève pas seulement de la recherche d’informations. C’est aussi une question d’autorisation. Les informations incluses dans un appel au modèle doivent correspondre à l’identité, aux droits d’accès et au périmètre de l’exécution en cours.

2. Orchestration de la boucle#

Après chaque appel au modèle, le harness détermine la suite à donner :

• renvoyer une réponse finale ;
• exécuter un autre outil ;
• transférer la tâche ;
• lancer une nouvelle itération ;
• solliciter une contribution extérieure ;
• ou arrêter l’exécution.

La boucle doit rester limitée. Un nombre maximal d’étapes, une limite de temps, un budget, un signal d’annulation ou une règle métier peuvent mettre fin à l’exécution.

Sans ces mécanismes, un agent risque de répéter une action inefficace, d’accumuler les erreurs ou de consommer des ressources sans produire de résultat utile. Les frameworks d’agents proposent donc des contrôles, comme un nombre maximal de tours ou des règles limitant les nouveaux appels au modèle.

3. Exécution des outils#

Un appel d’outil produit par un modèle n’est pas encore une action exécutée. C’est une demande structurée qu’un autre système doit traiter.

La couche d’exécution peut devoir :

• identifier l’outil demandé ;
• valider ses paramètres ;
• vérifier l’identité et les droits d’accès de l’appelant ;
• déterminer si une validation est nécessaire ;
• lancer l’outil dans l’environnement approprié ;
• gérer les dépassements de délai et les échecs ;
• appliquer les règles de nouvelle tentative ;
• enregistrer le résultat ;
• renvoyer ce résultat au modèle dans un format exploitable.

Cette séparation est fondamentale. Un modèle peut demander une action, mais il ne doit pas être seul à décider si elle est autorisée.

Le harness coordonne la demande et les contrôles applicables. Le runtime, la sandbox, le moteur de règles ou un service externe réalise ensuite l’opération correspondante.

4. État, points de reprise et récupération#

Une tâche à plusieurs étapes produit un état : résultats intermédiaires, décisions, fichiers, artefacts, validations ou avancement d’un processus métier.

Si l’exécution échoue après la quatrième étape, reprendre toute la tâche depuis le début peut être inefficace, voire risqué. Un système d’exécution durable doit pouvoir conserver l’état et établir des points de reprise.

Le runtime peut alors reprendre à partir d’un point connu, au lieu de rejouer aveuglément toute la séquence.

Il ne suffit pas pour cela de stocker la transcription d’une conversation. Le système doit savoir quelles actions sont déjà terminées, quels résultats ont été enregistrés de manière définitive et quelles informations sont nécessaires à l’étape suivante.

5. Règles et contrôle humain#

Certaines actions peuvent être automatisées. D’autres présentent assez de risques pour nécessiter des contrôles supplémentaires. Lire un document et déclencher un paiement ne doivent pas être traités comme des opérations équivalentes.

Le système d’exécution peut faire appliquer des règles concernant :

• les outils accessibles ;
• les données autorisées ;
• l’identité de l’utilisateur ;
• les plafonds de coût ou de tokens ;
• les obligations de validation ;
• les périmètres d’exécution ;
• et l’arrêt d’urgence.

Une instruction en langage naturel peut guider le modèle. Une règle appliquée par le système d’exécution limite les actions qui peuvent effectivement avoir lieu.

Cette distinction est importante : les prompts influencent le comportement, tandis que les contrôles au niveau du système déterminent ce que l’agent est techniquement autorisé à faire.

Dans un exemple d’assistance liée à la facturation, « ne jamais promettre un remboursement » est une instruction de comportement ; les droits d’accès, eux, déterminent si l’agent peut consulter les données de paiement ou créer un dossier. Une réponse peut malgré tout enfreindre l’instruction : d’où l’importance des évaluations en production.

6. Observabilité#

Une réponse finale ne suffit pas pour comprendre le comportement d’un agent.

Les équipes peuvent avoir besoin d’examiner l’exécution dans son ensemble :

• les appels au modèle ;
• les outils sélectionnés ;
• les paramètres transmis ;
• les résultats reçus ;
• les échecs et les nouvelles tentatives ;
• les transitions d’état ;
• la latence ;
• la consommation de tokens ;
• le coût ;
• et les ressources consommées.

Cette visibilité aide les ingénieurs à diagnostiquer les échecs, à comparer les configurations, à évaluer l’effet d’un changement de modèle et à vérifier que les règles d’exécution ont été appliquées.

Dans un système agentique, l’observabilité doit couvrir tout le parcours, de la demande initiale au résultat final, et pas seulement la dernière réponse du modèle.

L’observabilité permet aussi d’évaluer les exécutions après la mise en production. Une réponse peut sembler utile tout en enfreignant une règle métier : la trace aide alors l’équipe à comprendre ce qui s’est passé, à enregistrer le cas, à tester une correction et à vérifier le résultat avant de déployer le changement.

Modèle, agent, harness, runtime et SDK : des couches distinctes#

Ces termes désignent des responsabilités différentes, même si leurs frontières varient selon les frameworks.

Le modèle#

Le modèle transforme une entrée en résultat : du texte, des données structurées ou une demande d’utilisation d’un outil.

C’est une capacité dont dispose l’agent, et non le système agentique dans son ensemble.

L’agent#

L’agent associe un objectif à une configuration d’exécution : des instructions, un modèle et, selon le cas d’usage, des outils, du contexte, de la mémoire ou des règles de comportement.

Il représente ce que le système est censé accomplir.

Le harness#

Le harness orchestre le déroulement de ce travail.

Il relie le modèle aux outils, à l’état, aux règles, au contexte et aux conditions d’arrêt. Il interprète les résultats du modèle et coordonne l’étape d’exécution suivante.

Le runtime#

Le runtime est le moteur et l’environnement dans lesquels s’exécutent le harness et le code de l’agent.

Selon l’architecture, il peut aussi fournir des workers, la persistance de l’état, le transport des événements, le stockage des artefacts et l’accès aux services externes. En tant que moteur sous-jacent, le runtime orchestre sur le plan opérationnel l’exécution des agents, les appels d’outils et les callbacks, ainsi que les changements d’état et les interactions avec des services comme les modèles et le stockage.

La frontière entre harness et runtime n’est pas définie de manière parfaitement uniforme dans le secteur. Certains frameworks intègrent des capacités du runtime à leur définition du harness. D’autres distinguent la logique d’orchestration de l’infrastructure opérationnelle.

Cette distinction reste utile :

Harness : la manière dont le travail est orchestré.
Runtime : où le travail s’exécute et grâce à quels services.

Le SDK#

Le SDK est l’interface de développement mise à la disposition des équipes d’ingénierie.

Il peut :

• inclure un runner d’agent local ;
• donner directement accès à l’API d’un modèle ;
• exposer des classes pour définir des agents et des outils ;
• communiquer avec un runtime distant ;
• ou combiner plusieurs de ces fonctions.

Le seul terme « SDK » ne permet pas de savoir où s’exécute la boucle de l’agent.

Cette distinction apparaît clairement dans les architectures produit existantes. Un SDK d’agent peut exécuter la boucle au sein du processus du développeur ; un SDK client peut donner accès à l’API tout en laissant au développeur la charge de la boucle ; et une API d’agents managés peut exécuter à distance l’agent et sa sandbox.

Chez Cominty, le SDK fournit un client d’API typé et les primitives permettant de définir des agents, des outils, des règles, des hooks et d’autres composants de personnalisation. La boucle de l’agent elle-même s’exécute en production sur l’infrastructure de Cominty.

Harness intégré ou harness managé ?#

Il existe deux grandes façons d’exploiter un harness agentique.

Harness intégré#

Dans une architecture intégrée, la boucle de l’agent s’exécute dans l’application ou au sein d’un service directement exploité par l’équipe d’ingénierie.

L’équipe garde ainsi un contrôle direct sur le processus. Mais elle doit aussi exploiter toutes les capacités complémentaires nécessaires à son cas d’usage :

• stockage de l’état et des sessions ;
• reprise après interruption ;
• exécution des outils ;
• gestion des secrets ;
• isolation ;
• gestion des exécutions concurrentes ;
• application des règles ;
• et observabilité.

Un harness local peut convenir lorsque les exécutions sont courtes, que l’environnement est étroitement contrôlé ou que l’équipe souhaite explicitement prendre en charge l’intégralité du runtime.

Harness managé#

Dans une architecture managée, l’application soumet une exécution à un service distant. Le harness et le runtime prennent ensuite en charge sa progression.

Selon l’implémentation, le client peut suivre les événements, recevoir le résultat ou fournir des informations complémentaires sans maintenir actif le processus qui exécute la boucle de l’agent.

Une plateforme d’agents managés peut fournir, sous forme d’un service intégré, le harness, le runtime, la couche d’exécution des outils, les sessions avec état et l’infrastructure de sandbox.

Cominty adopte cette architecture managée.

Un agent peut être défini depuis l’interface graphique, l’API ou le SDK. Lorsqu’une exécution en production démarre, elle se poursuit sur les workers de Cominty, indépendamment du processus client qui l’a soumise.

La place de Cominty dans cette architecture#

Cominty réunit trois couches complémentaires au sein d’une même plateforme Managed Agents.

Un SDK pour définir et contrôler les agents#

Les développeurs utilisent le SDK de Cominty pour décrire un agent et ses capacités :

• instructions ;
• outils ;
• règles ;
• hooks ;
• et composants de personnalisation.

Le SDK sert également de client typé pour communiquer avec la plateforme, lancer une exécution et en récupérer le résultat ou le flux d’événements.

Le SDK n’est pas un moteur d’exécution local qui oblige l’application cliente à rester active pendant toute la durée de la tâche. Une fois soumise, l’exécution est prise en charge par Cominty.

Ce fonctionnement correspond au modèle produit de Cominty : les équipes d’ingénierie développent avec le SDK, tandis que la plateforme exploite l’infrastructure sous-jacente, accessible via une API de streaming unifiée.

Un harness agentique configurable#

Cominty fournit la boucle de l’agent et les mécanismes qui l’orchestrent.

Les équipes ne partent pas d’une boucle vide. Elles personnalisent un harness existant au moyen de composants et de hooks qui reflètent leur produit et leur logique métier.

Le harness :

• construit le contexte de travail ;
• interprète les réponses du modèle ;
• orchestre les appels au modèle et aux outils ;
• coordonne l’application des règles ;
• et détermine si l’exécution doit se poursuivre ou s’arrêter.

Le runtime prend en charge les opérations d’exécution et conserve les changements d’état qui en résultent.

Cominty fournit donc bien plus qu’un SDK d’accès aux modèles. La plateforme met à disposition la couche d’orchestration sur laquelle l’agent s’exécute, tout en laissant aux développeurs la maîtrise de ce qui le différencie.

Un runtime entièrement managé#

Le harness et le code de l’agent s’exécutent sur les workers de Cominty.

Le runtime gère :

• les sessions ;
• l’état d’exécution ;
• les points de contrôle ;
• la reprise après interruption ;
• l’accès aux fournisseurs de modèles ;
• et l’observabilité de bout en bout.

Pour les tâches qui exigent une isolation, Cominty met à disposition des sandboxes dédiées à l’exécution de code et de Skills qui exécutent du code. Cet environnement d’exécution est séparé de l’application qui a soumis la tâche, tandis que l’état nécessaire pour la poursuivre reste disponible sur la plateforme.

La documentation produit de Cominty décrit cette couche opérationnelle comme une orchestration durable avec gestion de l’état, points de contrôle et nouvelles tentatives, exécution en sandbox et observabilité couvrant les entrées et sorties des outils, la latence et les coûts.

Cominty Managed Agents — exemple de cette architecture (ouvre un nouvel onglet)

Cette architecture peut être représentée ainsi :

Le Managed Agent est le résultat opérationnel de cette architecture : une définition d’agent, ses composants de personnalisation, un harness, un runtime, un état persistant et un environnement d’exécution réunis dans un même service.

Autrement dit, Cominty n’est pas simplement un SDK, une sandbox distante ou une passerelle d’accès aux modèles. C’est une plateforme Managed Agents composée de :

Un SDK de développement
+ un harness agentique configurable
+ un runtime d’agent managé

Exemple : traiter une demande d’assistance liée à la facturation#

Prenons un agent chargé de préparer une réponse à un client qui signale avoir été facturé deux fois.

Dans cet exemple, l’agent peut consulter les données de facturation autorisées et la politique de remboursement, puis ouvrir un dossier pour un spécialiste de la facturation. Ses instructions lui interdisent de promettre un remboursement avant cet examen.

L’application métier soumet la demande et lance une exécution. Elle n’a pas besoin de maintenir une boucle d’agent locale active jusqu’à la fin de la tâche.

Le runtime de Cominty charge la définition de l’agent, son état actuel et les règles applicables.

Le harness construit le contexte et détermine le prochain appel au modèle. Le runtime envoie la requête au fournisseur de modèles configuré. Le modèle peut alors demander l’accès à un outil qui récupère les informations de facturation.

Une passerelle d’accès aux modèles peut appliquer à chaque appel la politique configurée pour le choix du fournisseur et basculer vers une solution de secours si le fournisseur principal n’est pas disponible.

Le harness interprète la demande et coordonne les contrôles applicables. Le runtime transmet la requête de facturation autorisée au service connecté et enregistre le résultat dans l’état de l’exécution. Si l’agent doit aussi exécuter du code ou une Skill qui exécute du code, cette opération peut se dérouler dans une sandbox distincte.

Ce résultat est réinjecté dans la boucle. Le harness reconstruit le contexte, le runtime effectue l’appel suivant au modèle et le modèle propose une réponse fondée sur les informations de facturation renvoyées par l’outil.

Après avoir consulté la politique de remboursement, l’agent peut créer le dossier de facturation et rédiger un projet de réponse fondé sur les données de paiement, la politique et l’action effectivement réalisée, sans promettre de remboursement non autorisé.

Tout au long de l’exécution, l’application cliente peut recevoir le flux d’événements, afficher la progression ou attendre le résultat final. Si le processus client s’arrête après avoir soumis la tâche, l’exécution peut se poursuivre sur les workers de Cominty.

Chaque couche a une responsabilité distincte :

• le modèle interprète la demande et propose des actions ;
• le harness orchestre et contrôle la séquence ;
• le runtime exécute et conserve l’état de l’exécution ;
• la sandbox isole l’exécution du code et des Skills qui exécutent du code lorsque cet environnement est nécessaire ;
• le SDK relie l’application métier à la plateforme.

Si une exécution ultérieure promet néanmoins un remboursement, une évaluation en production peut signaler cette réponse pour examen. Le cas enregistré peut ensuite servir à tester de nouvelles instructions et à comparer les résultats avant de mettre le changement en production.

Le choix d’architecture qui sous-tend chaque agent#

Choisir une architecture d’agent ne se limite pas à sélectionner un modèle.

Les équipes d’ingénierie doivent aussi décider :

• où s’exécute la boucle de l’agent ;
• qui est responsable de l’état d’exécution ;
• comment les outils sont isolés ;
• où les droits d’accès sont appliqués ;
• comment une exécution reprend après une interruption ;
• qui exploite les workers chargés de l’exécution ;
• et comment le système est observé et évalué.

Une équipe peut construire et exploiter elle-même l’ensemble de cette couche.

Elle peut aussi garder la maîtrise de ses agents, de ses outils, de ses règles et de sa logique métier, tout en s’appuyant sur un harness et un runtime managés pour l’exécution.

C’est le positionnement de Cominty : une plateforme Managed Agents qui associe un SDK de développement, un harness agentique configurable et un runtime managé.

Les développeurs construisent les éléments qui différencient leurs agents. Cominty exploite la couche nécessaire à leur exécution durable, avec des contrôles explicites et une visibilité de bout en bout.

En résumé#

Un modèle produit un résultat. Un agent poursuit un objectif. Le harness transforme les résultats successifs du modèle en une exécution structurée. Le runtime fournit l’environnement et les services opérationnels qui permettent à cette exécution de se poursuivre, de reprendre après une interruption et d’être observée. Le SDK permet aux développeurs de définir, personnaliser et contrôler le système.

Chez Cominty, ces composants appartiennent à la même plateforme tout en conservant des responsabilités distinctes :

SDK : définir, personnaliser et contrôler.
Harness : orchestrer et encadrer.
Runtime : exécuter, conserver l’état et assurer l’exploitation.
Managed Agent : réunir ces couches en un service utilisable.

Passer d’une boucle expérimentale autour d’un modèle à un système d’exécution encadré ne suffit pas, à lui seul, pour parvenir à la production. C’est néanmoins une étape essentielle pour construire des systèmes agentiques capables de fonctionner de manière fiable dans un environnement de production.