Un agent ou plusieurs : mesurer le gain avant d’ajouter de l’orchestration

Un agent peine à traiter une demande qui réunit commande, règle commerciale et décision de reprise. L’équipe propose un spécialiste par sujet, puis un superviseur chargé de les réunir. Le découpage paraît clair sur le schéma ; à l’exécution, il faut encore transmettre l’identité, les révisions et les restrictions de chaque source. Une négation perdue dans un échange peut transformer une demande à transférer en proposition de remboursement.

En pratique, plusieurs rôles sont une hypothèse d’amélioration, pas une preuve de gain. La comparaison doit conserver mission, sources, droits, juge et budget, puis éprouver les frontières ajoutées. La conception d’agents IA sur mesure doit expliquer le problème que la décomposition résout et le risque qu’elle crée, avant de faire du nombre d’agents une promesse de qualité.

Deux workflows locaux déterministes traitent ici les mêmes six missions fictives : l’un partage le contexte, l’autre échange les résultats de deux rôles. Huit mutations révèlent ce que doit vérifier leur coordination, notamment un tenant erroné, une preuve inversée ou un résultat incomplet. Aucun LLM, autonomie ou parallélisation réelle n’est exécuté. L’expertise IA sur mesure de Dawap peut partir d’un défaut identifié dans la mission pour tester si un rôle supplémentaire le corrige et à quel coût de contrôle.

Pour qui le découpage répond à un problème identifié

Localiser ce que le parcours actuel ne réussit pas

Une erreur peut venir d’une source absente, d’un outil mal défini, d’un contexte trop chargé ou d’une décision métier ambiguë. Ces causes n’appellent pas toutes plusieurs agents. Le diagnostic doit retrouver la trace où le résultat perd sa validité et vérifier si le parcours le plus simple peut être corrigé. Une décomposition qui ne traite pas cette cause peut multiplier les recherches tout en conservant la même réponse erronée.

Le responsable métier précise la sortie attendue et les défauts qui rendent la mission inutile. L’équipe technique identifie les étapes et dépendances. Le produit vérifie comment la personne contrôle le résultat et reprend un blocage. Cette analyse donne une hypothèse concrète : traiter deux recherches indépendantes, isoler un outil spécialisé ou garder une décision critique dans un contrôle distinct. Le titre « spécialiste » attribué à un prompt ne suffit pas à démontrer cette capacité.

Distinguer tâche exploratoire et action fortement couplée

Une recherche de plusieurs sources indépendantes peut se prêter à une décomposition différente d’une modification de commande. Dans cette dernière, montant, état, droits et confirmation peuvent devoir être rapprochés au même moment. Les séparer demande ensuite de reconstruire leur cohérence avant l’effet. Le choix doit suivre les dépendances de la tâche, au lieu de reproduire automatiquement un organigramme de rôles humains.

Le retour d’Anthropic sur son système de recherche multi-agent décrit des tâches parallélisables et des contraintes de coordination. Ses résultats sont liés à son système et à son évaluation. Ils ne permettent pas de promettre le même avantage pour une action ERP, une qualification de dossier ou notre laboratoire déterministe. Le gain doit être établi sur la mission effectivement proposée.

Distinguer plusieurs appels, rôles et agents autonomes

Nommer le contrôle qui décide les étapes

Une chaîne de trois appels prévus par le code n’a pas la même autonomie qu’un système dont le modèle choisit les sous-tâches et les outils au fil de la mission. La distinction influe sur ce qu’il faut tester : chemin fixe, décision de délégation, recherche supplémentaire ou arrêt. Un système peut aussi mêler ces mécanismes ; il faut les décrire là où ils déterminent effectivement la dépense et le résultat.

Dans Building Effective Agents, Anthropic distingue workflows à chemins prédéfinis et agents dont le modèle dirige dynamiquement le processus. Notre banc appartient au premier type, sans appels LLM. Les deux parcours sont définis en Python et les résultats métier suivent une règle fixe. L’exécution vérifie donc un contrat d’échange, sans fournir une preuve de raisonnement agentique.

Formuler le gain attendu avant d’ajouter un rôle

La proposition doit indiquer ce qui devrait s’améliorer : couverture des sources, qualité d’une étape, délai critique ou capacité à utiliser un outil spécialisé. Elle précise le coût acceptable et les défauts bloquants. « Plusieurs perspectives » reste trop vague si personne ne définit les désaccords utiles et la règle qui les résout. Les sorties doivent pouvoir être confrontées au même juge que celles du parcours de référence.

Il faut aussi choisir ce que la décomposition ne doit pas modifier : droits de l’utilisateur, actions autorisées et critère de clôture. Le budget peut être identique pour comparer l’usage des ressources, ou explicitement différent pour tester un compromis qualité/coût. Les deux analyses répondent à des questions distinctes. Augmenter ressources et nombre de rôles en même temps sans les déclarer empêche d’attribuer correctement une amélioration observée.

Conserver la même mission dans la comparaison

Fixer l’entrée, les sources et la sortie utile

La mission fictive M34 concerne la commande Q34 de A pour Alice. Elle consulte une commande à la révision 7 et une politique P34 à la révision 3. La sortie reste une préparation locale : proposition à relire lorsque le remboursement est permis, transfert lorsque la règle l’interdit. Aucun parcours ne publie ni ne rembourse réellement. Le résultat doit conserver cette même frontière dans les deux coordinations.

Le contrat d’entrée comprend mission, tenant, sujet et cible établis par le service. Le contrôle final conserve la responsabilité de rapprocher source courante et proposition. L’instrumentation note lectures tentées, messages de rôles, taille JSON et décision. Le repli est une préparation de transfert ou un refus attribué ; il n’élargit pas les permissions pour obtenir une sortie favorable. Ces éléments restent communs avant d’examiner les échanges supplémentaires.

Séparer les défauts communs des défauts de communication

Les six missions comparent nominal, règle d’interdiction, source absente, source modifiée, sujet absent et mauvaise cible. Elles s’appliquent aux deux parcours. Les huit mutations d’échange concernent ensuite la coordination par rôles, car l’autre parcours ne possède pas ces messages. Elles mesurent sa frontière supplémentaire. Elles ne doivent pas être mélangées à un taux global qui ferait paraître une architecture intrinsèquement moins fiable.

La comparaison réelle doit également conserver les cas où le parcours simple échoue et où la décomposition pourrait aider. Les résultats du laboratoire ne représentent pas cette distribution : ses règles rendent volontairement les verdicts communs identiques. Une recette LLM devra observer sorties, variabilité et répétitions sur une population indépendante du choix d’architecture, sans sélectionner après coup les demandes qui favorisent les nouveaux rôles.

Découper un travail sans perdre ses dépendances

Donner une sortie explicite à chaque sous-tâche

Le rôle order retourne faits de commande, identifiant et révision ; policy retourne règle commerciale, identifiant et révision. Le coordinateur n’a pas besoin de recevoir une conversation complète ni une opinion générale sur la demande. Il attend les informations nécessaires au contrôle final, avec un état de manque lorsqu’une source n’existe pas. Le contrat de rôle indique aussi les opérations qu’il ne peut pas accomplir.

Les sous-tâches ne doivent pas recevoir automatiquement tous les droits de la mission. Un rôle de lecture documentaire peut avoir besoin d’un corpus limité ; un autre peut lire un dossier précis. La responsabilité de délégation reste au service qui établit leur contexte. Ajouter un compte technique ou un modèle spécialisé ne crée pas une permission d’agir que l’utilisateur représenté ne possède pas.

Mesurer le chemin critique plutôt que le nombre de travailleurs

Deux recherches indépendantes pourraient être exécutées en parallèle, puis attendre l’agrégation. Une vérification qui dépend du résultat de la première ne gagne pas automatiquement cette possibilité. Le délai total dépend aussi de la file, des limites de fournisseur et des reprises. Un schéma montrant deux boîtes côte à côte n’est pas une mesure de latence et ne prouve pas que la capacité réelle les exécute simultanément.

Notre code exécute les deux rôles séquentiellement et ne mesure aucune durée. Il compte leurs messages pour rendre le contrat observable. Dans une recette de production, le suivi doit distinguer temps actif des rôles, attente de synchronisation et délai de clôture. Un rôle supplémentaire peut rester justifié pour sa qualité ou son périmètre, même sans gain de vitesse ; ce compromis doit être déclaré et éprouvé.

Faire suivre le contexte et la preuve dans chaque résultat

Rendre l’échange vérifiable par le coordinateur

Un résultat porte mission, tenant, sujet, rôle, source et révision, puis faits. Le coordinateur vérifie forme exacte, origine attendue dans le banc, unicité et présence des deux rôles. Un résultat issu d’une autre mission ne devient pas pertinent parce que sa formulation ressemble à la demande. L’identité et le périmètre doivent être confrontés au contexte de confiance, pas reconstruits à partir du texte de synthèse.

Le laboratoire transmet des dictionnaires en mémoire. Il ne met en œuvre ni signature ni authentification entre services. L’égalité des champs vérifie seulement la cohérence selon la recette, sans démontrer qui a réellement produit un message réseau. Une architecture distribuée doit définir transport, identité des émetteurs, accès et rétention. Ces garanties ne peuvent pas être déduites du seul JSON conforme affiché dans une trace.

Conserver la restriction sans la résumer en autorisation

Cas concret : la politique interdit le remboursement dans C34-02. H34-05 reprend cette source et inverse refund_allowed à vrai dans le message du rôle. fact_mismatch refuse l’échange avant la préparation. Le contrôle compare les faits à l’instantané de source conservé ; il ne demande pas au coordinateur de décider si la formulation semble convaincante ou si la majorité des rôles approuve la proposition.

Une synthèse plus libre peut perdre une négation, une exception ou une limite de périmètre. Le contrat doit conserver les éléments qui changent la décision, avec références vérifiables. Il faut distinguer fait extrait, interprétation et proposition d’action. Une réponse élégante n’est pas une preuve suffisante de conservation de la règle. Le service doit pouvoir refuser un résultat incomplet sans encourager les rôles à le remplir par hypothèse.

Vérifier les faits avant de réunir les réponses

Attendre les résultats nécessaires au verdict

Le coordinateur attend exactement un résultat order et un résultat policy. H34-07 retire le second : incomplete_roles refuse l’agrégation. Un résultat dupliqué ne remplace pas celui qui manque, et une réponse reçue deux fois ne constitue pas deux preuves. La politique de clôture doit définir les rôles indispensables et la conduite à tenir lorsqu’un résultat reste absent, au lieu de laisser la synthèse combler son contenu.

{
  "mission_id": "M34",
  "tenant": "A",
  "subject": "alice",
  "role": "policy",
  "source_id": "P34",
  "source_revision": 3,
  "facts": {
    "refund_allowed": true,
    "needs_review": true
  }
}

Ce message nominal appartient à C34-01 ; la règle de C34-02 et de H34-05 possède refund_allowed=false. Les deux contextes ne doivent pas être mélangés dans la comparaison. Le contrôle de laboratoire vérifie clés et égalité aux instantanés ; il n’est pas un validateur complet de tous les types JSON. Un contrat réseau réel doit préciser types, erreurs, versions et compatibilité avant d’utiliser ces messages comme entrée d’une décision.

Conserver une frontière finale commune

Après lecture ou agrégation, les deux workflows appliquent le même contrôle sur cible et révisions courantes. C34-04 passe la commande de la révision 7 à 8 avant préparation : source_stale refuse. C34-06 propose Q99 au lieu de Q34 : target_denied refuse. La présence de deux rôles conformes ne remplace donc pas la vérification au moment où leur résultat doit devenir une proposition utilisable.

Un agent de contrôle supplémentaire peut aider une évaluation, mais ne garantit pas son indépendance. Il peut recevoir le même contexte incomplet ou suivre la formulation du premier agent. Pour les effets critiques, le service doit conserver les contraintes vérifiables et l’autorité métier nécessaires. Les avis de plusieurs modèles ne deviennent pas une permission d’action par un simple vote majoritaire dans la conversation.

Six missions exécutées dans deux workflows locaux

Comparer décisions et traces sur les mêmes entrées

Chaque mission utilise des copies indépendantes du contexte et des sources. Les règles locales déterminent les mêmes sorties dans les deux workflows. Les lectures sont des accès à un registre Python en mémoire, comptés même lorsqu’une source manque. Les octets correspondent au JSON compact trié en UTF-8 : instantanés de sources pour le parcours partagé, liste des messages pour le parcours par rôles. Aucun coût de tokens n’en est déduit.

Le parcours partagé ne produit aucun message de rôle. En C34-03, le parcours par rôles a déjà retourné order lorsque policy manque ; cette réponse partielle ne suffit pas à préparer la mission. En C34-05, les deux objets vides occupent chacun deux octets, sans lecture. Ces valeurs rendent le comptage contrôlable, mais leur taille choisie ne prédit pas celle des contextes ou conversations d’une application réelle.

Ne pas transformer l’égalité locale en conclusion générale

Les décisions identiques résultent de règles déterministes communes ; elles ne prouvent pas qu’un agent unique vaut plusieurs modèles. Le banc ne pose aucune question à un LLM et ne teste ni raisonnement ni exploration de nouvelles sources. Son utilité est de conserver une sortie et un contrôle comparables lorsque la coordination change. La preuve de gain devra être obtenue sur les sorties effectivement générées et leurs conséquences.

Une recette de modèles doit distinguer défaut métier, défaut d’échange et résultat inachevé. Elle conserve les tentatives et budgets, ainsi que les versions de prompts, outils et sources. Le juge doit disposer d’une grille commune, avec cas critiques et relecture. Un score de chaque rôle séparément ne suffit pas si leur résultat agrégé perd une restriction ou ne permet pas de terminer la tâche.

Huit défauts d’échange et leurs refus

Provoquer une perte de contexte plutôt que l’attendre

Les mutations commencent avec la politique d’interdiction de C34-02. Elles modifient un champ, ajoutent un résultat ou en retirent un avant le contrôle d’agrégation. Les codes correspondent à la première frontière refusée. Un refus de forme ne dit pas si les champs restants auraient été acceptés. Aucun message n’est produit par un modèle et aucune de ces erreurs n’est présentée comme sa fréquence probable.

Deuxième cas concret : H34-04 possède les deux rôles attendus puis un troisième résultat order dupliqué. duplicate_role refuse, sans compter ce résultat comme un avis supplémentaire. La déduplication du transport et l’unicité du rôle dans une mission sont deux contrats à distinguer. Une rediffusion reconnue peut être récupérée autrement, mais elle ne doit pas renforcer artificiellement une majorité ou créer une nouvelle action.

Garder une reprise qui ne fabrique pas le résultat manquant

Un rôle absent peut demander une nouvelle lecture, une attente bornée ou un transfert. La reprise conserve la mission et revalide la source, avec une nouvelle tentative identifiée. Elle ne modifie pas les permissions ou le rôle attendu simplement pour rendre la liste complète. La politique doit définir quelles données déjà acquises restent utilisables et quelle cause empêche encore la préparation.

H34-08 ajoute une instruction de publication dans un résultat de lecture. Le banc refuse ce champ inattendu ; aucun outil de publication n’existe. Une production doit également protéger les chemins d’exécution réels et distinguer donnée reçue d’un mandat d’action. Un message conforme ne doit pas conférer à son destinataire un droit plus large que la mission, même si l’émetteur possède lui-même une capacité technique supérieure.

Mesurer le coût et l’attente du travail complet

Rattacher les dépenses des rôles à la même mission

Une comparaison de coût doit compter appels, contextes transmis, recherches, retries et agrégation. Les dépenses d’un rôle qui ne termine pas restent dans le coût de la mission. Il faut conserver une réserve partagée pour que chaque rôle ne dépense pas indépendamment le budget entier. Le budget d’exécution d’un agent décrit les réservations et consommations inconnues à garder avant d’admettre une tentative supplémentaire.

Dans C34-01, les deux workflows lisent deux sources, mais leurs objets sérialisés occupent 164 et 306 octets. Ce surplus provient du format choisi et de ses métadonnées. Il n’est pas une estimation de tokens ni de facture fournisseur. Un LLM peut recevoir d’autres contextes et générer d’autres sorties ; son coût doit être mesuré selon l’interface et les consommations réellement observées, avec les échecs conservés.

Examiner la qualité obtenue pour cette dépense

Paradoxalement, des rôles individuellement rapides peuvent produire une mission plus lente si l’agrégation attend le plus lent, recommence une lecture ou résout des contradictions. La recette doit mesurer le chemin complet jusqu’à un résultat utile. Les délais doivent distinguer file, exécution, communication et vérification humaine. Une baisse du temps d’un spécialiste ne démontre pas une baisse du délai que le métier subit.

Une dépense supplémentaire peut être acceptable si elle améliore un défaut important selon la grille de qualité. Ce compromis doit être explicite, avec seuils et périmètre. Il ne faut ni exiger un multi-agent pour une simple tâche par principe, ni refuser toute décomposition parce qu’elle coûte plus d’appels. La décision dépend du gain prouvé, des erreurs ajoutées et de la capacité d’exploitation de l’ensemble.

Erreurs fréquentes dans une comparaison multi-agent

Comparer un ancien parcours mal équipé à une nouvelle équipe favorisée

Donner aux nouveaux rôles davantage de sources, un modèle plus puissant et un budget supérieur, puis attribuer tout le résultat à leur nombre, rend la comparaison trompeuse. Ces changements peuvent être utiles, mais ils doivent être séparés dans la recette. Le parcours simple doit disposer d’un contrat d’outil et de sources de qualité comparable avant de décider que sa coordination constitue le problème.

Une autre erreur est de noter seulement les succès des nouveaux rôles. Les recherches répétées, résultats incomplets et refus d’agrégation font partie du service. La comparaison doit conserver les missions communes et une fenêtre de clôture. Elle indique ce qui a été corrigé entre versions et ce qui reste à éprouver, sans transformer chaque ajustement favorable en un avantage universel de l’architecture.

Prendre des avis convergents pour des preuves indépendantes

Deux rôles peuvent répéter le même fait faux parce qu’ils lisent le même résumé ou partagent une source périmée. Leur accord n’ajoute pas une preuve indépendante. Le coordinateur doit savoir quelles références soutiennent chaque affirmation et quelles erreurs peuvent être communes. La séparation des noms, modèles ou prompts ne garantit pas cette indépendance à elle seule.

La revue peut aussi devenir une boucle sans progression : un rôle corrige, un autre critique et le superviseur recommence sans résultat nouveau. Il faut définir sortie attendue, limite de tentatives et cause de reprise. Les contrôles déterministes sur cible, accès et révision restent utiles même lorsque plusieurs modèles jugent favorablement la proposition. La conversation ne doit pas devenir une autorité qui contourne ces frontières.

Plan d’action pour une preuve de coordination utile

Partez d’un défaut précis du parcours actuel et conservez une mission de référence. Le contrat doit nommer entrée, sortie, sources disponibles et responsable de décision. Décrivez ensuite la décomposition proposée et les informations qui doivent traverser chaque échange. L’instrumentation suit lecture, message, dépense et résultat jusqu’à la clôture ; le repli garde les faits acquis et les restrictions qui rendent encore la mission incomplète.

1. Diagnostiquer la limite avant de distribuer le travail. Retrouvez la trace du défaut et vérifiez source, outil, contexte et ambiguïté métier. Formulez le gain attendu de chaque rôle. Si une correction locale suffit, mesurez-la avant d’introduire une orchestration qui demandera ses propres contrats, traces et procédures d’exploitation.
2. Geler les conditions de comparaison. Gardez mission, population, sources, juge et actions autorisées constants. Déclarez budgets et versions. Distinguez une comparaison à ressources égales d’un compromis qualité/coût avec davantage de moyens, afin que l’amélioration puisse être attribuée et discutée au bon niveau.
3. Définir les résultats des rôles. Portez origine, cible, tenant, source, révision et faits utiles. Vérifiez identité réelle des émetteurs et transport si le système est distribué. Distinguez un manque d’information d’une proposition de nouvelle action ; ne laissez pas une synthèse élargir la portée de la mission initiale.
4. Éprouver l’agrégation et les reprises. Provoquez résultat absent, doublon, mauvaise mission, fait inversé et source changée. Ajoutez les erreurs du runtime réel, avec délais et budgets. Gardez des cas favorables pour vérifier que le contrôle n’a pas fermé toute la capacité et que le repli conserve un état utilisable.
5. Mesurer le résultat complet avec les modèles retenus. Évaluez qualité, missions inachevées, coût connu, exposition et attente. Conservez les répétitions et cas critiques. Décidez de la décomposition seulement après cette preuve, puis archivez la configuration et les limites qui conditionnent son ouverture et sa réévaluation.

La première recette peut rester un laboratoire de contrats, comme ici. Elle doit être présentée avec ses limites avant d’être complétée par des appels de modèles et des outils effectifs. Une réussite à ce niveau retire des défauts d’échange prévisibles ; elle ne mesure pas la qualité de génération. Chaque phase doit conserver ce qu’elle prouve afin que la décision finale n’additionne pas des preuves de nature incompatible.

Le propriétaire du service doit aussi savoir exploiter le système choisi : retrouver le rôle qui manque, couper une capacité et reprendre une mission sans doubler son effet. Ce coût de coordination reste pertinent après la démonstration. Une architecture utile doit permettre aux équipes de comprendre son résultat et ses refus, même lorsque les personnes qui ont conçu les prompts ne sont pas disponibles pour expliquer chaque trace.

Guides pour mission, outils, régression et limites

Conserver une autorité métier commune aux rôles

Le contrat de mission d’un agent support fixe sources, actions et conditions d’arrêt. Le contrat d’outil entre autorisation et exécution précise la frontière qui décide l’effet. La décomposition doit conserver ces décisions plutôt que les répartir implicitement entre opinions de rôles.

Le refus d’arguments d’outil invalides reste applicable à la proposition agrégée. Un coordinateur peut transmettre des arguments bien formés et pourtant hors cible ou hors droit. La recette garde donc proposition, ressource et contexte d’autorisation jusqu’à leur vérification, avec une reprise qui ne choisit pas un autre compte pour contourner le refus.

Comparer la version complète du système

Les évaluations de régression IA entre versions permettent de conserver population, juge et résultats appariés. Le changement d’orchestration doit être une version identifiable, comprenant rôles, prompts, outils et règles d’agrégation. Une amélioration de moyenne ne doit pas effacer une régression sur une restriction ou une mission critique.

Les limites d’exécution et les traces de reprise complètent cette comparaison. Elles permettent de retrouver la dépense engagée par chaque rôle et le motif d’un arrêt. Le dispositif doit rester lisible au niveau de la mission, car l’utilisateur attend un résultat utile. La réussite isolée d’un spécialiste ne suffit pas à rendre le service complet acceptable ou à justifier son ouverture.

Conclusion : justifier la décomposition par son résultat

Le nombre d’agents décrit une organisation, pas une qualité. La décomposition devient utile lorsqu’elle résout un défaut identifié avec un résultat prouvé, dans un budget et des droits conservés. Chaque échange ajoute des conditions sur origine, faits, révisions et complétude. Le service doit pouvoir les vérifier sans faire d’une synthèse ou d’un accord de modèles une autorisation métier.

Les deux workflows locaux rendent cette frontière observable : six missions communes, décisions identiques et huit mutations refusées. Leurs tailles JSON sont calculées, sans coût en tokens ou délai extrapolé. Aucun LLM n’est exécuté. La recette démontre la cohérence du contrôleur sur ces cas ; elle prépare la comparaison de modèles qui devra établir un éventuel gain de qualité, de couverture ou de temps.

La conception d’agents IA sur mesure doit relier cette preuve à la mission et à ses conditions d’exploitation. Une architecture peut rester simple ou introduire plusieurs rôles selon les dépendances effectivement observées. La décision conserve son propriétaire, ses défauts bloquants et sa reprise, au lieu de dépendre d’une préférence pour un schéma plus complexe.

Pour comparer un agent et plusieurs rôles, notre expertise IA sur mesure peut établir un même jeu de missions, des verdicts attendus et des contrats d’échange explicites. Les modèles réels doivent ensuite être évalués sur la qualité, les délais, les coûts et les reprises. Une séparation n’est retenue que si son apport au travail justifie les messages supplémentaires et les nouveaux cas de désaccord à traiter.