Agent Teams.
Prawdziwa ekipa techniczna, zeskryptowana.

Subagents Claude to inline delegacje z pojedynczej sesji Claude-rodzica. Rodzic decyduje, kiedy wywołać subagenta, subagent działa w izolowanym kontekście, zwraca wynik, a rodzic kontynuuje. AgentsRoom Teams są o poziom wyżej: każdy węzeł to top-level sesja Claude Code z własnym terminalem, własnym stanem i własnym scrollbackiem. Widzisz każdego agenta na żywo w jego własnej zakładce, możesz z nim pogadać w dowolnym momencie, możesz spauzować zespół, zmienić workflow i wznowić. To nie jest zamiennik subagents Claude, możesz absolutnie używać obu. Węzeł zespołu może używać subagentów wewnętrznie.

Działa ze wszystkimi 14 CLI agentów wspieranymi przez AgentsRoom (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor i 10 innymi). Każdy węzeł zespołu wybiera własnego dostawcę i model. Narzędzia koordynacji zespołu oparte na MCP działają identycznie między dostawcami, bo są wystawione przez standardowy Model Context Protocol. Możesz uruchomić zespół z Codex na ciężkim węźle backendowym i Haiku na węźle QA, jeśli to pasuje do Twojego budżetu i latencji.

Ustrukturyzowany obiekt podróżujący od jednego agenta do następnego. Pola: featureSummary (krótki opis tego, co zostało dowiezione), changedFiles (git diff name-status), touchedAreas (UI, API, DB, config), risks (cokolwiek, czym następny agent powinien się przejmować), testHints (priorytety dla QA), flags (booleany jak qaPassed, używane przez krawędzie warunkowe). Agent wywołuje team_complete_step z tym payloadem, runner waliduje go server-side, kolejny agent dostaje go jako kontekst startowy.

Tak. Gdy węzeł jest ponownie wchodzony (cykl większy niż 1), AgentsRoom nie spawnuje nowego agenta. Reużywa oryginalnego agenta z cyklu 1, zapisuje nowy payload handoff bezpośrednio w jego istniejącym terminalu, a agent zachowuje pełną pamięć sesji Claude z poprzednich cykli. To jest krytyczne: agent Dev, który już wie, co QA flagował poprzednio, naprawia buga. Świeży agent Dev bez pamięci po prostu powtórzyłby ten sam błąd.

Konfiguracja zespołu ma max-cycles guard, domyślnie 3. Gdy cap zostanie osiągnięty, run pauzuje ze statusem 'blocked' i czeka na Ciebie. Możesz sfinalizować run, ręcznie zrobić jeszcze jeden handoff lub anulować wszystko. Żadnych nieskończonych pętli, żadnych niespodziewanych nocnych rachunków.

Tak. Zespół działa w jednym workspace i na jednym branchu (lub worktree, jeśli używasz feature'a AgentsRoom Worktrees). Każdy agent widzi pracę poprzedniego przez git. Payload handoff zawiera git diff względem baseline runa, więc kolejny agent wie dokładnie, co jest nowe.

Nie. Teams są częścią AgentsRoom. Przynosisz własne klucze dostawców (Claude, Codex, GitHub Copilot CLI, Cursor i 10 innych CLI agentów) i płacisz tylko za tokeny, których używasz, jak przy pojedynczym agencie. Uruchomienie zespołu Dev do QA na małym tickecie zwykle kosztuje tyle samo, co uruchomienie pojedynczego agenta Fullstack, bo Haiku/Sonnet na kroku QA jest tani.

Zespoły projektowe żyją z roomem, synchronizowane z twoim kontem i cache'owane w {project}/.agentsroom/teams-cache.json (gitignored). Zespoły globalne również są synchronizowane z twoim kontem: biblioteka podąża za tobą między maszynami, z ~/.agentsroom/teams/ jako cachem offline. Dołączone szablony zostają lokalne: każda maszyna instaluje je we własnym języku.

Stan uruchomienia jest zapisywany na dysku w {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), z atomowymi zapisami i notatkami append-only. Przerwane uruchomienie wznawia się po restarcie aplikacji: orkiestrator wraca do aktywnego kroku, otwiera terminal na nowo, a agent odzyskuje kontekst z notatek i narzędzi zespołu. Uruchomienie, którego zespół usunięto, jest zamykane automatycznie zamiast wisieć w nieskończoność.

Tak. Każde uruchomienie jest niezależne, identyfikowane przez runId. Możesz mieć trzy różne zespoły żywe na trzech ticketach tego samego projektu. Wewnątrz jednego uruchomienia przebieg podąża za twoim grafem: sekwencyjnie domyślnie, równolegle tam, gdzie narysujesz równoległe gałęzie (na przykład QA i Security przeglądające jednocześnie), zawsze z deterministycznym złączeniem.

Tak. Narysuj dwa połączenia bez warunku z jednego węzła, a oba cele działają jako równoległe gałęzie, każdy we własnym agencie i terminalu. Gałęzie mają głębokość jednego węzła i muszą zbiegać się we wspólnym węźle łączącym, co edytor waliduje przed uruchomieniem. Gdy każda gałąź skończy, złączenie dostaje scalony payload: podsumowania opisane rolami, zdeduplikowane ryzyka i wskazówki testowe oraz flagi scalone regułą fail-safe (konflikt boolowski rozstrzyga się na false).

Wpisujesz polecenie shell na węźle, na przykład npm test, i opcjonalnie nazwę flagi (domyślnie checkPassed). Gdy agent zgłasza koniec kroku, AgentsRoom uruchamia polecenie w workspace z limitem pięciu minut. Kod wyjścia 0 zapisuje true do flagi, każdy inny false, nadpisując to, co agent zadeklarował o sobie. Przy niepowodzeniu ostatnie kilobajty wyjścia wędrują do następnego agenta: powrót ląduje z prawdziwym stack trace, a wynik widać na osi czasu uruchomienia.

Tak. Każdy węzeł może przypiąć skille z twojej Skills Library, projektowej lub globalnej. Agent dostaje polecenie wczytania każdego z nich przed rozpoczęciem kroku: checklista review, runbook wdrożenia czy procedura testowa są stosowane przy każdym uruchomieniu, zamiast zależeć od pamięci agenta.

Tak. Edytor uruchamia zestaw kontroli grafu i oddziela błędy blokujące od ostrzeżeń. Błędy zatrzymują uruchomienie: brakujący węzeł Start lub End, zduplikowane połączenia, dwa połączenia o tych samych warunkach, połączenie, którego warunki są ze sobą sprzeczne, nieprawidłowy fan-out. Ostrzeżenia nie: nazwa flagi otoczona spacjami, warunek na połączeniu wychodzącym ze Start, węzeł, którego wszystkie wychodzące połączenia są warunkowe, przez co uruchomienie może się zatrzymać. Jedne i drugie są wypisane w panelu kontroli, a winne połączenia zmieniają kolor na kanwie, więc poprawiasz graf, zanim stracisz przez niego uruchomienie.

Nie, i jest to celowe. Dopóki uruchomienie żyje, definicja zespołu jest zamrożona wobec zapisów przychodzących z narzędzi MCP: węzły, krawędzie, limit cykli, instrukcje kroków, skille, polecenie kontrolne, rola, dostawca i model są dla agentów tylko do odczytu, skill wczytany przez uruchomienie też nie może zostać nadpisany, a zamrożenia nie da się obejść przez usunięcie i ponowne utworzenie zespołu. Agent nie może przepisywać reguły, która nim rządzi. Ty dalej edytujesz wszystko z interfejsu w dowolnym momencie.

Tak. Aplikacja mobilna może wystartować zespół na projekcie, pokazuje baner uruchomienia z postępem każdego kroku i daje dostęp do terminala agenta, który właśnie pracuje. Samo uruchomienie nadal wykonuje się na Twoim komputerze, przez prawdziwe CLI, dokładnie tak, jakbyś odpalił je na miejscu.

Zapytaj, na czym run by poległ. Jeśli poległby przez zgubienie wątku, wybierz sztafetę: jedna sesja gra każdą rolę i nigdy nie tłumaczy decyzji samej sobie drugi raz. Jeśli poległby przez przytakiwanie samemu sobie, wybierz zespół: role działają jako osobni agenci, więc kod recenzuje nie ten, kto go napisał. Sztafeta jest domyślna, bo dokładnie tak działa każdy zespół zbudowany, zanim to ustawienie powstało, a nie dlatego, że jest lepsza.

Nie. Członek zespołu startuje przy pierwszej potrzebie, bo graf dochodzi do jego kroku albo bo napisał do niego inny agent, i od tej chwili zostaje żywy do końca runu. Czteroosobowy zespół nie spala więc czterech sesji, żeby odpowiedzieć na pytanie dotyczące tylko dwóch ról, a rola zagadnięta w trzecim cyklu to wciąż ten sam agent, który odpowiadał w pierwszym.

Tylko tyle, ile jest w stanie przeczytać. Członek zespołu dołączający w trakcie runu ma własną sesję i żadnej pamięci tej pracy, i właśnie dlatego jego zdanie coś znaczy. Nadrabia ze wspólnych notatek, z osi czasu runu i z gitowego diffa od startu runu, a wszystko to czyta własnymi narzędziami. To czytanie jest kosztem tego trybu i to dlatego tryb sztafety nadal istnieje.

Tak, i tak jest domyślnie. Przy wyłączonej swobodnej rozmowie członek zespołu może pisać tylko do ról, na które wskazuje jego węzeł w grafie, więc bramki nie da się obejść, pytając kogoś innego. Włącz ją, kiedy chcesz prawdziwego zespołu: każdy pisze do każdego, w dowolnym kierunku i do kilku naraz. Tak czy inaczej graf wciąż startuje run i wciąż go kończy.

Tak. Wyzwalacz może wskazywać na zespół zamiast na pojedynczego agenta, więc ten sam pipeline działa bez nadzoru: w rytmie kalendarza, w oknie limitu twojego planu AI albo na zdarzenie wysłane przez GitHub, GitLab, Slack, Linear, Sentry lub twoje CI. Prompt trafia do pierwszego kroku zespołu, run dzieje się na twojej własnej maszynie jak każdy inny, ląduje w historii wyzwalacza, a powiadomienie mówi ci, że wystartował. Wyzwalacze znajdziesz w panelu Wyzwalacze w projekcie, obok zaplanowanych zadań.