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 sept 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, et un réglage permet de démarrer sa console pour lui : désactivé par défaut, l'agent revient alors en arrière-plan et lit sa boîte de réception avant toute chose.
- 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_message_statusVérifier avant de renvoyer
Rend l'état d'un message envoyé pour chaque destinataire : en file, remis, lu, accepté, refusé ou répondu, avec l'heure et la raison. Un silence a deux causes opposées, pas encore remis ou lu puis volontairement laissé de côté, et seul cet outil les distingue.
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.
Diffuser un message à tous les agents ouverts
Un mégaphone dans la colonne des agents. Vous tapez la consigne une fois et tous les agents dont la console est ouverte la reçoivent, quelle que soit la CLI de chacun : Claude Code, Codex, Copilot CLI, OpenCode, Antigravity, Aider et les autres.
Un bouton, toutes les consoles ouvertes
Le mégaphone est dans la barre d'outils des agents, à côté de la gomme de nettoyage. Il n'apparaît que si une session est ouverte, et il annonce le nombre : envoyer aux 3 agents ouverts. Aucun mode à activer, aucune cible à retenir.
Des destinataires que vous pouvez retirer
Chaque agent ouvert arrive présélectionné sous forme de pastille, avec un point d'état en direct : libre, au travail, vous attend. Décochez les deux que vous préférez ne pas couper en plein tour, puis envoyez aux autres.
Un rapport, pas un « Envoyé »
Cinq destinataires, c'est cinq issues : vous obtenez le compte séparé des remis, des mis en file et des échecs. Une diffusion qui répond « Envoyé » par-dessus deux refus vous laisse croire que toute la salle a été prévenue.
Personne ne croit la tâche pour lui seul
Chaque copie porte un en-tête qui nomme les autres destinataires et interdit à l'agent de relayer le message. Sans cette ligne, cinq agents recevant la même consigne démarrent chacun le même travail, ou se mettent à s'écrire entre eux à son sujet.
La diffusion ne démarre jamais une console. Les agents ouverts sont la liste des destinataires, pas un point de départ : un agent sans session en cours n'est tout simplement pas destinataire, donc rien ne réveille dix CLI dans votre dos ni ne consomme dix quotas. Un agent dont la CLI démarre encore garde le message dans sa file et le reçoit quelques secondes plus tard.
C'est votre envoi, pas celui des agents. Il écrit directement dans chaque console, exactement comme si vous l'aviez tapé vous-même. Le trafic entre agents reste sur agents_send et sa boîte persistante, volontairement limitée en débit pour qu'une chaîne d'agents qui se relaient ne se transforme pas en boucle de messages.
Ça marche aussi depuis le téléphone. Le compagnon mobile AgentsRoom a le même mégaphone au-dessus de la liste des agents : les agents ouverts de la salle arrivent présélectionnés, et la diffusion s'exécute toujours sur votre poste, donc l'en-tête, la mise en file d'un agent dont le CLI démarre encore et le rapport par destinataire sont identiques à ceux de la machine.
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.
Le matin où un agent a détruit le travail de cinq collègues
Le 7 septembre 2026 à 9 h 25, un agent qui travaillait sur AgentsRoom lui-même a lancé une seule commande git sur 109 fichiers qu'il prenait pour les restes d'un script qu'il venait d'exécuter. Ce n'étaient pas des restes. C'étaient les modifications non commitées de cinq autres agents travaillant dans la même copie de travail, jamais passées en staged, jamais mises en stash : git n'avait plus rien à rendre.
Personne ne surveillait ce terminal. Ce qui s'est passé dans la minute suivante, c'est ce dont cette couche de messagerie est responsable.
- 01
Il s'est signalé lui-même
L'agent a ouvert sa réponse par les dégâts plutôt que par le ticket qu'il venait de finir : la commande qu'il avait lancée, les 109 fichiers, et la règle du projet qu'il avait lue puis enfreinte une heure plus tôt.
- 02
Il a écrit ce qui était perdu
La liste complète des fichiers détruits est partie sur disque en premier, pour que la perte cesse d'être un vague « quelque chose a été écrasé » et devienne un ensemble de chemins sur lesquels quelqu'un pouvait agir.
- 03
Il a écrit aux cinq, un par un
Chaque agent touché a reçu son propre message par agents_send, avec sa propre liste de fichiers. Pas une diffusion générale : cinq messages nominatifs, cinq listes différentes, chacune arrivant dans la boîte de réception de l'agent qui avait perdu ce travail-là.
- 04
Deux avaient refait leur travail avant que quiconque lise le rapport
Ils étaient en pleine session, le message les y a rejoints, et ils ont réécrit ce qu'ils avaient perdu. L'agent qui ne tournait pas a récupéré sa liste au démarrage suivant, parce que le message avait été stocké et pas seulement crié.
Rien ici n'a empêché l'erreur, et aucune couche de messagerie ne l'empêchera jamais. Ce qui a changé, c'est que les cinq autres agents l'ont appris de celui qui l'avait causée, en quelques minutes, avec la liste exacte de ce qu'ils avaient à refaire. Quand plusieurs agents partagent un même dépôt, c'est toute la distance entre un incident et un incident silencieux.
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 sept 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, Devin et Cursor. 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. Par défaut, aucune console n'est 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. Activez « Un message peut démarrer son destinataire » dans les réglages et l'application ouvre la console de cet agent en arrière-plan, sur sa conversation précédente s'il y en a une, et l'agent lit sa boîte de réception avant de vous demander quoi que ce soit. Dans les deux cas, l'application montre ce qui attend.
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.
Comment envoyer un seul message à tous mes agents IA d'un coup ?
Ouvrez le projet, cliquez sur le mégaphone dans la barre d'outils des agents, tapez le message et envoyez. Tous les agents dont la console est ouverte le reçoivent. Vous pouvez décocher n'importe quel destinataire avant l'envoi, et vous obtenez ensuite un rapport agent par agent plutôt qu'une simple confirmation. Cela marche pareil que vos agents tournent sur Claude Code, Codex ou toute autre CLI prise en charge.
Une diffusion démarre-t-elle les agents qui ne tournent pas ?
Non. Seuls les agents dont la console est ouverte sont destinataires : démarrer dix CLI que vous ne regardiez pas dépenserait dix quotas pour une seule annonce. Un agent dont la CLI est encore en train de démarrer n'est pas perdu pour autant, sa copie attend dans la file et part dès qu'il peut la prendre.
Peut-on désactiver la messagerie entre agents ?
Oui, avec un seul interrupteur dans les réglages de l’application. Désactivée, aucun agent ne peut écrire à un autre et rien de ce qui attend n’est écrit dans une console. Rien n’est supprimé : la réactiver reprend exactement là où on s’était arrêté, et vous pouvez toujours écrire vous-même à vos agents depuis le panneau Organisation. Il existe aussi un contrôle plus fin sur la ligne de chaque membre, qui met cet agent-là en pause dans les deux sens.
Un agent peut-il écrire à un agent d'un autre projet ?
Oui, à condition que les deux projets appartiennent à votre compte et que l'autre projet soit ouvert dans l'application desktop. Deux des sept outils acceptent un argument project facultatif : agents_list_live liste les agents de cet autre projet, et agents_send écrit à l'un d'eux. Le cas typique : un agent trouve un bug dans une bibliothèque partagée et prévient l'agent qui la maintient, au lieu d'ouvrir une console là-bas ou de créer un ticket en double. Le message est stocké dans le projet du destinataire, celui-ci voit qui a écrit et depuis quel projet, et la réponse revient dans la boîte de réception de l'expéditeur. Les mêmes limites de débit et la même pause s'appliquent, et une diffusion à tout le monde est refusée d'un projet à l'autre.
Un agent peut-il écrire à tout un projet plutôt qu'à l'un de ses agents ?
Oui. Chaque projet a sa propre boîte de réception : agents_send avec le destinataire "inbox" écrit au projet lui-même, et avec l'argument project il atteint un autre projet de votre compte. C'est l'adresse pour le cas où l'expéditeur ne sait pas quel agent, là-bas, s'occupe du sujet. N'importe quel agent de ce projet peut lire la demande, la prendre en charge (un seul peut le faire, le travail n'est donc jamais fait deux fois), la refuser avec une raison ou y répondre, et la réponse revient dans la boîte de l'expéditeur. La demande est annoncée au coordinateur du projet si vous en avez désigné un ; sinon elle vous attend dans un encadré en haut de la liste d'agents, où un clic la confie à un agent, lance un nouvel agent dessus ou la refuse.
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 sept 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.