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. Tu vois chaque agent tourner en live dans son onglet, tu peux parler à n'importe lequel à tout moment, tu peux mettre l'équipe en pause, changer le workflow et reprendre. Ce n'est pas un remplacement des subagents Claude, tu peux totalement utiliser les deux. Un node d'équipe peut utiliser des subagents en interne.

Ça marche avec les 14 CLI d'agent supportés par AgentsRoom (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor et 10 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. Tu peux faire tourner une équipe avec Codex sur le node backend lourd et Haiku sur le node QA si c'est ce qui colle à ton budget et à ta 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 t'attend. Tu peux finaliser le run, faire un handoff manuel de plus, ou tout annuler. Pas de boucles infinies, pas de factures surprise du jour au lendemain.

Oui. L'équipe tourne dans un workspace unique et une branche unique (ou un worktree si tu utilises la feature Worktrees d'AgentsRoom). Chaque agent voit le travail du précédent à travers git. Le payload de handoff inclut un diff git contre le baseline du run pour que l'agent suivant sache exactement ce qui est nouveau.

Non. Teams fait partie d'AgentsRoom. Tu apportes tes propres clés provider (Claude, Codex, GitHub Copilot CLI, Cursor et 10 autres CLI d'agent) et tu paies seulement les tokens que tu consommes, 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 equipes projet vivent avec la room, synchronisees a votre compte et mises en cache dans {project}/.agentsroom/teams-cache.json (gitignore). Les equipes globales sont elles aussi synchronisees a votre compte : votre bibliotheque vous suit d'une machine a l'autre, avec ~/.agentsroom/teams/ comme cache hors-ligne. Les modeles fournis restent locaux : chaque machine les installe dans sa propre langue.

L'etat du run est persiste sur disque dans {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), avec ecritures atomiques et notes en append-only. Un run interrompu reprend au redemarrage de l'app : l'orchestrateur re-entre l'etape active, rouvre le terminal, et l'agent retrouve son contexte via les notes et les outils d'equipe. Un run dont l'equipe a ete supprimee est clos automatiquement au lieu de trainer indefiniment.

Oui. Chaque run est independant, identifie par son runId. Vous pouvez avoir trois equipes differentes en cours sur trois tickets du meme projet. A l'interieur d'un run, l'execution suit votre graphe : sequentielle par defaut, parallele la ou vous tracez des branches paralleles (par exemple QA et Securite qui relisent en meme temps), avec toujours une jonction deterministe.

Oui. Tracez deux liens sans condition depuis un node et les deux cibles tournent en branches paralleles, 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'editeur valide avant de vous laisser lancer. Quand toutes les branches ont termine, la jonction recoit un payload fusionne : resumes etiquetes par role, risques et pistes de test dedupliques, et flags fusionnes avec une regle fail-safe (un conflit booleen se resout a false).

Vous tapez une commande shell sur le node, par exemple npm test, et si besoin un nom de flag (checkPassed par defaut). Quand l'agent signale la fin de son etape, AgentsRoom execute la commande dans le workspace avec un plafond de cinq minutes. Code de sortie 0, le flag passe a true ; tout autre code, false, en ecrasant ce que l'agent a declare sur lui-meme. En cas d'echec, les derniers kilo-octets de sortie voyagent vers l'agent suivant : le retour en arriere atterrit avec la vraie stack trace, et le resultat s'affiche dans la timeline du run.

Oui. Chaque node peut epingler des skills de votre Skills Library, projet ou globale. L'agent recoit l'instruction de les charger avant de commencer l'etape : une checklist de review, un runbook de deploiement ou une procedure de test est appliquee a chaque run, au lieu de dependre de la memoire 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à.

Demande-toi sur quoi le run échouerait. S'il échouerait en perdant le fil, prends 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, prends 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, et il reste ensuite vivant jusqu'à la fin du run. Une équipe de quatre rôles ne brûle donc pas quatre sessions pour répondre à une question qui n'en concerne que deux, et un rôle sollicité au cycle trois est toujours le même agent que celui qui a répondu au cycle un.

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. Active-la quand tu veux 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 ton abonnement IA, ou sur un événement envoyé par GitHub, GitLab, Slack, Linear, Sentry ou ta CI. Le prompt part à la première étape de l'équipe, le run se passe sur ta machine comme n'importe quel autre, il atterrit dans l'historique du déclencheur, et une notification t'annonce qu'il a démarré. Les déclencheurs vivent dans le panneau Déclencheurs du projet, à côté des tâches planifiées.