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.
Composez votre equipe de dev IA ideale sur un canvas visuel, comme un workflow n8n. Liens conditionnels, boucles de feedback, branches de relecture paralleles, portes de qualite verifiees par la machine, garde-fou max-cycles. Sauvegardez-la une fois, lancez-la sur chaque ticket, et regardez vos 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, Antigravity CLI, Aider, Grok Build, Mistral Vibe ou Kimi Code 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, Antigravity 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, Antigravity 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.
Portes de qualite verifiees par la machine
Epinglez une commande de controle sur un node (npm test, un lint, un build). Le runner l'execute quand l'agent se declare termine : code de sortie 0, le flag de routage passe a true, sinon false. Le resultat mesure remplace toujours la declaration de l'agent.
Branches de relecture paralleles
Tracez deux liens sans condition depuis un node et les deux cibles tournent en meme temps : QA et Securite relisent le meme diff cote a cote, puis un node de jonction fusionne leurs rapports. Une seule branche rouge suffit a garder la porte fermee.
Skills epinglees par etape
Attachez des entrees de votre Skills Library a un node. L'agent les charge avant de commencer l'etape : votre checklist de review ou votre procedure de deploiement est appliquee a chaque run, pas seulement quand l'agent y pense.
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.
Les runs survivent aux redemarrages
Fermez l'app en plein run, rouvrez-la : le run reprend l'etape ou il en etait. L'etat, les notes et la timeline vivent sur disque ; l'orchestrateur reprend le travail au lieu de laisser un zombie derriere lui.
Bibliotheque d'equipes sur votre compte
Les equipes globales sont synchronisees a votre compte et vous suivent d'une machine a l'autre ; les equipes projet voyagent avec la room. Les deux gardent un cache hors-ligne, et les modifications faites hors-ligne se rejouent a la reconnexion.
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.
Quatre modeles d'equipe inclus
Coder puis verifier, Specifier coder verifier, Chasse au bug (reproduire, corriger, prouver), et Bouclier de release avec QA et Securite en parallele. Dupliquez, editez, lancez. Pret 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é.
La confiance se mesure, elle ne se declare pas
Un agent qui corrige sa propre copie finira par se mettre 20/20. Agent Teams garde le pipeline honnete avec deux mecanismes.
Le code de sortie decide
Chaque node peut declarer une commande de controle : npm test, un lint, un build, tout ce qui renvoie un code de sortie. Quand l'agent appelle team_complete_step, le runner execute la commande dans le workspace et ecrit le resultat mesure dans le flag de routage. Vert, le run avance. Rouge, la sortie d'erreur atterrit en tete du contexte de l'agent suivant, avec la vraie stderr. Un agent qui affirme que tous les tests passent alors que la suite est rouge est route par la suite rouge, pas par son affirmation.
Quatre yeux, en meme temps
Eclatez un node en branches paralleles : QA deroule les parcours pendant que Securite audite le diff, chacun dans son propre agent, aveugle aux conclusions de l'autre. Un node de jonction attend toutes les branches, fusionne resumes, risques et flags, puis route sur le resultat combine. Les conflits booleens se resolvent a false par construction : un seul relecteur en echec suffit a retenir la release.
Dev → [ QA ∥ Security ] → Release gateComment un run d'équipe se déroule
Ouvre l'onglet Teams
Dans la vue projet, l'onglet Teams liste quatre modeles fournis (Coder puis verifier, Specifier coder verifier, Chasse au bug, Bouclier de release) plus toutes les equipes deja sauvegardees. Dupliquez un modele ou cliquez sur 'New team'.
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 termine, AgentsRoom construit le payload de handoff (resume via l'agent ou via Haiku, diff git, risques, pistes de test, flags), ajoute une note dans NOTES.md, choisit le bon lien sortant selon les flags, et passe la main a l'agent N+1 avec ce payload comme contexte d'entree. Si le node declare une commande de controle, le runner l'execute d'abord : c'est le code de sortie mesure, pas la declaration de l'agent, qui remplit le flag de routage.
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.
Bouclier de release : QA et Securite en parallele
Un node dev s'eclate en QA et Securite qui tournent cote a cote, puis une porte de release fusionne les deux rapports. Livre avec l'app en modele. Tout le bouclier reboucle vers le Dev si l'une des branches signale un probleme.
Chasse au bug : reproduire avant de corriger
Un agent QA reproduit le bug et note les etapes exactes. Un dev corrige la cause racine. Un second QA rejoue les memes etapes pour prouver le correctif. Fini le 'ca marche chez moi'.
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 Antigravity 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, Antigravity CLI, Aider, Grok Build, Mistral Vibe ou Kimi Code, 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, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code). 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, Antigravity, Aider, Grok Build, Mistral Vibe, Kimi Code) 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 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.
Qu'est-ce qui se passe si un agent crash ou que l'app redémarre en plein run ?
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.
Je peux faire tourner plusieurs équipes en parallèle sur différents tickets ?
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.
Deux agents peuvent-ils vraiment tourner en meme temps ?
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).
Comment fonctionnent les portes de qualite exactement ?
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.
Une etape peut-elle charger mes procedures de la Skills Library ?
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.
Construis ton équipe dev IA de rêve
Quatre modeles livres avec l'app. Ouvrez AgentsRoom, posez des nodes, tracez des liens, lancez sur n'importe quel ticket. Votre equipe d'ingenierie IA est a un clic.
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.