Contrats de délégation pour les équipes d’agents IA : portée, gestion de l’acceptation et des échecs
Pourquoi les intitulés des postes d’agent n’empêchent pas des transferts de responsabilités défaillants, et comment un contrat de délégation avec des politiques imposées, ainsi que des règles d’acceptation et d’échec indépendantes, peut être testé.
Imaginez un changement de produit géré par trois agents : l’ajout d’une pagination par curseur à une API, au client qui l’appelle, et aux tests. Tous trois indiquent un succès, mais le client ne parvient pas à interpréter ce que l’API renvoie. L’agent de l’API émet next_cursor, l’agent du client s’attend à nextCursor, et l’agent des tests vérifie les simulations basées sur les hypothèses du client. Chaque tâche locale semble terminée, mais le changement global échoue dès la première requête réelle.
Attribuer aux agents les étiquettes « Ingénieur », « Spécialiste client » et « Réviseur » ne précise pas quelle interface l’emporte ni qui approuve le résultat. Ces décisions doivent figurer dans un contrat de délégation, c’est-à-dire une attribution concrète qui indique les entrées, la portée autorisée, la sortie requise, les conditions d’acceptation et ce qui se passe en cas d’échec. Sa valeur réside dans la manière dont le système utilise cet accord, et non dans la création d’un document supplémentaire.
Pensez-y en termes de niveaux : un rôle définit la façon dont un agent aborde le travail, tandis qu’un contrat précise quelles contributions sont acceptables. La politique en temps de exécution détermine ce que l’agent est réellement capable de faire, et l’acceptation décide si cette contribution se transforme en état produit.
La spécialisation laisse la transmission ouverte
Un rôle décrit un point de vue, tel que la recherche de problèmes de sécurité, la construction de l’interface utilisateur ou le remise en question du design. Un contrat de tâche décrit une mission spécifique : utiliser cette version de l’interface, modifier ces fichiers, fournir cette preuve. Les autorisations en temps de exécution déterminent ce que l’utilisateur peut réellement lire, modifier ou exécuter.
En les séparant, on permet à un rôle utile de rester efficace sans qu’il soit responsable de tout. Un réviseur peut identifier des changements problématiques sans avoir le droit de les valider, et un ingénieur peut proposer une version révisée de l’interface sans pouvoir la rendre officielle.
La recherche sur les multi-agents menée par Anthropic en août 2026 rend le problème de dépendance concrètement visible. Dans ses expériences de création de jeux, les rôles prescrits et une hiérarchie de type PDG n’ont guère changé, et les jeux sont restés de mauvaise qualité même si certains modèles obtenaient de meilleurs résultats sur les critères de coordination. Le même rapport souligne des comportements corrélés ainsi que des erreurs corrélées. Ces résultats proviennent d’expériences spécifiques et ne disent rien de définitif au sujet de chaque équipe d’agents ; de plus, leurs comparaisons relatives à la détection des vulnérabilités diffèrent en termes d’ampleur et d’utilisation des ressources, ce qui empêche de déterminer précisément quel facteur de coordination a joué un rôle.
Un contre-exemple existe. Le rapport technique d’Anthropic sur son système de recherche indique des améliorations grâce à la recherche parallèle et décrit des tâches dotées d’objectifs, de formats de sortie, de directives relatives aux outils et de limites. Il mentionne également une utilisation plus élevée des ressources et met en garde contre les travaux présentant de nombreuses dépendances. Cela plaide en faveur d’une approche sérieuse de la décomposition, mais cela ne prouve pas qu’une architecture de recherche puisse être transposée telle quelle à l’ingénierie au sein d’une base de code partagée.
La proposition présentée ici concerne la frontière entre les tâches déléguées et celles qui sont directement acceptées. Il convient de tester si le fait d’établir cette frontière de manière explicite en vaut la peine en termes de coûts supplémentaires.
Rédiger la tâche en fonction des dépendances
Pour la modification de la pagination, commencez par faire en sorte que le responsable du produit corrige le comportement souhaité et que le responsable de l’API approuve l’interface. Supposons que l’interface utilise next_cursor, où null indique la dernière page. Les composants API et les clients peuvent alors être développés en se basant sur une révision donnée, tandis que les tests d’acceptation vérifient le résultat final.
Le YAML suivant illustre un contrat pour le composant client. Ses chemins, noms de révision et identifiants de vérification font partie de cet exemple et ne constituent ni une norme ni un élément de l’API d’un framework quelconque.
task_id: pagination-client-17
objective: Fetch successive pages using next_cursor; stop at null.
inputs:
repository:
ref: product-repo
revision: base-42
requirement:
ref: pagination-behavior
revision: r3
interface:
ref: api/pagination.yaml
revision: r7
scope:
writable:
- client/pagination.ts
- tests/client/pagination.test.ts
non_goals:
- interface_changes
- api_changes
- deployment
deliverable:
- patch_against_base-42
- check_results_bound_to_patch_and_input_revisions
acceptance:
checks:
- client-pagination-unit
- pagination-api-client-e2e
owner: product-maintainer
policy_ref: client-worker-v2
failure:
stale_or_conflicting_input: stop_and_report_to_owner
missing_evidence: return_incomplete
authority_required: request_owner_decision
max_attempts: 2
exhausted: return_unaccepted_to_owner
Les noms des vérifications doivent correspondre à des commandes et des assertions réelles dans un registre que le lanceur contrôle. Dans cet exemple, ils représentent des vérifications unitaires concernant la gestion du curseur ainsi qu’une vérification bout en bout qui examine plusieurs pages à l’aide de l’API candidate réelle, y compris le null de fermeture. Le travailleur client peut exécuter ses propres vérifications unitaires, tandis que le lanceur d’intégration génère les preuves combinées une fois que les deux correctifs sont disponibles.
De même, policy_ref ne fait que désigner une politique. Le dispatcheur doit associer l’affectation approuvée à un travailleur authentifié et rechercher cette politique dans une configuration que le travailleur ne peut pas modifier. Une référence inconnue, ou une demande de politique plus stricte, doit entraîner l’échec de la validation, et modifier le YAML ne devrait jamais accorder des droits supplémentaires.
Limiter le travail à deux tentatives est un choix local qui maintient les boucles de réparation dans des limites définies, mais cela ne dit rien sur la fiabilité. Un budget d’exécution fini fixé par le propriétaire garantit qu’aucune tentative ne se poursuivra indéfiniment.
Une tâche structurée n’est pas une frontière d’autorisation. YAML peut décrire la portée prévue, mais le système d’exécution doit encore la faire respecter.
Un parcours d’étapes qui rend le contrat réel
Autour des travailleurs se trouve un parcours d’étapes. Le mécanisme de coordination ici n’est rien de plus que le logiciel qui lance les travailleurs, gère leurs outils et enregistre ce qui s’est passé.
- Approuver les dépendances : les propriétaires du produit et de l’API valident les exigences ainsi que l’interface.
- Valider l’affectation : son auteur fournit le contrat ainsi que les versions finalisées.
- Dépêcher selon une politique imposée : le dispatcheur lance des travailleurs API et clients isolés.
Cette tâche peut être réalisée par un humain ou par un autre agent. Deux vérifications ont ensuite lieu : un validateur déterministe confirme que la structure est correcte et que toutes les références fonctionnent, tandis que le responsable vérifie que le texte reflète bien les exigences du produit. Ensuite, le dispatcheur attend l’existence de dépendances approuvées, charge les données nécessaires et lance chaque travailleur dans ses limites définies.
Quatre questions doivent rester distinctes. La validité du schéma vérifie si les champs requis existent et sont bien formatés. L’adéquation sémantique s’assure que l’affectation décrit correctement le travail à effectuer. Le contrôle des permissions détermine si un utilisateur peut outrepasser ses autorisations. Les preuves de résultat vérifient si le produit final répond aux exigences. Un document structuralement valide ne répond qu’à la première de ces questions.
Pour assurer le respect des règles, une liste de chemins écrivables doit constituer une véritable restriction en temps de exécution, soutenue par une vérification des fichiers modifiés lors de l’intégration. L’accès au shell ne doit pas offrir une alternative aux contrôles de fichiers ou de réseau. Un processus d’approbation séparé permet de garder les propositions distinctes, mais il ne constitue pas à lui seul une limite d’autorisation.
L’annonce de GitHub sur les permissions gérées du 9 septembre décrit les opérations qui sont bloquées au niveau central, nécessitent une approbation ou sont autorisées, avec des limites que les paramètres de l’espace de travail ne peuvent pas assouplir. Sa description architecturale des workflows agents évoque une exécution isolée ainsi que des écritures en plusieurs étapes, soumises à vérification. Ces deux approches constituent des exemples de mécanismes de contrôle, mais aucune ne prouve que cette conception de délégation améliore la livraison ou garantit des modifications correctes.
Propriété du résultat fusionné
Dans l’exemple de pagination, le moteur d’intégration fusionne les propositions API et client dans un espace de travail temporaire. Il vérifie la portée, contrôle les versions des données d’entrée et exécute les vérifications d’acceptation enregistrées sur ce candidat précis. L’expéditeur de l’acceptation lit ensuite les preuves et évalue toute décision liée au produit que les vérifications ne peuvent pas trancher.
L’acceptation indépendante signifie que le travailleur qui a effectué la tâche ne contrôle pas seul les critères et les preuves. Les assertions et les fixtures de bout en bout restent hors de portée des accès d’écriture du travailleur, et les résultats sont liés au résumé du candidat. L’acceptation peut combiner des vérifications déterministes avec un mainteneur humain, et un autre LLM est optionnel. Le fait de nommer un modèle « Superviseur » ne confère aucune autorité ni ne rend son jugement fiable.
Seul un propriétaire autorisé peut modifier les critères d’acceptation, et ce, en indiquant une raison enregistrée ainsi qu’une nouvelle version de l’affectation. L’agent d’exécution peut demander une modification, mais il ne doit pas omettre un test échoué du jeu de tests ni redéfinir la pagination en considérant qu’une page est terminée après une seule page.
Finalement, un intégrateur autorisé applique le candidat accepté par l’intermédiaire du chemin de fusion sécurisé déjà en place. Le registre d’acceptation indique le candidat exact ainsi que les versions de données qu’il couvre. Si la branche cible progresse avant l’intégration, le candidat est reconstruit et vérifié à nouveau par rapport à la nouvelle base d’abord.
Les résultats en conflit sont renvoyés à la personne responsable de la frontière contestée. Deux interfaces plausibles restent deux interfaces incompatibles ; donc, tant que cette personne n’a pas pris de décision, aucune proposition ne devient la définition commune simplement parce qu’elle est arrivée en premier.
Gestion des échecs au sein du même flux de travail
Chacun de ces cas doit être testé indépendamment dans le flux de travail de pagination, avec une réponse attendue et une entité chargée d’en assurer le respect.
Lorsque les deux collaborateurs tentent de modifier l’interface, le dispatcheur rejette une double appropriation de celle-ci et les restrictions en temps de exécution empêchent toute modification non autorisée. L’intégration rejette tout correctif qui sort du champ d’application prévu, et le propriétaire de l’API décide de la modification demandée.
Si la révision de l’interface change pendant que des travaux sont en cours, la vérification des dépendances signale la proposition comme obsolète. Le propriétaire choisit s’il souhaite la soumettre à nouveau en fonction de la nouvelle révision, et l’intégration ne peut pas accepter silencieusement les éléments collectés pour l’ancienne version.
Lorsqu’un code plausible apparaît sans preuves, le système de validation enregistre cela comme incomplet. Un exécuteur fiable effectue les vérifications requises, et un message d’achèvement affirmatif ne peut pas remplacer les résultats réels.
Lorsqu’un travailleur s’arrête en cours de route, le harnais enregistre l’interruption et conserve la proposition partielle séparément. Avant le début des travaux de remplacement, l’essai précédent est retiré afin qu’il ne puisse pas soumettre de résultat accepté par la suite.
Si une nouvelle tentative risque de créer deux fois le même environnement de prévisualisation, l’adaptateur d’action externe réconcilie d’abord la demande antérieure. Lorsque le fournisseur prend en charge la déduplication, une clé d’opération stable est utilisée, et les effets restant incertains sont envoyés à leur propriétaire pour examen.
Si l’intégration nécessite des autorisations que le travailleur ne possède pas, la politique d’outil bloque l’opération et envoie une demande au propriétaire compétent. La proposition reste non acceptée jusqu’à ce que cette décision soit prise.
Le scénario d’environnement de prévisualisation est un complément optionnel à l’exemple, géré par le service d’intégration, dont le déploiement reste en dehors des responsabilités du travailleur client. Une clé d’opération désigne un effet unique visé lors de toutes les tentatives de réessai, un identifiant d’essai sépare les exécutions individuelles, et un réessai ne doit pas créer une nouvelle opération simplement pour surmonter une réponse ambiguë.
Le compte Agent Harness précoce de Temporal décrit une exécution durable ainsi que des points de contrôle autour d’une boucle d’agent interne, avec des temps d’attente pour la récupération et l’approbation. Il s’agit d’un projet en développement chez le fournisseur et ne constitue pas une preuve comparative indépendante. Une déduplication ou une réconciliation spécifique au fournisseur reste nécessaire pour les actions externes, car l’orchestration durable seule ne garantit pas des effets exactement une seule fois dans un service arbitraire, et la documentation propre à Temporal sur les réessais préconise une détection des doublons en amont lors des tentatives de réessai.
Chaque réparation consomme une partie du budget alloué aux tentatives et aux ressources déclarés. Lorsque l’un ou l’autre est épuisé, le flux de travail renvoie un résultat non accepté accompagné des preuves correspondantes ainsi que du nom de la personne responsable. Les escalades nécessitent également une date d’expiration ou un moyen de les annuler, afin que la responsabilité ne se perde pas au sein d’une conversation abandonnée.
Les contrats peuvent formaliser un travail incorrect
L’argument le plus fort contre cela est le surcoût. Lorsqu’un seul agent modifie une fonction isolée, le problème ainsi que les tests existants peuvent déjà suffire pour définir l’étendue du travail et assurer un contrôle d’acceptation adéquat. Les prototypes à usage unique et les tâches de recherche indépendantes à faible risque n’ont presque pas besoin de plus que des instructions claires. Créer un service contractuel uniquement pour redénommer de telles dispositions serait inutile.
De même, les contrats ne peuvent ni créer l’intention de production ni modéliser des capacités qui font défaut. Une mauvaise décomposition reste une mauvaise décomposition, les erreurs corrélées persistent, et un oracle d’acceptation défectueux, c’est-à-dire le test ou le jugement qui décide si la sortie est correcte, reste également défectueux. Supposons que le test bout en bout réutilise le mock défaillant du client : son résultat positif manquera alors complètement la panne initiale.
Pour cette raison, ce design mérite d’être comparé à des alternatives plus simples, notamment un seul agent ou un flux de travail déterministe. La question est de savoir si cette coordination supplémentaire améliore la qualité du travail accepté ou contrôle un risque réel pour le volume de travail en question.
Comment le tester
Aucune nouvelle expérience n’a été menée pour cette solution. Trois configurations méritent d’être comparées : un seul agent (A), plusieurs agents avec des attributions basées sur des rôles (B), et plusieurs agents utilisant des contrats de délégation explicites ainsi que la méthode décrite ci-dessus (C).
La justice exige que A, B et C reçoivent des informations sur la tâche et des critères d’acceptation identiques, des outils et des limites de sécurité comparables, des environnements de départ correspondants, ainsi qu’un budget de ressources global déclaré. B et C partagent des modèles et un même nombre d’agents, tandis qu’A utilise un modèle correspondant lorsque c’est possible. La variable étudiée est le mécanisme de délégation et de coordination, sans capacités supplémentaires ni exigences cachées de part et d’autre.
B doit conserver des mesures de sécurité ordinaires ainsi que des descriptions de tâche utiles. S’il élabore naturellement des accords de transfert explicites, il convient d’en enregistrer le comportement sans l’interdire. Il faut publier les configurations réelles afin que la comparaison ne se transforme pas en une mise en œuvre optimisée face à une base de référence délibérément affaiblie.
Sélectionnez des tâches qui représentent un mélange réel : certaines avec des composants indépendants, d’autres avec des dépendances séquentielles, et encore d’autres avec des interfaces ou des ressources partagées entre les agents. Les essais se répètent dans des environnements réinitialisés dans un ordre aléatoire, et les tâches ordinaires restent séparées des pannes introduites délibérément. Après un essai pilote, les configurations sont figées ; les tâches réservées permettent la comparaison réelle, et l’incertitude est indiquée pour chaque structure de dépendance.
La méthodologie d’évaluation d’Anthropic distingue le texte généré de l’état de l’environnement qu’il laisse derrière lui, et elle évalue le modèle ainsi que son environnement d’exécution. C’est là qu’il convient de mesurer : la pagination fonctionne-t-elle dans l’environnement combiné ? Le fait que trois agents annoncent avoir terminé ne prouve rien.
Trois indicateurs principaux s’appliquent : les résultats finaux acceptés, le coût total de chaque résultat accepté, et le temps écoulé jusqu’à l’acceptation. Les coûts comprennent les essais échoués, la coordination, les tentatives de réessai, l’examen, la mise en place ainsi que la rédaction des contrats. La mise en place initiale est indiquée séparément du coût récurrent ; toute hypothèse d’amortissement est précisée, et le temps de travail humain est enregistré ouvertement. Si rien n’est accepté, il convient d’indiquer les dépenses et zéro succès au lieu de présenter un coût unitaire qui semble fini mais est trompeur.
En plus de ceux-ci, il faut suivre les échecs d’intégration, le travail double, les erreurs dues à des données obsolètes, les interventions humaines, les violations du périmètre défini ainsi que les résultats rejetés après avoir été signalés comme achevés. Les violations tentées et réussies sont rapportées séparément, tandis que les essais inachevés et les délais d’expiration restent enregistrés afin que les succès rapides ne masquent pas des échecs prolongés.
Le rejet correct d’un correctif obsolète prouve que les mécanismes de contrôle fonctionnent, mais la tâche liée au produit échoue toujours à moins qu’un résultat valide ne soit accepté dans les délais impartis. Les premiers résultats des essais pilotes ne font que indiquer une direction possible. Si les contrats entraînent des coûts supplémentaires sans améliorer significativement les résultats ou réduire de façon notable les risques, il est judicieux de les éviter pour ce type de charge de travail.
Commencez par un transfert que vous pouvez examiner
Un bon point de départ consiste à utiliser un flux de travail existant comprenant deux personnes et une personne désignée pour l’acceptation. La vérification d’intégration reste en dehors du contrôle des personnes concernées, et chaque cas d’échec est testé séparément avant d’élargir le périmètre. Un bref message dans ce sens peut être adressé à l’agent chargé du codage :
Add the minimum delegation contract to [WORKFLOW].
Acceptance owner: [OWNER].
Preserve existing safety boundaries.
1. Inspect current delegation, inputs, permissions, and acceptance.
Exit: map who assigns, executes, checks, accepts, and commits.
2. Identify missing boundaries; reuse existing issues and checks.
Exit: owner-approved scope, revisions, deliverable, and criteria.
3. Wire the minimum contract into dispatch and result handling.
Exit: references resolve; proposals cannot accept themselves; unauthorized operations are blocked by the actual runtime.
4. Exercise valid and invalid handoffs in isolated fixtures.
Exit: demonstrate acceptance, conflict rejection, stale-input detection, missing-evidence rejection, interruption recovery, bounded retries, and authority escalation. Mock external effects.
5. Report changed files, commands run, outcomes, and remaining gaps.
Exit: distinguish implemented controls from unverified behavior.
Ne remplacez pas la plateforme d’orchestration ni ne modifiez des tâches non liées, et n’publiez, ne déployez pas ni n’élargissez les permissions.
L’API, le client et les tests dépendent toujours de travailleurs capables. Le changement réside dans la règle opérationnelle qui les encadre. Avant que le travail combiné ne soit considéré comme terminé, précisez ce à quoi chaque contribution doit correspondre, qui peut la valider et ce qui se passe si elle ne peut pas être acceptée. Les intitulés de poste ne définissent jamais cette frontière.