Agent Teams.
Een echt technisch team, gescript.

Claude subagents zijn inline delegaties van een enkele ouder Claude sessie. De ouder beslist wanneer een subagent wordt aangeroepen, de subagent draait in een geïsoleerd contextvenster, retourneert een resultaat, en de ouder gaat verder. AgentsRoom Teams is een niveau hoger: elke node is een top-level Claude Code sessie met zijn eigen terminal, eigen status en eigen scrollback. Je ziet elke agent live draaien in zijn eigen tabblad, je kunt op elk moment met een van hen praten, je kunt het team pauzeren, de workflow wijzigen en hervatten. Het is geen vervanging voor Claude subagents, je kunt beide absoluut gebruiken. Een teamnode kan intern subagents gebruiken.

Het werkt met alle 14 agent-CLI's die AgentsRoom ondersteunt (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor en nog 10 andere). Elke teamnode kiest zijn eigen provider en model. De MCP-gebaseerde teamcoördinatietools werken identiek over providers heen omdat ze worden blootgesteld via het standaard Model Context Protocol. Je kunt een team draaien met Codex op de zware backend-node en Haiku op de QA-node als dat past bij je budget en je latentie.

Een gestructureerd object dat van de ene agent naar de volgende reist. Velden: featureSummary (een korte beschrijving van wat zojuist is geleverd), changedFiles (git diff naam-status), touchedAreas (UI, API, DB, config), risks (alles waar de volgende agent zich zorgen over moet maken), testHints (prioriteiten voor QA), flags (booleans zoals qaPassed, gebruikt door conditionele randen). De agent roept team_complete_step aan met deze payload, de runner valideert het aan de serverzijde, de volgende agent ontvangt het als zijn startcontext.

Ja. Wanneer een node opnieuw wordt betreden (cyclus groter dan 1), spawnt AgentsRoom geen nieuwe agent. Het hergebruikt de originele agent van cyclus 1, schrijft de nieuwe overdrachtspayload direct in zijn bestaande terminal, en de agent behoudt zijn volledige Claude sessiegeheugen van de vorige cycli. Dit is cruciaal: een Dev-agent die al weet wat QA de vorige keer heeft gemarkeerd, lost de bug op. Een nieuwe Dev-agent zonder geheugen zou dezelfde fout gewoon herhalen.

De teamconfiguratie heeft een max-cycles beveiliging, standaard 3. Wanneer de limiet is bereikt, pauzeert de run met een 'geblokkeerde' status en wacht op jou. Je kunt de run voltooien, handmatig nog een keer overdragen, of alles annuleren. Geen oneindige lussen, geen verrassende rekeningen 's nachts.

Ja. Het team draait in een enkele werkruimte en een enkele branch (of worktree als je de AgentsRoom Worktrees-functie gebruikt). Elke agent ziet het werk van de vorige via git. De overdrachtspayload bevat een git diff tegen de run-baseline zodat de volgende agent precies weet wat nieuw is.

Nee. Teams maken deel uit van AgentsRoom. Je brengt je eigen provider-sleutels (Claude, Codex, GitHub Copilot CLI, Cursor en 10 andere agent-CLI's) en je betaalt alleen voor de tokens die je gebruikt, net als bij een enkele agent. Het draaien van een Dev naar QA team op een klein ticket kost doorgaans hetzelfde als het draaien van een enkele Fullstack agent, omdat Haiku/Sonnet op de QA-stap goedkoop is.

Project-gescopeerde teams leven met de ruimte, gesynchroniseerd met je account en gecached in {project}/.agentsroom/teams-cache.json (git genegeerd). Globale teams worden ook gesynchroniseerd met je account, zodat je teambibliotheek je volgt over machines heen, met ~/.agentsroom/teams/ als de offline cache. Gezaaide sjablonen blijven lokaal: elke machine zaait ze in zijn eigen taal.

De run-status wordt naar schijf opgeslagen in {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), met atomaire schrijfbewerkingen en een alleen-aanvulbaar notitiebestand. Een onderbroken run hervat bij het opnieuw opstarten van de app: de orkestrator betreedt opnieuw de stap die actief was, heropent de terminal, en de agent krijgt zijn context terug uit de notities en de teamtools. Een run waarvan de teamdefinitie is verwijderd, wordt automatisch gesloten in plaats van voor altijd te blijven hangen.

Ja. Elke teamrun is onafhankelijk en geïdentificeerd door zijn runId. Je kunt drie verschillende teams live hebben op drie tickets in hetzelfde project. Binnen een enkele run volgt de uitvoering je grafiek: standaard sequentieel, parallel waar je parallelle takken tekent (bijvoorbeeld QA en Beveiliging die tegelijkertijd beoordelen), altijd terug samenkomend op één deterministische samenvoegnode.

Ja. Teken twee onvoorwaardelijke randen uit een node en beide doelen draaien als parallelle takken, elk in zijn eigen agent en terminal. Takken zijn één node diep en moeten samenkomen op een gemeenschappelijke samenvoegnode, die de editor valideert voordat je kunt draaien. Wanneer elke tak is voltooid, ontvangt de samenvoeging één samengevoegde payload: samenvattingen gelabeld per rol, gededupliceerde risico's en testaanwijzingen, en vlaggen samengevoegd met een fail-safe regel (een booleaanse conflict wordt opgelost naar false).

Je typt een shell-opdracht op de node, bijvoorbeeld npm test, en optioneel een vlagnaam (standaard checkPassed). Wanneer de agent voltooiing signaleert, voert AgentsRoom de opdracht uit in de werkruimte met een limiet van vijf minuten. Exitcode 0 schrijft true in de vlag, iets anders schrijft false, waarmee wordt overschreven wat de agent over zichzelf heeft gerapporteerd. Bij een mislukking reizen de laatste kilobytes van de uitvoer naar de volgende agent, zodat de loop-back landt met de daadwerkelijke stack trace, en het resultaat wordt weergegeven op de uitvoeringstijdlijn.

Ja. Elke node kan vaardigheden vastzetten uit je Vaardighedenbibliotheek, project of globaal. De agent krijgt de instructie om elk van hen te laden voordat de stap begint, zodat een beoordelingschecklist, een implementatierunbook of een testprocedure bij elke uitvoering wordt toegepast in plaats van afhankelijk te zijn van het geheugen van de agent.

Ja. De editor voert een reeks grafiekcontroles uit en scheidt blokkerende fouten van waarschuwingen. Fouten stoppen de run: een ontbrekende Start- of End-node, dubbele verbindingen, twee verbindingen met dezelfde voorwaarden, een verbinding waarvan de voorwaarden elkaar tegenspreken, een ongeldige fan-out. Waarschuwingen niet: een vlagnaam met spaties eromheen, een voorwaarde op een verbinding uit Start, een node waarvan alle uitgaande verbindingen voorwaardelijk zijn zodat de run kan vastlopen. Beide staan in een controlepaneel en de schuldige verbindingen krijgen een andere kleur op het canvas, zodat je de grafiek repareert voordat je er een run aan verliest.

Nee, en dat is bewust. Zolang een run leeft, is de teamdefinitie bevroren voor schrijfacties vanuit de MCP-tools: nodes, randen, max cycli, stapinstructies, vaardigheden, controlecommando, rol, provider en model zijn alleen-lezen voor agents, een vaardigheid die door de run is geladen kan evenmin worden herschreven, en de bevriezing valt niet te omzeilen door het team te verwijderen en opnieuw aan te maken. Een agent hoort de regel die hem stuurt niet te herschrijven. Jij blijft alles op elk moment vanuit de interface bewerken.

Ja. De mobiele metgezel kan een team starten op een project, toont een runbanner met de voortgang van elke stap en geeft toegang tot de terminal van de agent die op dat moment werkt. De run zelf draait nog steeds op je desktop, via de echte CLI's, precies alsof je hem daar had gestart.

Vraag je af waarop de run zou stuklopen. Als hij zou stuklopen door de draad kwijt te raken, kies dan de estafette: één sessie speelt alle rollen en legt zichzelf nooit een beslissing opnieuw uit. Als hij zou stuklopen doordat hij het met zichzelf eens is, kies dan het team: de rollen draaien als aparte agents, dus wie de code beoordeelt is niet wie hem schreef. De estafette is de standaard omdat elk team dat vóór deze instelling gebouwd is al zo werkt, niet omdat het beter zou zijn.

Nee. Een teamgenoot start de eerste keer dat hij nodig is, ofwel omdat de grafiek bij zijn stap komt, ofwel omdat een andere agent hem schrijft, en daarna blijft hij de rest van de run in leven. Een team van vier rollen verbrandt dus geen vier sessies om een vraag te beantwoorden die er maar twee aangaat, en een rol die in cyclus drie wordt aangesproken is nog steeds dezelfde agent die in cyclus één antwoordde.

Alleen wat hij kan lezen. Een teamgenoot die halverwege de run instapt heeft zijn eigen sessie en geen herinnering aan het werk, en juist daarom is zijn mening iets waard. Hij komt bij via de gedeelde notities, de tijdlijn van de run en de git-diff sinds de run begon, die hij allemaal met zijn eigen tools leest. Dat lezen is de prijs van deze modus, en het is de reden dat de estafettemodus blijft bestaan.

Ja, en dat is de standaard. Met het vrije gesprek uit mag een teamgenoot alleen schrijven naar de rollen waar zijn knooppunt in de grafiek naar wijst, zodat er niet om een poort heen gewerkt kan worden door het aan iemand anders te vragen. Zet het aan wanneer je een echt team wilt: iedereen schrijft naar iedereen, in elke richting en naar meerdere tegelijk. De grafiek start de run hoe dan ook nog steeds en beëindigt hem ook.

Ja. Een trigger kan naar een team wijzen in plaats van naar een enkele agent, dus dezelfde pipeline draait zonder toezicht: op het ritme van de kalender, op het quotumvenster van je AI-abonnement, of op een gebeurtenis gestuurd door GitHub, GitLab, Slack, Linear, Sentry of je CI. De prompt gaat naar de eerste stap van het team, de run gebeurt op je eigen machine zoals elke andere, hij belandt in de geschiedenis van de trigger, en een melding vertelt je dat hij is gestart. Triggers vind je in het paneel Triggers van het project, naast de geplande taken.