Agent Teams.
Une vraie équipe tech, scriptée.

Les subagents Claude sont des délégations inline depuis une session Claude parente unique. Le parent décide quand appeler un subagent, le subagent tourne dans une fenêtre de contexte isolée, retourne un résultat, et le parent continue. AgentsRoom Teams est un cran au-dessus : chaque node est une session Claude Code top-level avec son propre terminal, son propre état et son propre scrollback. Vous voyez chaque agent tourner en live dans son onglet, vous pouvez parler à n'importe lequel à tout moment, vous pouvez mettre l'équipe en pause, changer le workflow et reprendre. Ce n'est pas un remplacement des subagents Claude, vous pouvez totalement utiliser les deux. Un node d'équipe peut utiliser des subagents en interne.

Ça marche avec les 17 CLI d'agent supportés par AgentsRoom (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor et 13 autres). Chaque node d'équipe choisit son propre provider et modèle. Les outils de coordination d'équipe basés sur MCP marchent à l'identique sur tous les providers parce qu'ils sont exposés via le standard Model Context Protocol. Vous pouvez faire tourner une équipe avec Codex sur le node backend lourd et Haiku sur le node QA si c'est ce qui colle à votre budget et à votre latence.

Un objet structuré qui voyage d'un agent au suivant. Champs : featureSummary (une description courte de ce qui vient d'être livré), changedFiles (git diff name-status), touchedAreas (UI, API, DB, config), risks (tout ce dont l'agent suivant doit se soucier), testHints (priorités pour le QA), flags (booléens comme qaPassed, utilisés par les edges conditionnels). L'agent appelle team_complete_step avec ce payload, le runner le valide côté serveur, l'agent suivant le reçoit comme contexte de départ.

Oui. Quand un node est ré-entré (cycle supérieur à 1), AgentsRoom ne spawn pas un nouvel agent. Il réutilise l'agent original du cycle 1, écrit le nouveau payload de handoff directement dans son terminal existant, et l'agent garde toute sa mémoire de session Claude des cycles précédents. C'est critique : un agent Dev qui sait déjà ce que le QA a flaggé la fois d'avant corrige le bug. Un agent Dev frais sans mémoire répèterait juste la même erreur.

La config d'équipe a une garde max-cycles, par défaut à 3. Quand le plafond est atteint, le run s'arrête avec un statut 'blocked' et vous affiche le compte rendu du dernier handoff : accordez un ou deux cycles de plus et l'équipe reprend exactement là où elle s'était arrêtée, finalise le run, ou annule tout. Pas de boucles infinies, pas de factures surprise du jour au lendemain.

Oui. Par défaut, l'équipe tourne dans un workspace unique et une branche unique (ou un worktree si vous utilisez la feature Worktrees d'AgentsRoom) : chaque agent voit le travail du précédent à travers git, et le payload de handoff inclut un diff git contre le baseline du run pour que l'agent suivant sache exactement ce qui est nouveau. Une étape peut aussi avoir son propre checkout jetable : cochez « Checkout dédié » sur l'étape et elle tourne dans un git worktree taillé sur un instantané du workspace du run, travail non commité compris, pour que les étapes parallèles qui mesurent ou relisent (une couverture de tests, une sonde) n'écrasent plus les fichiers les unes des autres. Rien de ce qui y est écrit n'atteint la branche du run, l'étape rapporte par son handoff et ses notes, et le checkout démarre sans dépendances installées. L'éditeur prévient quand deux étapes parallèles partagent le même arbre et que l'une d'elles peut écrire.

Non. Teams fait partie d'AgentsRoom. Vous apportez vos propres clés provider (Claude, Codex, GitHub Copilot CLI, Cursor et 13 autres CLI d'agent) et vous payez seulement les tokens que vous consommez, comme avec un agent unique. Faire tourner une équipe Dev vers QA sur un petit ticket coûte généralement la même chose qu'un agent Fullstack unique, parce que Haiku/Sonnet sur l'étape QA c'est pas cher.

Les équipes projet vivent avec la room, synchronisées à votre compte et mises en cache dans {project}/.agentsroom/teams-cache.json (gitignoré). Les équipes globales sont elles aussi synchronisées à votre compte : votre bibliothèque vous suit d'une machine à l'autre, avec ~/.agentsroom/teams/ comme cache hors-ligne. Les modèles fournis restent locaux : chaque machine les installe dans sa propre langue.

L'état du run est persisté sur disque dans {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), avec écritures atomiques et notes en append-only. Un run interrompu reprend au redémarrage de l'app : l'orchestrateur ré-entre l'étape active, rouvre le terminal, et l'agent retrouve son contexte via les notes et les outils d'équipe. Un run dont l'équipe a été supprimée est clos automatiquement au lieu de traîner indéfiniment.

Oui. Chaque run est indépendant, identifié par son runId. Vous pouvez avoir trois équipes différentes en cours sur trois tickets du même projet. À l'intérieur d'un run, l'exécution suit votre graphe : séquentielle par défaut, parallèle là où vous tracez des branches parallèles (par exemple QA et Sécurité qui relisent en même temps), avec toujours une jonction déterministe.

Oui. Tracez deux liens sans condition depuis un node et les deux cibles tournent en branches parallèles, chacune dans son propre agent et son propre terminal. Les branches font un node de profondeur et doivent converger vers un node de jonction commun, ce que l'éditeur valide avant de vous laisser lancer. Quand toutes les branches ont terminé, la jonction reçoit un payload fusionné : résumés étiquetés par rôle, risques et pistes de test dédupliqués, et flags fusionnés avec une règle fail-safe (un conflit booléen se résout à false).

Vous tapez une commande shell sur le node, par exemple npm test, et si besoin un nom de flag (checkPassed par défaut). Quand l'agent signale la fin de son étape, AgentsRoom exécute la commande dans le workspace avec un plafond de cinq minutes. Code de sortie 0, le flag passe à true ; tout autre code, false, en écrasant ce que l'agent a déclaré sur lui-même. En cas d'échec, les derniers kilo-octets de sortie voyagent vers l'agent suivant : le retour en arrière atterrit avec la vraie stack trace, et le résultat s'affiche dans la timeline du run.

Oui. Chaque node peut épingler des skills de votre Skills Library, projet ou globale. L'agent reçoit l'instruction de les charger avant de commencer l'étape : une checklist de review, un runbook de déploiement ou une procédure de test est appliquée à chaque run, au lieu de dépendre de la mémoire de l'agent.

Oui. L'éditeur exécute une série de contrôles de graphe et sépare les erreurs bloquantes des avertissements. Les erreurs arrêtent le run : nœud Start ou End manquant, connexions en double, deux connexions portant les mêmes conditions, une connexion dont les conditions se contredisent, un fan-out invalide. Les avertissements non : un nom de flag entouré d'espaces, une condition sur une connexion sortant de Start, un nœud dont toutes les connexions sortantes sont conditionnelles et où le run peut donc s'arrêter. Les deux sont listés dans un panneau de contrôles et les connexions fautives sont recolorées sur le canvas : vous corrigez le graphe avant de perdre un run dessus.

Non, et c'est volontaire. Tant qu'un run est vivant, la définition de l'équipe est gelée contre les écritures venant des outils MCP : nœuds, arêtes, nombre maximum de cycles, instructions d'étape, skills, commande de vérification, rôle, provider et modèle passent en lecture seule pour les agents, une skill chargée par le run ne peut pas non plus être réécrite, et le gel ne se contourne pas en supprimant puis recréant l'équipe. Un agent ne doit pas réécrire la règle qui le gouverne. Vous, depuis l'interface, continuez à tout modifier à tout moment.

Oui. L'application mobile peut démarrer une équipe sur un projet, affiche une bannière de run avec la progression de chaque étape, et donne accès au terminal de l'agent en cours. Le run lui-même s'exécute toujours sur votre poste, à travers les vraies CLI, exactement comme si vous l'aviez lancé depuis là.

Demandez-vous sur quoi le run échouerait. S'il échouerait en perdant le fil, prenez le relais : une seule session joue tous les rôles et ne se réexplique jamais une décision. S'il échouerait en étant d'accord avec lui-même, prenez l'équipe : les rôles tournent comme des agents séparés, donc celui qui relit le code n'est pas celui qui l'a écrit. Le relais est le mode par défaut parce que c'est déjà ce que font toutes les équipes construites avant l'existence du réglage, pas parce qu'il serait meilleur.

Non. Un coéquipier démarre la première fois qu'on a besoin de lui, soit parce que le graphe atteint son étape, soit parce qu'un autre agent lui écrit. Une équipe de quatre rôles ne brûle donc pas quatre sessions pour répondre à une question qui n'en concerne que deux. Quand une étape a passé la main et que le run ne peut plus y revenir, sa console est mise en veille pour libérer de la mémoire, et elle se réveille avec sa conversation intacte si quelqu'un lui écrit. Un rôle sollicité à nouveau lors d'un cycle suivant reste le même agent que celui qui a répondu avant, sauf si vous activez l'option d'équipe qui ferme la console de chaque étape quand elle passe la main : il repart alors de zéro.

Seulement de ce qu'il peut lire. Un coéquipier qui arrive en cours de run a sa propre session et aucun souvenir du travail, et c'est exactement pour ça que son avis vaut quelque chose. Il se met à jour via les notes partagées, la timeline du run et le diff git depuis le début du run, qu'il lit lui-même avec ses propres outils. Cette lecture est le coût du mode, et c'est la raison pour laquelle le mode relais existe toujours.

Oui, et c'est le comportement par défaut. Avec la conversation libre désactivée, un coéquipier ne peut écrire qu'aux rôles vers lesquels son nœud pointe dans le graphe, donc une porte de qualité ne peut pas être contournée en demandant à quelqu'un d'autre. Activez-la quand vous voulez une vraie équipe : chacun écrit à n'importe qui, dans n'importe quel sens, et à plusieurs à la fois. Dans les deux cas, le graphe démarre toujours le run et le termine toujours.

Oui. Un déclencheur peut pointer vers une équipe plutôt que vers un agent seul, donc le même pipeline tourne sans surveillance : sur un rythme de calendrier, sur la fenêtre de quota de votre abonnement IA, ou sur un événement envoyé par GitHub, GitLab, Slack, Linear, Sentry ou votre CI. Le prompt part à la première étape de l'équipe, le run se passe sur votre machine comme n'importe quel autre, il atterrit dans l'historique du déclencheur, et une notification vous annonce qu'il a démarré. Les déclencheurs vivent dans le panneau Déclencheurs du projet, à côté des tâches planifiées.

Il vous attend, parce que terminer un run commite, fusionne son worktree et ferme son ticket, et que la dernière étape peut encore renvoyer du travail. Si vous préférez ne pas revenir le chercher, activez Terminer après inactivité dans les réglages de l'équipe et choisissez un délai (30 minutes proposées, jusqu'à 24 heures) : une fois le run à End et aucune étape active pendant ce délai, AgentsRoom le termine et libère ses consoles. Comme personne n'a vérifié ce travail, son ticket va alors dans la colonne En revue si votre tableau l'affiche (dans Terminé sinon), avec une note qui indique que le run s'est terminé tout seul. Il n'annule jamais un run qui travaille encore ou qui attend votre réponse, et l'option est coupée par défaut.

Oui. Tirez des connexions conditionnelles depuis l'étape Wait for me, une par issue, par exemple approved = true vers Deploy et approved = false retour vers Dev. Quand le run s'y arrête, la boîte de réponse les liste sous Votre décision : celle que vous choisissez pose ses flags, le run prend cette connexion, et l'étape suivante sait que la décision vient de vous. Votre note devient facultative, et les mêmes choix sont proposés sur le téléphone.

Oui. Dans Réglages, Dynamic Island, Runs d'équipe, activez Afficher chaque run d’équipe comme une seule icône d’équipe. Chaque run prend alors une seule place, avec le blason de l'équipe et un point pour son état (rouge quand le run ou l'un de ses agents vous attend), et un clic ouvre la console qui a besoin de vous.