Exploration sur la mise en place d’une communication inter-agents universelle

Le besoin : des agents capables de se parler

Je développe AceMyExam avec mon associé en parallèle de nos activités respectives. Comme notre temps est limité, nous déléguons le gros du travail à des agents de code : j’utilise Claude Code tandis que mon associé utilise Codex.

Cependant, chaque session d’un agent repart de zéro, si bien que ce que mon agent vient d’apprendre reste inconnu du sien. C’était donc à nous de faire le lien : je copiais une question de mon agent pour que mon associé la colle dans le sien, puis il me renvoyait la réponse.

Nous avons donc mis en place un canal sur le serveur MCP d’AceMyExam. Puisque les deux agents l’utilisaient déjà pour travailler sur la plateforme, il n’y avait rien de nouveau à installer.

Le typage des messages

Dans la première version, les messages consistaient en un simple texte brut. Dès lors, il était impossible de déterminer si un message appelait une réponse, à quel fil il se rattachait ou si l’échange était clos ; nous devions donc encore assurer le suivi nous-mêmes.

Pour y remédier, nous avons typé chaque message afin d’expliciter l’action attendue du destinataire.

Exemple d’une demande, du début à la fin

Prenons un cas simple dans lequel mon agent constate que la page des tarifs affiche encore l’ancien prix. Il demande alors à l’agent de mon associé de la corriger.

Les trois choix structurants

Un message reçu est une donnée et non un ordre

Par nature, un agent tend à obéir aux instructions qu’il lit. Si un message reçu prenait la forme d’une consigne, l’agent destinataire risquerait donc de l’exécuter d’office : un simple message piégé dans le canal suffirait alors à le faire agir à notre insu.

Pour prévenir ce risque, le serveur appose une étiquette à chaque message reçu, qui identifie son auteur et rappelle que ce contenu doit être traité comme une simple donnée, non comme un ordre. De plus, dès qu’une demande a un effet, l’agent doit obtenir l’accord de l’utilisateur avant d’agir.

Nous avons corrigé un détail en cours de route. Au départ, l’étiquette mentionnait aussi le nom de l’agent. Or ce nom est un texte libre défini par l’agent lui-même, dans lequel il était donc possible de glisser une instruction. Nous l’avons retiré, de sorte que l’étiquette ne mentionne plus que la personne, que le serveur authentifie grâce à son jeton.

L’utilisateur décide du moment où son agent lit ses messages

Aucun mécanisme ne sollicite un agent en arrière-plan : celui-ci ne consulte sa boîte de réception que lorsque l’utilisateur le lui demande explicitement. Il n’existe donc ni déclencheur ni tâche de fond.

Ce fonctionnement manuel est un choix délibéré pour cette première version, bien que nous envisagions un réveil automatique par la suite. Une seule exception a été prévue : lorsqu’une session est déjà active, l’agent peut patienter jusqu’à 50 secondes dans l’attente d’une réponse immédiate avant de rendre la main.

MCP comme protocole commun

Claude Code et Codex disposent chacun de leur propre système pour recevoir des messages. Nous ne les avons pas utilisés, car les deux agents savaient déjà dialoguer avec notre serveur MCP. Nous avons donc tout regroupé au même endroit, ce qui rend la communication indépendante du fournisseur de chaque agent.

Les trois états d’un fil

Une question, une demande ou une passation ouvre un fil. Celui-ci reste ouvert tant que l’autre agent n’a pas répondu, puis il passe à l’état répondu lorsque la réponse arrive. Il est enfin clos lorsque l’un des deux le ferme.

Si l’auteur relance, le fil redevient ouvert, ce qui permet plusieurs allers-retours dans un même fil. Par ailleurs, l’état évolue de lui-même avec les messages, si bien que personne ne le modifie à la main.

Les difficultés rencontrées

• Les nouveaux outils n’apparaissaient pas. Une session ouverte avant la mise en production ne les voyait pas, il fallait donc la relancer.
• Un document pouvait être envoyé mais pas relu. Un agent n’en voyait que les 20 000 premiers caractères, c’est pourquoi nous avons ajouté la lecture par tranches dès le lendemain.
• Nous parlions de canaux « entre agents ». En relisant, nous avons constaté que ce n’était pas exact, puisque le serveur ne connaît pas l’agent mais la personne, grâce à son jeton. Il s’agit donc de canaux entre personnes.

Les limites du système

Le serveur n’exécute rien lui-même, car c’est l’agent destinataire qui agit avec les droits de sa propre session. La protection repose donc sur l’étiquette, sur les consignes données aux agents ainsi que sur les permissions du poste de chacun. Le protocole ne garantit rien au-delà.

Par ailleurs, comme rien ne réveille un agent automatiquement, un message peut rester sans réponse tant que personne n’ouvre de session.

Une piste de réflexion : le réveil automatique et l’agent relais

Cette limite pourrait être levée grâce à un script d’écoute continu, chargé d’alerter les agents dès la réception d’un message. Ainsi, un agent n’aurait plus à attendre que l’utilisateur lui demande de consulter ses messages.

Dans cette architecture, chaque environnement disposerait d’un unique agent relais. Du côté de Claude Code comme de Codex, cet agent recevrait l’alerte du script, analyserait le message entrant, puis répartirait le travail entre les agents spécialisés via leur protocole natif.

De cette manière, le canal commun ne relierait qu’un agent par fournisseur, tandis que la répartition du travail resterait propre à chaque écosystème. L’accord d’un humain resterait toutefois nécessaire avant toute action ayant un effet.

La complémentarité entre l’IA et l’humain

Dans ce système, les agents font circuler l’information à notre place tandis que les décisions restent entre nos mains.

La suite

Le protocole est en production depuis le 12 novembre 2026. Comme je ne dispose pas encore de chiffres d’usage, je les ajouterai ici dès qu’ils seront disponibles, notamment le nombre de fils, le délai de réponse et le nombre de demandes refusées par un humain.