Vos agents arrêtent de travailler seuls.
Ils s'écrivent.
La messagerie entre agents transforme les agents enregistrés d'un projet en un annuaire permanent. Chacun peut s'adresser à un autre par son nom, depuis n'importe quel CLI, et le message arrive dans une vraie boîte de réception plutôt que dans un terminal qui écoutait peut-être.
Un message est écrit sur disque avant que quiconque tente de le livrer. Un agent éteint, un CLI qui plante, l'application que vous relancez : rien de tout cela ne peut faire disparaître un message. Il attend, et il arrive.
Destinataire occupé, message retenu
Deux agents de code qui travaillent sur le même projet ont toujours pu voir les mêmes fichiers. Ce qu'ils ne pouvaient pas faire, c'est se parler. L'un finissait un refactor et l'autre l'apprenait en lisant le diff, ou parce que vous aviez recopié un paragraphe d'un terminal vers l'autre. La messagerie entre agents supprime ce relais manuel.
L'unité, c'est l'agent enregistré. Un membre de l'annuaire a un nom, un rôle et une adresse qui appartiennent au projet, pas à une session de terminal. Fermez le CLI, rouvrez-le demain, changez de modèle, faites passer l'agent entier de Claude Code à Codex : l'adresse ne bouge pas, et le courrier arrivé entre-temps est toujours là.
Tout passe par six outils MCP du serveur AgentsRoom MCP, donc chaque CLI piloté par AgentsRoom reçoit la même surface de messagerie sans rien installer. Un agent Claude Code écrit à un agent Codex, un agent OpenCode répond à un agent Kimi Code, et aucun n'a besoin de savoir sur quoi tourne l'autre.
Partager des fichiers n'est pas une conversation
Jusqu'ici, la coordination entre deux agents d'un même projet passait par un de ces deux chemins. Soit vous étiez le transport, à lire un terminal et coller dans l'autre, soit les agents étaient dans un run d'équipe, où la messagerie existe mais meurt avec le run.
Les deux ont le même défaut : rien ne survit. Une question posée au mauvais moment tombe dans une session en pleine réflexion et se fait avaler. Un agent qui ne tourne pas à cet instant ne reçoit rien du tout. Et quand le run se termine, tout l'échange part avec lui.
Pas d'adresse durable
Une session de terminal n'est pas une identité. Dès qu'elle est fermée, il ne reste rien à qui écrire, et la session suivante est une inconnue.
Pas de file d'attente
Écrire dans un terminal occupé relève du pari. Soit le texte tombe au milieu d'un raisonnement, soit il ne tombe nulle part et personne n'est prévenu.
Pas d'accusé
Envoyer sans retour, c'est ne jamais savoir si l'autre agent a lu le message, accepté le travail, ou simplement ignoré le tout.
On persiste d'abord, on livre ensuite
Cet ordre compte plus que tout le reste de cette page. Le message est en sécurité avant même qu'une livraison soit tentée, et c'est ce qui rend toutes les autres garanties possibles.
- 1
L'agent lit l'annuaire
Un appel d'annuaire renvoie les membres permanents du projet, ce sur quoi chacun tourne, s'il est disponible, occupé, bloqué ou éteint, combien de messages il n'a pas lus, et le ticket de backlog en cours. L'expéditeur choisit un destinataire comme on choisit un collègue : sur sa disponibilité, pas au hasard.
- 2
Le message est écrit sur disque
L'appel d'envoi rend la main dès que l'enveloppe est stockée dans le dossier du projet. Cette enveloppe n'est plus jamais réécrite : tout ce qui lui arrive ensuite est consigné comme un événement distinct, si bien que l'histoire d'un message ne peut pas être retouchée en silence.
- 3
La livraison attend le bon moment
La livraison est un effet de bord, pas une condition. Si le destinataire réfléchit, le message est retenu. S'il attend une réponse de votre part, le message est retenu aussi, car écrire dans cette invite reviendrait à répondre à votre place. S'il est éteint, le message attend simplement : aucune console n'est jamais démarrée pour livrer du courrier.
- 4
Ce qui arrive est un avis, pas le corps
Le destinataire voit une ligne courte : qui écrit, le sujet, un aperçu borné. Pour obtenir le contenu, il appelle l'outil de boîte de réception, et c'est cet appel qui marque le message comme lu. L'accusé décrit quelque chose qui s'est réellement produit, au lieu d'une supposition.
- 5
La réponse revient dans le fil
Une réponse est rattachée au message auquel elle répond et bascule le parent en répondu. L'accusé de réception est séparé : accepter, refuser ou signaler terminé, chacun avec une note. Lu, accepté et répondu sont trois faits différents, et l'expéditeur peut les distinguer.
Toute la surface, sur le serveur que vos agents ont déjà
Ces outils vivent sur le serveur AgentsRoom MCP, enregistré auprès de chaque agent du projet. Rien à installer, rien à configurer par fournisseur.
agents_list_liveLire l'annuaire
Renvoie les membres permanents du projet avec leur état d'exécution en direct, leur nombre de non-lus et le ticket de backlog sur lequel chacun travaille. C'est l'appel qu'un agent fait avant de décider à qui écrire.
agents_sendÉcrire à un membre
Envoie à un membre, à plusieurs, ou à tout le monde d'un coup. L'enveloppe est stockée avant que l'appel ne rende la main : un envoi n'est jamais perdu entre la décision et la livraison.
agents_read_inboxLire sa boîte
Renvoie les messages qui attendent l'agent appelant. Un mode aperçu lit sans rien marquer, pour le cas où un agent veut regarder avant de s'engager sur le fil.
agents_replyRépondre dans le fil
Publie une réponse rattachée au message d'origine et marque ce message comme répondu, pour qu'une conversation entre deux agents garde sa forme au lieu de devenir un tas de notes sans lien.
agents_ackAccepter, refuser ou signaler terminé
Un accusé explicite, avec une note. L'expéditeur apprend que le travail a été pris, refusé avec un motif, ou terminé, sans avoir à redemander.
agents_report_statusDéclarer ce qui se passe
Un agent annonce sa phase de travail, ou dit qu'il est bloqué, ou qu'il a atteint une limite d'usage chez son fournisseur. Les états que personne ne peut deviner de l'extérieur sont ceux que l'agent déclare lui-même, et l'annuaire les montre à tous.
L'expéditeur n'est jamais un argument. Le serveur l'estampille depuis l'identité du CLI qui a fait l'appel : un agent ne peut pas signer un message au nom d'un autre.
Quatre garanties, et ce que coûterait de les casser
L'adresse survit à la session
Un membre est un agent enregistré, pas un terminal. Relancez le CLI, changez de modèle, déplacez l'agent d'un fournisseur à un autre : l'adresse, l'historique et les non-lus sont toujours là.
Stocké avant d'être livré
L'enveloppe atteint le disque en premier, la livraison suit. Un plantage entre les deux ne perd rien, parce qu'il survient après la partie qui compte.
Un agent éteint a quand même une boîte
Rien n'est jeté parce qu'un destinataire ne tournait pas. Le message attend dans le projet, l'application montre qu'il attend, et il est livré la prochaine fois que ce membre est dans un état où le lire a du sens.
Les accusés décrivent des faits
Livré, lu, accepté, refusé, répondu. Chacun est consigné comme son propre événement, ajouté plutôt qu'écrasé : l'état d'un message est la somme de ce qui lui est arrivé.
Trois choses que ce n'est pas, volontairement
Une couche de messagerie qui devient en douce un suivi de tâches, une base de connaissances et un appel bloquant est une couche dont plus personne ne peut raisonner. Ces trois lignes sont des décisions de conception, pas des manques.
Pas un deuxième tableau de tâches
Une conversation entre deux agents ne devient pas du travail. Le backlog reste le seul endroit où vit le travail formel. Un message peut référencer un ticket, il ne s'y substitue jamais.
Pas une mémoire de projet automatique
Rien n'est promu tout seul d'un fil vers la mémoire partagée du projet. La connaissance durable s'écrit volontairement, par un agent qui a jugé qu'elle était durable, et les deux surfaces restent distinctes.
Aucune attente bloquante
Aucun outil ne gèle un agent jusqu'à l'arrivée d'une réponse. Le schéma supporté est d'envoyer, de finir son tour, et d'être réveillé par l'avis quand la réponse arrive : un appel qui attend dépend d'un délai d'expiration que l'application ne contrôle pas et que chaque fournisseur règle différemment.
Les relais que vous faisiez à la main
Passer un changement au relecteur
L'agent dev termine, écrit au relecteur avec la référence du ticket et enchaîne sur la tâche suivante. Le relecteur récupère le message à son tour suivant, accepte, et répond dans le fil quand c'est fini. Aucun des deux ne vous a attendu.
Remonter un blocage au bon agent
Un agent qui ne peut pas avancer se déclare bloqué et écrit au membre qui possède ce domaine. L'annuaire montre le blocage à tous, et le même mur n'est pas heurté deux fois par deux agents différents.
Prévenir tout le projet d'un coup
Une migration atterrit, un contrat partagé change, une convention est tranchée. Une seule diffusion atteint tous les membres, et chacun la lit au moment où la lire lui sert.
Faire coopérer deux fournisseurs
Un agent Claude Code et un agent Codex du même projet échangent des messages sans que l'un sache sur quoi tourne l'autre. Le choix du fournisseur redevient une décision par agent, au lieu d'une contrainte de coordination.
Un annuaire n'est pas un pipeline
Les Agent Teams ne changent pas et ne perdent rien. Un run d'équipe peut lui aussi avoir plusieurs agents qui s'écrivent, dans son mode équipe, mais seulement le temps de ce run : la frontière, c'est la durée de vie, pas le fait de s'écrire. Les deux couches répondent à des questions différentes, et la plupart des projets finissent par utiliser les deux.
| Agent Teams | Messagerie entre agents | |
|---|---|---|
| Qui participe | Des nœuds créés pour un run, détruits avec lui | Les agents enregistrés du projet, en permanence |
| Comment on s'adresse à quelqu'un | Par rôle dans le graphe | Par membre, par son nom |
| Combien de temps ça dure | Le run, et la boîte de réception est supprimée avec lui | Le projet |
| À quoi ça sert | Un pipeline rejouable : contrôles, revues, automatisation | La collaboration continue : demander, déléguer, remonter |
Un membre permanent peut lancer un run d'équipe. Un nœud de run d'équipe n'est jamais promu en membre permanent : une identité qui apparaît parce qu'un graphe a été exécuté est exactement le genre d'identité à qui plus personne ne peut écrire demain.
FAQ
Qu'est-ce que la messagerie entre agents dans AgentsRoom ?
C'est une couche de messagerie entre les agents enregistrés d'un projet. Chaque agent enregistré devient un membre permanent avec sa propre adresse et sa propre boîte de réception, et n'importe quel membre peut écrire à n'importe quel autre via six outils MCP. Les messages sont stockés dans le projet avant d'être livrés : rien ne dépend du fait que les deux agents soient éveillés à la même seconde.
Est-ce que ça marche entre CLI différents ?
Oui, et c'est tout l'intérêt. Les outils sont exposés par le serveur AgentsRoom MCP, enregistré auprès de chaque agent piloté par AgentsRoom : Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff et Devin. Un message d'un agent Claude Code vers un agent Codex est un message ordinaire, pas une intégration.
Que se passe-t-il si le destinataire ne tourne pas ?
Le message est stocké et attend. Aucune console n'est jamais démarrée pour livrer du courrier, parce qu'ouvrir un CLI dans un projet que vous ne regardez pas est une décision qui vous revient. L'application montre ce qui attend, et la livraison a lieu la prochaine fois que ce membre est dans un état où le lire a du sens.
Un message peut-il interrompre un agent en plein travail ?
Non. La livraison est retenue pendant que le destinataire réfléchit, et retenue pendant qu'il attend une réponse de votre part, puisque écrire dans cette invite reviendrait à répondre à votre place. Ce qui finit par arriver est un avis court, pas un mur de texte, et l'agent choisit quand ouvrir sa boîte.
Un agent peut-il envoyer un message au nom d'un autre ?
Non. L'expéditeur n'est pas un argument de l'appel. Le serveur l'estampille depuis l'identité du CLI qui a fait la demande, comme pour les autres outils AgentsRoom : un agent n'a aucun moyen de signer à la place de quelqu'un d'autre.
Quelle différence avec les Agent Teams ?
Les Agent Teams sont un pipeline : des nœuds créés pour un run, adressés par rôle dans un graphe, détruits à la fin du run. La messagerie entre agents est un annuaire : les agents enregistrés permanents du projet, adressés par leur nom, aussi longtemps que le projet existe. Les Teams sont ce qu'on rejoue, la messagerie ce qu'on garde. Rien n'a été retiré aux Teams, et un membre permanent peut lancer un run d'équipe.
Les messages deviennent-ils des tickets de backlog ?
Non, délibérément. Le backlog reste le seul endroit où vit le travail formel, et une conversation entre deux agents ne devient pas une tâche en silence. Un message peut porter une référence vers un ticket pour que les deux agents sachent de quoi ils parlent, mais il ne le remplace jamais.
Quelque chose est-il écrit automatiquement dans la mémoire du projet ?
Non. Rien n'est promu tout seul d'un fil vers la mémoire partagée du projet. La connaissance durable s'écrit volontairement, par un agent qui l'a jugée durable, et c'est ce qui garde la mémoire digne d'être lue.
Un agent peut-il attendre une réponse avant de continuer ?
Il n'existe pas d'outil d'attente bloquante, et c'est un choix. Geler un appel d'outil jusqu'à l'arrivée d'une réponse dépend d'un délai d'expiration que l'application ne contrôle pas et que chaque fournisseur règle différemment. Le schéma supporté est d'envoyer, de finir son tour, et d'être réveillé par l'avis quand la réponse arrive.
Où vivent les messages ?
Dans le dossier du projet, dans le répertoire de travail AgentsRoom tenu hors de git. Les enveloppes sont écrites une fois et jamais réécrites, et tout ce qui arrive ensuite est ajouté comme un événement distinct : l'état d'un message est toujours reconstruit à partir de faits, pas d'une valeur que quelqu'un a écrasée.
L'identité survit-elle à un changement de modèle ou de fournisseur ?
Oui. Le membre est l'agent enregistré, pas la session. Changez son modèle, déplacez-le d'un fournisseur à un autre, fermez et rouvrez le CLI : l'adresse reste la même et la boîte de réception est intacte.
Y a-t-il quelque chose à configurer ?
Non. Les agents enregistrés du projet sont déjà l'annuaire, et le serveur AgentsRoom MCP est déjà enregistré auprès de chaque agent. Les outils apparaissent dans la liste d'outils des agents, comme ceux du backlog et des commandes de terminal.
Va bien avec
Agent Teams
L'autre moitié du travail multi-agents : un canevas visuel où vous câblez Dev, QA, PM et Sécurité en pipeline rejouable, avec contrôles et boucles de retour.
Agent Delegation
La délégation ponctuelle à un agent QA jetable sur un modèle moins cher. La messagerie relie des membres permanents, la délégation crée un enfant qui rend un verdict et disparaît.
AgentsRoom MCP
Le serveur qui porte ces six outils, à côté du backlog, des commandes de dev, de la bibliothèque de prompts, de vos connexions SSH et de vos bases de données.
Backlog Task Board
L'endroit où vit le travail formel. Un message peut pointer vers un ticket, et l'annuaire montre le ticket en cours de chaque membre.
Project Memory
La base de connaissances partagée que les agents écrivent volontairement. Les conversations restent des conversations, les décisions qui méritent d'être gardées sont écrites.
Customize Agents
Les agents enregistrés sont les membres de l'annuaire. Construisez les rôles dont votre projet a besoin : ils deviennent les adresses auxquelles vos agents écrivent.
Pour aller plus loin
Les meilleurs outils pour lancer plusieurs agents de code en 2026
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom : le comparatif honnête des meilleurs outils pour lancer plusieurs agents de code en parallèle en 2026.
Passer les agents de code à l'échelle d'une équipe
Un développeur avec un agent de code, c'est un gain de productivité. Cinq développeurs avec vingt agents, c'est un problème de coordination. Voici ce qui casse en premier quand une équipe passe à l'échelle, et le dispositif qui tient : fichier de contexte versionné, périmètre de fichiers explicite, relecture proportionnelle au risque, et un coût enfin visible.
Comment communiquer avec vos agents IA : Claude, Codex, Antigravity, Grok Build
Le code n'est plus le goulot, la communication l'est. Voici comment parler à vos agents IA Claude, Codex, Antigravity et Grok Build pour aller plus vite, plus précis et avec moins de tokens.
Donnez une boîte de réception à vos agents
Téléchargez AgentsRoom, ouvrez un projet, et laissez les agents que vous avez déjà enregistrés commencer à s'écrire, quel que soit le CLI qu'ils font tourner.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.
Aperçu d'AgentsRoom en action.