Agent Teams.
Une vraie équipe tech, scriptée.
AgentsRoom Teams enchaîne tes agents IA de code comme une vraie équipe d'ingénieurs. Un Fullstack Dev livre la feature, un QA Engineer la valide, un PM la signe. Chaque rôle est scripté, le workflow est visuel, et chaque handoff transporte le résumé de feature, le diff, les risques et les pistes de test. Fini l'agent unique qui fait tout mal.
Construis ton équipe dev IA de rêve sur un canvas visuel, exactement comme un workflow n8n. Edges conditionnels, boucles de feedback, retries, garde max-cycles. Sauvegarde une fois, lance sur chaque ticket, regarde tes agents se passer le relais comme des seniors.
AgentsRoom Teams : éditeur visuel de workflow multi-agents, handoff automatique entre agents Claude Code, boucle de feedback Dev vers QA, communication inter-agents via MCP.
Agent Teams est la réponse d'AgentsRoom à une vérité brutale sur les agents IA de code : un agent unique qui essaie de tout faire finit par tout faire mal. L'agent Fullstack qui code, teste, review, déploie et écrit la spec en même temps oublie la moitié de ses instructions en cours de route. La bonne réponse, celle utilisée par toute équipe logicielle sérieuse au monde, c'est de découper le travail en rôles. Un développeur code. Un QA Engineer valide. Un product manager signe. Un security reviewer audite. Chaque rôle a son propre contexte, son propre focus, son propre outillage.
C'est exactement ce qu'apporte Agent Teams à AgentsRoom. Tu poses des nodes sur un canvas infini (basé sur React Flow, le même moteur que n8n, Make, Retool et Pipedream), chaque node est un agent Claude Code, Codex, OpenCode, Gemini CLI ou Aider assigné à un rôle spécifique, et tu les câbles entre eux. Lance l'équipe sur un ticket de ton backlog, ou attache-la à n'importe quel nouveau spawn d'agent. AgentsRoom orchestre la chaîne : spawn du premier agent, attente du handoff, résumé du travail, spawn de l'agent suivant avec ce résumé en contexte d'entrée, et on recommence jusqu'au node de fin.
D'autres outils essaient de faire ça avec un super-agent unique et des prompts malins. On a essayé, ça ne marche pas au-delà de trois étapes. Les rôles dérivent, le contexte se perd, l'agent oublie ce qu'il devait vérifier. Agent Teams traite les agents comme de vrais coéquipiers : chacun reçoit une session propre, un system prompt focalisé, un payload de handoff structuré, et un scratchpad partagé pour parler aux autres. C'est le workflow d'équipe dev IA que tu veux vraiment.
Éditeur AgentsRoom Teams : pose des nodes pour chaque rôle, câble-les, ajoute des conditions, sauvegarde l'équipe, lance-la sur n'importe quel ticket.
Une orchestration multi-agents qui passe vraiment à l'échelle
Chaque node sur le canvas est un agent. Tu choisis son rôle (Fullstack, Frontend, Backend, QA, Security, DevOps, PM, Architect, Mobile, Marketing, Git, SEO, Localization, ou n'importe quel rôle custom que tu as créé), son modèle (Opus, Sonnet, Haiku, GPT-5, o3, Gemini Pro, etc.), son mode de handoff (auto via Stop hook, ou manuel via un bouton) et quelques lignes d'instructions spécifiques à l'étape. C'est tout. Pas de cérémonie de prompt engineering, pas de fichier YAML à écrire.
Les edges connectent les nodes. Un edge simple veut dire : quand le premier agent finit son étape, passe la main au suivant. Un edge conditionnel porte un check de flag, par exemple qaPassed equals true. L'agent QA pose ce flag dans son payload de handoff, le runner choisit l'edge qui correspond. C'est comme ça qu'on construit des boucles de feedback : QA finit, qaPassed equals false, l'edge renvoie au Dev avec les pistes de test et les risques. Dev corrige, fait le handoff. Boucle jusqu'à ce que le QA passe ou que la garde max-cycles déclenche.
La communication inter-agents est robuste par design. AgentsRoom embarque un serveur MCP dédié (agentsroom-team) qui donne à chaque agent du run un set d'outils : lire le contexte de l'équipe, lire le scratchpad partagé NOTES.md, poster une note pour les coéquipiers, envoyer une question à un autre rôle, lire l'inbox, lire la timeline, lire le diff git contre le baseline du run, et compléter l'étape avec un payload structuré. Ces outils sont réinjectés dans la session Claude à chaque tour, donc ils survivent à la compaction de contexte. Même après un /compact ou un /clear, l'agent voit toujours ses outils d'équipe.
En plus, un hook UserPromptSubmit rappelle à l'agent les nouvelles notes des coéquipiers avant chaque message utilisateur. Un fichier NOTES.md dans le workspace est en append-only et survit aux crashs, redémarrages et reboots Mac. Un schéma de payload de handoff validé côté serveur empêche les agents de faire des handoffs vides ou pourris. C'est la partie que la plupart des démos multi-agents passent en silence, et c'est la raison pour laquelle la plupart s'effondrent au cycle 3.
Tout ce qu'il faut pour faire tourner une vraie équipe d'ingénieurs IA
Workflow visuel, vrai handoff, vraies boucles de feedback, vraie communication inter-agents. Conçu pour livrer une feature en un ping Slack au lieu de cinquante.
Canvas de workflow visuel
Canvas zoomable infini propulsé par React Flow, le même moteur que n8n, Retool, Pipedream et Make. Pose des nodes, connecte-les, sauvegarde l'équipe. Pas de code, pas de YAML.
14 rôles d'agent intégrés
Fullstack, Frontend, Backend, DevOps, QA, Security, PM, Architect, Mobile, Marketing, Git Expert, SEO, i18n. Plus n'importe quel rôle custom déjà sauvegardé sur ton projet.
Modèle et prompt par node
Chaque node choisit son provider, son modèle et ses instructions d'étape. Utilise Opus pour l'Architect, Haiku pour le QA, Codex pour le backend lourd, Gemini pour le frontend pas cher. Mix and match.
Handoff automatique
Quand un agent appelle team_complete_step, AgentsRoom construit le payload de handoff (résumé de feature, fichiers changés, risques, pistes de test, flags) et spawn le node suivant avec ce payload comme contexte de départ.
Option de handoff manuel
Tu préfères valider chaque étape ? Passe le node en mode manuel. L'agent attend, tu cliques sur 'Hand off' quand tu es content du résultat. Le meilleur des deux mondes.
Edges conditionnels
Chaque edge peut porter un check de flag (par exemple qaPassed equals true). Construis des branches : si QA passe, va au PM, sinon repars en boucle vers Dev. Vraie logique de workflow, pas de scripting.
Boucles de feedback
Dev vers QA vers Dev vers QA. Quand le QA renvoie le ticket, l'agent Dev original est réutilisé avec la mémoire complète du cycle précédent, donc il corrige vraiment la régression au lieu de repartir de zéro.
Garde max-cycles
Plafond configurable (3 par défaut). Évite les boucles infinies QA-rejette-Dev. Quand le plafond est atteint, le run s'arrête sur awaiting-finalization et tu décides quoi faire.
Scratchpad partagé NOTES.md
Chaque agent du run lit et écrit dans un fichier markdown du workspace. Survit à la compaction, au crash, au redémarrage. La source de vérité unique pour le raisonnement de l'équipe.
Inbox de rôle à rôle
Besoin que le QA pose une question à l'Architect en cours de run ? team_ask poste un message dans l'inbox du rôle. Le prochain agent sur ce rôle le lit et répond. Vrai chat entre agents.
Communication inter-agents via MCP
Tous les outils d'équipe sont exposés via un serveur MCP. Les outils survivent à la compaction de contexte Claude (Anthropic les renvoie à chaque tour). Résistants à /clear, /compact et aux longues boucles.
Résumé de handoff propulsé par Haiku
Si un agent n'écrit pas son propre résumé de feature, un petit appel Haiku en génère un à partir du diff git. Pas cher, rapide, et l'agent suivant atterrit toujours avec du contexte.
Propagation Browser MCP
Un node d'équipe avec verifyInBrowser bascule automatiquement son agent en mode browser-access. Le node QA atterrit avec tous les outils browser (navigate, click, type, screenshot, get logs).
Agents éphémères par run
Chaque run d'équipe spawn des agents frais et les détruit au dismiss. Ta liste d'agents projet reste propre. L'équipe c'est le workflow, les agents c'est le runtime.
Équipes globales et projet
Sauvegarde des équipes réutilisables dans ta bibliothèque globale (~/.agentsroom/teams) ou épingle-les à un projet spécifique (commitées avec la room). Même éditeur, scope différent.
Templates d'équipe inclus
Trois templates de base livrés avec l'app : Dev vers QA, Dev vers QA avec boucle de feedback, et Dev vers Security vers QA. Duplique, édite, lance. Démarre en 30 secondes.
UI timeline du run
Chaque handoff apparaît comme une carte dans la timeline du run : quel rôle vient de finir, ce que dit le résumé, quels fichiers ont changé, quels flags ont été posés. Auditable, rejouable.
Lance sur n'importe quel ticket de backlog
Pose un ticket sur une équipe et la chaîne démarre sur ce ticket. Le premier agent lit le titre et le corps du ticket, le reste de l'équipe enchaîne à partir de là.
14 rôles spécialisés, prêts à être câblés
Chaque rôle a son propre system prompt, ses zones de focus et ses tâches d'exemple. Mixe-les sur le canvas. Ajoute tes propres rôles custom à tout moment.
Pourquoi une vraie équipe bat un super-agent unique
L'orchestration multi-agents sonne comme un buzzword. Voici la différence pratique, sur une feature que tu livrerais vraiment.
Scénario : ajouter un flow de checkout Stripe à un site e-commerce
Super-agent solo
- • Lit le ticket. Écrit 600 lignes entre l'API, le formulaire React, le webhook, la migration et les tests.
- • Oublie la clé d'idempotence sur le webhook. Oublie de tester le chemin d'échec. Oublie la variable d'env de staging.
- • Dit 'Done'. Tu passes deux heures à chasser les bugs en production.
Agent Team (Dev vers Security vers QA)
- • L'agent Fullstack livre l'implémentation, commit, fait le handoff avec un résumé et une liste de risques flaggant le changement d'auth.
- • L'agent Security lit le diff, audite la vérif de signature du webhook, écrit des pistes de test pour le QA dans le payload de handoff.
- • L'agent QA exécute les pistes de test dans le navigateur intégré, tombe sur un bug d'idempotence, pose qaPassed equals false, renvoie le ticket au Dev avec la repro exacte.
- • Dev corrige, refait le handoff. QA passe. Le PM finalise. Le run passe à done.
Même ticket, mêmes modèles, même projet. Forme de travail différente. L'approche équipe attrape ce que l'agent solo rate, parce que chaque rôle a un brief focalisé et un handoff structuré.
Comment un run d'équipe se déroule
Ouvre l'onglet Teams
Dans la vue projet, l'onglet Teams liste trois templates de base (Dev vers QA, Dev vers QA avec boucle de feedback, Dev vers Security vers QA) plus toute équipe que tu as déjà sauvegardée. Duplique un template ou clique sur 'Nouvelle équipe'.
Construis le workflow sur le canvas
Pose des nodes d'agent sur le canvas React Flow. Pour chaque node, choisis le rôle (Fullstack, QA, Security, PM, etc.), le provider, le modèle, et quelques lignes d'instructions d'étape. Câble-les avec des edges. Ajoute des conditions sur les edges si tu as besoin de branchement.
Dev → QA → PMDéfinis le mode de handoff par node
Handoff auto : l'agent appelle team_complete_step quand son travail est terminé, le runner prend le relais. Handoff manuel : l'agent attend que tu cliques sur 'Hand off'. Mixe les deux selon le besoin.
Lance l'équipe
Depuis un ticket de backlog, clique sur 'Run with team'. Depuis un slot d'agent vide, clique sur 'Create as team'. Le premier node spawn comme agent éphémère dans le workspace projet.
Regarde le handoff se faire
Quand l'agent N finit, AgentsRoom construit le payload de handoff (résumé de feature via l'agent ou via Haiku, diff git, risques, pistes de test, flags), append une note à NOTES.md, choisit le bon edge sortant en fonction des flags, et spawn l'agent N+1 avec ce payload comme contexte d'entrée.
Boucle, fin, finalisation
Les boucles de feedback ré-entrent dans l'agent original (mémoire complète préservée). Le node de fin déclenche awaiting-finalization. Tu cliques sur 'Finish run'. Dismiss la bannière pour détruire les agents et libérer les PTY.
Une communication inter-agents qui survit à tout
Le détail que la plupart des démos multi-agents zappent. Voici ce qui fait tenir Agent Teams sur des runs longs et beaucoup de cycles.
Les agents Claude Code ont une fenêtre de contexte et ils la compactent. L'erreur classique des systèmes multi-agents, c'est de mettre la coordination de l'équipe uniquement dans le system prompt. Après deux cycles de /compact, l'agent n'a plus aucune idée qu'il est dans une équipe. AgentsRoom ne fait pas ça.
Toute la coordination d'équipe vit à trois endroits qui survivent à la compaction. Premièrement, un serveur MCP (agentsroom-team) expose des outils (team_get_context, team_read_notes, team_post_note, team_read_inbox, team_ask, team_read_timeline, team_read_diff, team_complete_step). Les outils MCP sont renvoyés à Claude à chaque tour par le CLI, donc ils sont immunisés contre la compression de contexte.
Deuxièmement, un hook UserPromptSubmit tourne avant chaque message utilisateur et préfixe un petit rappel s'il y a de nouvelles notes ou de nouveaux messages d'inbox pour ce rôle. Pas cher quand il ne se passe rien, décisif quand il se passe quelque chose.
Troisièmement, NOTES.md et state.json vivent sur disque dans le workspace. L'agent peut les relire à n'importe quel moment avec un simple Read ou avec team_read_notes. Ils survivent aux crashs, redémarrages, /clear, /compact et reboots Mac. Le system prompt n'est jamais la source de vérité, le disque et les outils MCP le sont.
Ce que les gens construisent avec Agent Teams
Pipeline Dev vers QA
Le classique. Le Fullstack livre la feature. Le QA la valide dans le navigateur intégré, exécute les pistes de test, signe. Équipe à deux nodes, tourne sur chaque ticket du backlog.
Dev vers QA avec boucle de feedback
Comme au-dessus, mais avec un edge conditionnel : qaPassed equals false renvoie le ticket au Dev avec les pistes de test. Max 3 cycles. Attrape les régressions avant qu'elles n'arrivent à un reviewer humain.
Dev vers Security vers QA
Pour les features qui touchent à l'auth, aux paiements ou aux PII. L'agent Security review le diff, flag les risques, écrit des pistes de test pour le QA. Utilisé par les équipes qui livrent du fintech, du healthtech et du SaaS B2B.
PM vers Architect vers Dev
Workflow spec-first. L'agent PM transforme le ticket en spec structurée. L'Architect choisit l'approche. Le Dev implémente. Trois rôles, séparation propre, décisions traçables.
Fan-out Frontend, Backend, DevOps
Découpage séquentiel pour les features full-stack. Le Frontend livre l'UI. Le Backend livre l'API. Le DevOps ajoute la config infra. Chaque rôle bosse dans sa zone, fait son handoff avec un diff propre.
Marketing vers SEO vers i18n
Oui, AgentsRoom Teams n'est pas que pour le code. Le Marketing écrit le copy de la landing. Le SEO injecte les mots-clés. La Localization traduit en 14 langues. Une équipe, un ticket, une livraison.
Comment ça se compare aux autres approches multi-agents
L'orchestration multi-agents est un buzzword saturé. Voici ce qui livre vraiment, et où AgentsRoom Teams se positionne.
Anthropic Subagents (outil Task, .claude/agents) permet à une session Claude unique de déléguer à des agents helper spécialisés. Excellent pour la délégation inline, mais la session parente reste le coordinateur et un contexte unique. AgentsRoom Teams est un cran au-dessus : chaque node d'équipe est une session Claude top-level séparée avec sa propre fenêtre, son propre état, son propre scrollback. CrewAI, AutoGen et LangGraph sont d'excellents frameworks Python pour les flows multi-agents, mais ils vivent en dehors de ton IDE et ne font pas tourner de vrais Claude Code, Codex ou Gemini CLIs end-to-end sur ton repo local. n8n, Make, Pipedream et Retool livrent le même genre d'éditeur canvas qu'on utilise, mais ce sont des plateformes d'automatisation généralistes, pas pensées pour les agents IA de code. AgentsRoom Teams est l'éditeur de workflow multi-agents façon canvas, mais câblé spécifiquement à tes agents CLI, ton projet, ton git, tes terminaux et ton navigateur.
Si tu construis des systèmes agentiques en Python, continue avec CrewAI ou LangGraph pour les pipelines de prod. Si tu livres du code avec Claude Code, Codex CLI, OpenCode, Gemini CLI ou Aider, Agent Teams est le workflow d'équipe qui tourne là où tu codes vraiment.
FAQ
En quoi c'est différent des subagents Claude Code (l'outil Task, .claude/agents) ?
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 uniquement avec Claude Code ?
Ça marche avec tous les providers supportés par AgentsRoom (Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider). 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.
C'est quoi un payload de handoff ?
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.
Les agents peuvent vraiment faire des allers-retours (Dev vers QA vers Dev) ?
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.
Qu'est-ce qui se passe si le QA rejette le Dev pour toujours ?
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.
Tous les agents d'équipe partagent le même workspace git ?
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.
Ça demande un abonnement supplémentaire ?
Non. Teams fait partie d'AgentsRoom. Tu apportes tes propres clés provider (Claude, Codex, OpenCode, Gemini, Aider) 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.
Où sont stockées les équipes ? Elles sont commitées dans git ?
Les équipes scope-projet vivent avec la room, synchronisées au cloud et cachées dans {project}/.agentsroom/teams-cache.json (gitignored). Les équipes globales vivent dans ~/.agentsroom/teams/{teamId}.json sur ta machine, un fichier par équipe. Tu décides quel scope colle à chaque workflow.
Qu'est-ce qui se passe si un agent crash ou que l'app redémarre en plein run ?
L'état du run est persisté sur disque dans {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl). NOTES.md est append-only, chaque écriture d'état est atomique. Les agents peuvent tout relire à n'importe quel moment avec team_read_notes ou team_get_context. La couche d'orchestration est en train d'être durcie pour rejouer entièrement un run interrompu au redémarrage de l'app, mais l'histoire on-disk est déjà crash-safe.
Je peux faire tourner plusieurs équipes en parallèle sur différents tickets ?
Oui. Chaque run d'équipe est indépendant et identifié par son runId. Tu peux avoir une équipe Dev vers QA qui tourne sur le ticket A, une équipe Dev vers Security vers QA sur le ticket B et une équipe PM vers Architect vers Dev sur le ticket C, le tout en live dans le même projet. À l'intérieur d'un run unique, l'exécution est séquentielle (un node actif à la fois) pour la prédictibilité.
Construis ton équipe dev IA de rêve
Trois templates livrés avec l'app. Ouvre AgentsRoom, pose des nodes, dessine des edges, lance sur n'importe quel ticket. Ton équipe d'ingénieurs IA est à un clic.
App companion : suivez vos agents en déplacement
Compatible avec Claude, Codex, OpenCode, Gemini CLI et Aider
Remontez bugs et demandes directement dans votre backlog public.