Faire cohabiter deux agents qui vous connaissent

Oui, à une condition qui n’a rien à voir avec leur nombre : il faut que leurs contextes ne se recouvrent pas. Et pour qu’ils coopèrent réellement, il faut que l’un des deux accepte de cesser d’être un collègue le temps de l’appel.

La situation est déjà courante et personne ne l’a décidée. Une entreprise se retrouve avec un agent généraliste fourni par sa plateforme bureautique, un agent métier installé par une équipe, parfois un troisième arrivé avec un outil. Aucun de ces choix n’est absurde pris séparément, et l’ensemble le devient si la question du contexte n’a jamais été posée.

Pourquoi « un agent, pas douze » n’interdit pas d’en avoir deux

Nous avons écrit qu’il vaut mieux un agent bien outillé que douze qui ne se parlent pas, et cette position est souvent lue comme une règle de nombre. Elle n’en est pas une, et la préciser est le point de départ de tout le reste.

Ce que nous reprochons aux douze agents n’est pas d’être douze, c’est que chacun prétend connaître votre entreprise. Douze installations, ce sont douze copies de vos règles, de vos clients et de votre historique, qui vieillissent chacune à sa vitesse. Le mauvais chiffre n’est pas le nombre d’agents, c’est le nombre d’endroits où votre contexte est recopié.

Reformulée ainsi, la règle autorise parfaitement deux agents, à la seule condition que leurs domaines de contexte soient disjoints et que la frontière soit écrite quelque part. Un agent qui connaît vos écritures comptables et un agent qui connaît vos consultants ne se gênent pas davantage que deux salariés dans deux services.

Où passe la frontière, concrètement

Pas sur les tâches, qui se chevauchent toujours, mais sur les faits. La question à poser pour chaque catégorie d’information est celle du propriétaire : lequel des deux agents a le droit d’écrire ceci, et lequel doit aller le lui demander ?

Prenez un client de votre société de conseil. Son adresse de facturation et son encours appartiennent au domaine financier. Ses préférences de profils, son historique de refus, le nom de la personne qui décide vraiment, appartiennent au domaine du staffing. Ce sont des faits sur la même entité, et ils ont deux propriétaires légitimes, ce qui est parfaitement tenable tant que chacun sait lequel des deux fait foi sur quoi.

L’exercice prend une réunion et il se fait par écrit. Trois colonnes suffisent : la catégorie de fait, l’agent propriétaire, et ce que fait l’autre quand il en a besoin. La troisième colonne n’a que deux réponses acceptables, il demande ou il s’en passe, et jamais il en garde une copie.

Ce qui arrive quand les deux connaissent le même client

C’est le seul scénario à éviter absolument, et il ne ressemble pas à une panne.

Le premier agent apprend en mars qu’un client refuse les profils sans habilitation. Le second l’apprend en juin, dans une conversation où quelqu’un a nuancé la règle. Trois mois plus tard, les deux répondent à la même question avec la même assurance et deux réponses différentes, et rien dans le système ne signale l’écart. La personne qui reçoit la mauvaise des deux n’a aucune raison de se méfier, puisque l’agent qui la lui donne est celui qu’elle utilise tous les jours.

Ce mode de défaillance est particulièrement pénible parce qu’il est silencieux, progressif, et qu’il empire précisément avec l’usage. Plus les deux agents travaillent, plus ils accumulent de faits, et plus la probabilité d’un désaccord non détecté augmente. C’est aussi la raison pour laquelle ce qu’un agent oublie compte autant que ce qu’il retient : une mémoire qui ne se purge pas est une mémoire qui finit par contredire une autre.

Se parler : ce que les protocoles permettent déjà

La partie technique est la plus avancée, et c’est ce qui trompe. Faire dialoguer deux agents ne pose plus de problème sérieux.

On invoque une capacité précise avec MCP, dont on connaît la forme du résultat à l’avance. On confie un but à un autre agent avec A2A, qui choisit lui-même ses étapes et peut demander des précisions en route, la découverte passant par une carte qui déclare ce qu’il sait faire. Nous avons détaillé cette distinction en écrivant que votre agent va sous-traiter à d’autres agents, et elle est le bon cadre pour penser une pile d’intégrations qui ne contient plus seulement des logiciels.

Du côté de la gouvernance, l’outillage arrive aussi. Microsoft a rendu disponible un plan de contrôle qui rassemble l’inventaire des agents, leurs permissions, leur comportement et leur coût au même endroit, ce qui est exactement l’inventaire qu’il faut avant d’écrire quoi que ce soit. Le protocole et le registre existent donc. Le problème est ailleurs.

Les trois questions que le protocole ne règle pas

Aucune n’est technique, et toutes se posent le jour où la chaîne produit un mauvais résultat.

Quelle mémoire fait foi ? Quand l’agent A demande à l’agent B ce qu’il sait d’un client, et que B répond quelque chose que A croyait savoir autrement, il faut une règle écrite d’avance. Sans elle, chaque agent garde sa version et vous venez de fabriquer la divergence que vous vouliez éviter, avec un protocole d’échange par-dessus.

Quelle règle de validation s’applique ? C’est le trou le plus courant. Un agent interne demande à un autre d’envoyer un message à un client, et l’action sortante se retrouve exécutée sans qu’aucun humain n’ait été sollicité, parce que chacun des deux considérait que la demande venait de l’intérieur. La règle qui tient est que la validation suit l’action, jamais l’agent : un envoi sortant reste un envoi sortant même quand personne n’a rien tapé.

Qui répond ? Un agent appelé rend une décision, pas une erreur, et il l’a prise avec des informations que vous ne verrez jamais. Quand le résultat est faux, la responsabilité est partagée entre deux éditeurs qui n’ont signé aucun contrat entre eux. C’est aussi pourquoi appliquer la même gouvernance à tous les agents ne suffit pas : ce qu’il faut gouverner ici est une chaîne, pas des unités.

La règle que nous appliquons

Elle tient en une phrase et elle résout les trois questions d’un coup : pour coopérer, l’un des deux agents cesse d’être un collègue et devient un consultant le temps de l’appel.

Concrètement, l’agent appelé reçoit une question, rend une réponse, et ne retient rien de l’échange. Il n’apprend pas votre client, il ne met pas à jour sa mémoire, il ne devient pas un second détenteur de votre contexte. Il est payé à la question, comme un expert externe, et c’est précisément ce qui le rend appelable autant qu’on veut.

L’agent appelant, lui, reste seul responsable. C’est lui qui détient le contexte, lui qui décide quoi faire de la réponse, lui qui applique la ligne de validation avant que quoi que ce soit ne sorte. La chaîne a donc un seul propriétaire, ce qui rend la question de la responsabilité triviale au lieu de la rendre insoluble.

La contrepartie est réelle et je préfère la nommer. Un consultant qui ne retient rien coûte plus cher, parce qu’il faut lui redonner le contexte à chaque appel, et ce contexte est refacturé à chaque fois. Nous acceptons ce surcoût, et c’est un arbitrage plutôt qu’une évidence.

Reste la question qui commande toutes les autres, celle de savoir si ces agents spécialisés ont un avenir face à des généralistes qui progressent tout seuls. Nous y avons répondu ailleurs, et la réponse tient à ce qu’un modèle ne transfère jamais : la responsabilité qu’un produit accepte de porter.