Agent Teams.
Prawdziwa ekipa techniczna, zeskryptowana.
AgentsRoom Teams łączy w łańcuch Twoich agentów AI do kodowania jak prawdziwy zespół inżynieryjny. Fullstack Dev dowozi feature'a, QA Engineer go waliduje, PM zatwierdza. Każda rola jest zeskryptowana, workflow jest wizualny, a każdy handoff niesie podsumowanie feature'a, diff, ryzyka i podpowiedzi testowe. Koniec z pojedynczym agentem robiącym wszystko źle.
Zbuduj wymarzony zespol deweloperski AI na wizualnym canvasie, jak workflow w n8n. Warunki na polaczeniach, petle feedbacku, rownolegle galezie przegladu, maszynowo weryfikowane bramki jakosci, limit cykli. Zapisz raz, uruchamiaj na kazdym tickecie i patrz, jak twoi agenci podaja sobie paleczke jak seniorzy.
AgentsRoom Teams: wizualny edytor workflow multi-agentowego, automatyczny handoff między agentami Claude Code, pętla feedback Dev do QA, komunikacja inter-agentowa oparta na MCP.
Agent Teams to odpowiedź AgentsRoom na brutalną prawdę o agentach AI do kodowania: pojedynczy agent, który próbuje robić wszystko, kończy robiąc wszystko źle. Agent Fullstack, który koduje, testuje, robi review, deployuje i pisze spec jednocześnie, zapomina połowę instrukcji w połowie drogi. Właściwa odpowiedź, ta używana przez każdy poważny zespół software'owy na świecie, to podzielić pracę na role. Developer koduje. QA engineer waliduje. Product manager zatwierdza. Security reviewer audytuje. Każda rola ma swój własny kontekst, swój własny focus, swoje własne narzędzia.
Dokładnie to wnosi Agent Teams do AgentsRoom. Upuszczasz węzły na nieskończony canvas (zbudowany na React Flow, tym samym silniku co n8n, Make, Retool i Pipedream), każdy węzeł to agent Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe lub Kimi Code przypisany do konkretnej roli, i łączysz je razem. Uruchamiasz zespół na tickecie z backlogu lub podpinasz go do dowolnego nowego spawnu agenta. AgentsRoom orkiestruje łańcuch: spawnuje pierwszego agenta, czeka na handoff, podsumowuje pracę, spawnuje kolejnego agenta z tym podsumowaniem jako kontekstem wejściowym, powtarza aż zespół osiągnie węzeł końcowy.
Inne narzędzia próbują tego z pojedynczym super-agentem i sprytnymi promptami. Próbowaliśmy, nie działa to powyżej trzech kroków. Role dryfują, kontekst się gubi, agent zapomina, co miał zweryfikować. Agent Teams traktuje agentów jak prawdziwych członków zespołu: każdy dostaje czystą sesję, sfokusowany system prompt, ustrukturyzowany payload handoff i współdzielony scratchpad do rozmowy z innymi. To workflow zespołu AI do programowania, którego naprawdę chcesz.
Edytor AgentsRoom Teams: upuszczaj węzły dla każdej roli, łącz je, dodawaj warunki, zapisz zespół, uruchom na dowolnym tickecie.
Orkiestracja multi-agentowa, która naprawdę skaluje
Każdy węzeł na canvasie to agent. Wybierasz jego rolę (Fullstack, Frontend, Backend, QA, Security, DevOps, PM, Architect, Mobile, Marketing, Git, SEO, Localization lub dowolną własną rolę, którą stworzyłeś), jego model (Opus, Sonnet, Haiku, GPT-5, o3, Antigravity Pro itp.), tryb handoffu (auto przez Stop hook lub manual przez przycisk) i kilka linijek instrukcji specyficznych dla kroku. To wszystko. Żadnej ceremonii prompt engineeringu, żadnego pliku konfiguracji YAML do napisania.
Krawędzie łączą węzły. Prosta krawędź oznacza: gdy pierwszy agent kończy swój krok, przekaż do następnego. Krawędź warunkowa niesie sprawdzenie flagi, na przykład qaPassed equals true. Agent QA ustawia tę flagę w payloadzie handoff, runner wybiera pasującą krawędź. Tak budujesz pętle feedback: QA kończy, qaPassed equals false, krawędź odsyła z powrotem do Dev z podpowiedziami testowymi i ryzykami. Dev poprawia, robi handoff ponownie. Pętla, aż QA przejdzie lub aż zadziała max-cycles guard.
Komunikacja inter-agentowa jest robust by design. AgentsRoom dostarcza dedykowany serwer MCP (agentsroom-team), który daje każdemu agentowi w runie zestaw narzędzi: czytaj kontekst zespołu, czytaj współdzielony scratchpad NOTES.md, posłaj notatkę dla kolegów, wyślij pytanie do innej roli, czytaj inbox, czytaj timeline, czytaj git diff względem baseline runa i zakończ krok ze ustrukturyzowanym payloadem. Te narzędzia są re-injectowane do sesji Claude w każdej turze, więc przeżywają kompakcję kontekstu. Nawet po /compact lub /clear agent nadal widzi swoje narzędzia zespołowe.
Dodatkowo hook UserPromptSubmit przypomina agentowi o nowych notatkach od kolegów przed każdą wiadomością użytkownika. Plik NOTES.md w workspace jest append-only i przeżywa crashe, restarty i reboot Maca. Schemat payloadu handoff walidowany po stronie serwera nie pozwala agentom robić handoff z pustymi lub śmieciowymi payloadami. To jest część, którą większość dem multi-agentowych po cichu pomija, i powód, dla którego większość z nich rozpada się na cyklu 3.
Wszystko, czego potrzebujesz, by prowadzić ekipę AI do programowania
Wizualny workflow, prawdziwy handoff, prawdziwe pętle feedback, prawdziwa komunikacja inter-agentowa. Zbudowane tak, byś mógł dowieźć feature'a w jednym pingu na Slacku zamiast pięćdziesięciu.
Wizualny canvas workflow
Nieskończony zoomowalny canvas oparty na React Flow, tym samym silniku stojącym za n8n, Retool, Pipedream i Make. Upuszczaj węzły, łącz je, zapisz zespół. Bez kodu, bez YAML.
14 wbudowanych ról agentów
Fullstack, Frontend, Backend, DevOps, QA, Security, PM, Architect, Mobile, Marketing, Git Expert, SEO, i18n. Plus dowolna własna rola, którą już zapisałeś w projekcie.
Model i prompt na węzeł
Każdy węzeł wybiera swojego dostawcę, swój model i swoje instrukcje kroku. Użyj Opus na Architect, Haiku na QA, Codex na ciężki backend, Antigravity na tani frontend. Mix and match.
Automatyczny handoff
Gdy agent wywołuje team_complete_step, AgentsRoom buduje payload handoff (podsumowanie feature'a, zmienione pliki, ryzyka, podpowiedzi testowe, flagi) i spawnuje kolejny węzeł z tym payloadem jako kontekstem startowym.
Opcja ręcznego handoffu
Wolisz walidować każdy krok? Przełącz węzeł w tryb manualny. Agent czeka, klikasz 'Hand off', gdy jesteś zadowolony z rezultatu. Najlepsze z obu światów.
Krawędzie warunkowe
Każda krawędź może nieść sprawdzenie flagi (np. qaPassed equals true). Buduj rozgałęzienia: jeśli QA przejdzie, idź do PM, w przeciwnym razie wracaj do Dev. Prawdziwa logika workflow, bez skryptowania.
Pętle feedback
Dev do QA do Dev do QA. Gdy QA odsyła ticket z powrotem, oryginalny agent Dev jest reużywany z pełną pamięcią poprzedniego cyklu, więc faktycznie naprawia regresję, zamiast zaczynać od nowa.
Maszynowo weryfikowane bramki jakosci
Przypnij polecenie kontrolne do wezla (npm test, lint, build). Runner uruchamia je, gdy agent zglasza koniec: kod wyjscia 0 ustawia flage routingu na true, kazdy inny na false. Zmierzony wynik zawsze nadpisuje deklaracje agenta.
Rownolegle galezie przegladu
Narysuj dwa polaczenia bez warunku z jednego wezla, a oba cele dzialaja jednoczesnie: QA i Security przegladaja ten sam diff obok siebie, a wezel laczacy scala ich raporty. Jedna czerwona galaz wystarczy, by bramka pozostala zamknieta.
Skille przypiete do kroku
Podepnij wpisy z twojej Skills Library do wezla. Agent wczytuje je przed rozpoczeciem kroku: twoja checklista review czy runbook wdrozenia sa stosowane przy kazdym uruchomieniu, a nie tylko gdy agent o nich pamieta.
Max-cycles guard
Konfigurowalny cap (domyślnie 3). Unika nieskończonych pętli QA-rejects-Dev. Gdy cap zostanie osiągnięty, run pauzuje na awaiting-finalization i decydujesz, co zrobić.
Uruchomienia przezywaja restarty
Zamknij aplikacje w trakcie, otworz ponownie: uruchomienie wraca do kroku, na ktorym bylo. Stan, notatki i os czasu zyja na dysku; orkiestrator podejmuje prace zamiast zostawiac zombie.
Biblioteka zespolow na twoim koncie
Zespoly globalne sa synchronizowane z twoim kontem i podazaja za toba miedzy maszynami; zespoly projektowe podrozuja z roomem. Oba trzymaja cache offline, a zmiany zrobione offline odtwarzaja sie po ponownym polaczeniu.
Współdzielony scratchpad NOTES.md
Każdy agent w runie czyta i zapisuje plik markdown w workspace. Przeżywa kompakcję, crash, restart. Jedyne źródło prawdy dla rozumowania zespołu.
Inbox role-to-role
Potrzebujesz, żeby QA zadał pytanie Architectowi w trakcie runa? team_ask wrzuca wiadomość do inboxa roli. Następny agent w tej roli ją czyta i odpowiada. Prawdziwy chat między agentami.
Komunikacja inter-agentowa oparta na MCP
Wszystkie narzędzia zespołowe są wystawione przez serwer MCP. Narzędzia przeżywają kompakcję kontekstu Claude (Anthropic re-sendsuje je w każdej turze). Odporne na /clear, /compact i długie pętle.
Podsumowanie handoff zasilane Haiku
Jeśli agent nie napisze własnego podsumowania feature'a, mała rozmowa Haiku wygeneruje je z git diff. Tanie, szybkie, a kolejny agent zawsze ląduje z kontekstem.
Propagacja Browser MCP
Węzeł zespołu z verifyInBrowser przełącza swojego agenta automatycznie w tryb browser-access. Węzeł QA ląduje z pełnymi narzędziami browser (navigate, click, type, screenshot, get logs).
Efemeryczni agenci na run
Każdy run zespołu spawnuje świeżych agentów i niszczy ich przy dismissie. Lista agentów Twojego projektu pozostaje czysta. Zespół to workflow, agenci to runtime.
Zespoły globalne i projektowe
Zapisuj wielokrotnego użytku zespoły w globalnej bibliotece (~/.agentsroom/teams) lub przypinaj je do konkretnego projektu (commitowane z roomem). Ten sam edytor, inny scope.
Cztery szablony zespolow w zestawie
Zbuduj i sprawdz, Specyfikacja budowa weryfikacja, Polowanie na buga (odtworz, napraw, udowodnij) oraz Tarcza wydania z rownoleglym QA i Security. Zduplikuj, edytuj, uruchom. Gotowe w 30 sekund.
UI timeline runa
Każdy handoff pojawia się jako karta w timeline runa: która rola właśnie skończyła, co mówi podsumowanie, jakie pliki się zmieniły, jakie flagi zostały ustawione. Audytowalne, replayowalne.
Uruchamiaj na dowolnym tickecie z backlogu
Upuść ticket na zespół, a łańcuch startuje na tym tickecie. Pierwszy agent czyta tytuł i treść ticketa, reszta zespołu przejmuje stamtąd.
14 wyspecjalizowanych ról, gotowych do podłączenia
Każda rola ma swój system prompt, obszary skupienia i przykładowe taski. Mieszaj je na canvasie. Dodawaj własne role w dowolnym momencie.
Dlaczego prawdziwy zespół bije jednego super-agenta
Orkiestracja multi-agentowa brzmi jak buzzword. Oto praktyczna różnica, na feature'rze, którego naprawdę byś dowiózł.
Scenariusz: dodać flow checkoutu Stripe do strony e-commerce
Samotny super-agent
- • Czyta ticket. Pisze 600 linii w API, formularzu React, webhooku, migracji i testach.
- • Zapomina o idempotency key na webhooku. Zapomina przetestować ścieżki błędu. Zapomina o env var staging.
- • Mówi 'Done'. Spędzasz dwie godziny polując na bugi w produkcji.
Agent Team (Dev do Security do QA)
- • Agent Fullstack dowozi implementację, commituje, robi handoff z podsumowaniem i listą ryzyk flagującą zmianę auth.
- • Agent Security czyta diff, audytuje sprawdzenie podpisu webhook, pisze podpowiedzi testowe dla QA w payloadzie handoff.
- • Agent QA odpala podpowiedzi testowe w wbudowanej przeglądarce, trafia na buga idempotency, ustawia qaPassed equals false, odsyła ticket do Dev z dokładną reprodukcją.
- • Dev poprawia, robi handoff ponownie. QA przechodzi. PM finalizuje. Run idzie do done.
Ten sam ticket, te same modele, ten sam projekt. Inny kształt pracy. Podejście zespołowe łapie to, co umyka samotnemu agentowi, bo każda rola ma sfokusowany brief i ustrukturyzowany handoff.
Zaufanie sie mierzy, a nie deklaruje
Agent, ktory ocenia wlasna prace, predzej czy pozniej sam sie zaliczy. Agent Teams trzyma pipeline w ryzach dwoma mechanizmami.
Decyduje kod wyjscia
Kazdy wezel moze zadeklarowac polecenie kontrolne: npm test, lint, build, cokolwiek zwracajacego kod wyjscia. Gdy agent wywoluje team_complete_step, runner uruchamia polecenie w workspace i zapisuje zmierzony wynik do flagi routingu. Zielone: uruchomienie idzie dalej. Czerwone: wyjscie bledu laduje na poczatku kontekstu nastepnego agenta, z prawdziwym stderr. Agent twierdzacy, ze wszystkie testy przechodza, gdy suita jest czerwona, zostaje pokierowany przez czerwona suite, nie przez swoje twierdzenie.
Cztery oczy, w tym samym czasie
Rozgalez wezel na rownolegle galezie: QA przechodzi przez przeplywy, podczas gdy Security audytuje diff, kazdy we wlasnym agencie, slepy na wnioski drugiego. Wezel laczacy czeka na kazda galaz, scala podsumowania, ryzyka i flagi, i kieruje dalej na podstawie polaczonego wyniku. Konflikty boolowskie rozstrzygaja sie na false z zalozenia: jeden oblany recenzent wystarczy, by wstrzymac wydanie.
Dev → [ QA ∥ Security ] → Release gateJak działa run zespołu
Otwórz zakładkę Teams
W widoku projektu zakladka Teams pokazuje cztery dolaczone szablony (Zbuduj i sprawdz, Specyfikacja budowa weryfikacja, Polowanie na buga, Tarcza wydania) oraz zapisane juz zespoly. Zduplikuj szablon albo kliknij 'New team'.
Zbuduj workflow na canvasie
Upuszczaj węzły agentów na canvas React Flow. Dla każdego węzła wybierz rolę (Fullstack, QA, Security, PM itp.), dostawcę, model i kilka linijek instrukcji kroku. Połącz je krawędziami. Dodaj warunki na krawędziach, jeśli potrzebujesz rozgałęzień.
Dev → QA → PMUstaw tryb handoffu na węzeł
Auto handoff: agent wywołuje team_complete_step, gdy jego praca jest skończona, runner przejmuje. Manual handoff: agent czeka, aż klikniesz 'Hand off'. Mieszaj oba według potrzeby.
Uruchom zespół
Z ticketa z backlogu kliknij 'Run with team'. Z pustego slotu agenta kliknij 'Create as team'. Pierwszy węzeł spawnuje jako efemeryczny agent w workspace projektu.
Patrz, jak zachodzi handoff
Gdy agent N konczy, AgentsRoom buduje payload handoffu (podsumowanie od agenta lub przez Haiku, diff gita, ryzyka, wskazowki testowe, flagi), dopisuje notatke do NOTES.md, wybiera wlasciwe polaczenie wyjsciowe na podstawie flag i przekazuje paleczke agentowi N+1 z tym payloadem jako kontekstem wejsciowym. Jesli wezel deklaruje polecenie kontrolne, runner uruchamia je najpierw: to zmierzony kod wyjscia, a nie twierdzenie agenta, ustawia flage routingu.
Pętla, koniec, finalizacja
Pętle feedback wracają do oryginalnego agenta (pełna pamięć zachowana). Węzeł końcowy wyzwala awaiting-finalization. Klikasz 'Finish run'. Dismiss banera niszczy agentów i zwalnia PTY.
Komunikacja inter-agentowa, która przeżyje wszystko
Szczegół, który większość dem multi-agentowych pomija. Oto co sprawia, że Agent Teams trzymają się przez długie runy i wiele cykli.
Agenci Claude Code mają context window i kompaktują go. Klasyczny błąd systemów multi-agentowych to umieścić koordynację zespołu tylko w system promptie. Po dwóch cyklach /compact agent nie ma pojęcia, że jest w zespole. AgentsRoom tego nie robi.
Cała koordynacja zespołu żyje w trzech miejscach, które przeżywają kompakcję. Po pierwsze, serwer MCP (agentsroom-team) wystawia narzędzia (team_get_context, team_read_notes, team_post_note, team_read_inbox, team_ask, team_read_timeline, team_read_diff, team_complete_step). Narzędzia MCP są re-sendsowane do Claude w każdej turze przez CLI, więc są odporne na kompresję kontekstu.
Po drugie, hook UserPromptSubmit odpala się przed każdą wiadomością użytkownika i dopisuje małe przypomnienie, jeśli są nowe notatki lub nowe wiadomości w inboxie dla tej roli. Tani, gdy nic się nie dzieje, decydujący, gdy się dzieje.
Po trzecie, NOTES.md i state.json żyją na dysku w workspace. Agent może je odczytać w dowolnym momencie zwykłym Read lub przez team_read_notes. Przeżywają crashe, restarty, /clear, /compact i reboot Maca. System prompt nigdy nie jest źródłem prawdy: dysk i narzędzia MCP nimi są.
Co ludzie budują z Agent Teams
Pipeline Dev do QA
Klasyk. Fullstack dowozi feature'a. QA waliduje go w wbudowanej przeglądarce, odpala podpowiedzi testowe, zatwierdza. Dwuwęzłowy zespół, działa na każdym tickecie z backlogu.
Dev do QA z pętlą feedback
To samo co wyżej, ale z krawędzią warunkową: qaPassed equals false odsyła ticket do Dev z podpowiedziami testowymi. Maks 3 cykle. Łapie regresje, zanim trafią do ludzkiego reviewera.
Dev do Security do QA
Dla feature'ów dotykających auth, płatności lub PII. Agent Security przegląda diff, flaguje ryzyka, pisze podpowiedzi testowe dla QA. Używane przez zespoły dowożące fintech, healthtech i B2B SaaS.
PM do Architect do Dev
Workflow spec-first. Agent PM zamienia ticket na ustrukturyzowany spec. Architect wybiera podejście. Dev implementuje. Trzy role, czysta separacja, śledzalne decyzje.
Fan-out Frontend, Backend, DevOps
Sekwencyjny split dla feature'ów full-stack. Frontend dowozi UI. Backend dowozi API. DevOps dodaje konfigurację infra. Każda rola pracuje w swoim obszarze, robi handoff z czystym diffem.
Marketing do SEO do i18n
Tak, AgentsRoom Teams to nie tylko kod. Marketing pisze copy landinga. SEO wstrzykuje słowa kluczowe. Localization tłumaczy na 14 języków. Jeden zespół, jeden ticket, jeden ship.
Tarcza wydania: QA i Security rownolegle
Wezel dev rozgalezia sie na QA i Security dzialajace obok siebie, a bramka wydania scala oba raporty. Dolaczona do aplikacji jako szablon. Cala tarcza wraca do Dev, jesli ktorakolwiek galaz zglosi problem.
Polowanie na buga: najpierw odtworz, potem naprawiaj
Agent QA odtwarza buga i spisuje dokladne kroki. Dev naprawia przyczyne zrodlowa. Drugi QA powtarza te same kroki, by udowodnic naprawe. Koniec z 'u mnie dziala'.
Jak wypada na tle innych podejść multi-agentowych
Orkiestracja multi-agentowa to zatłoczony buzzword. Oto co naprawdę dowozi i gdzie pasują AgentsRoom Teams.
Subagents Anthropica (Task tool, .claude/agents) pozwalają pojedynczej sesji Claude delegować do wyspecjalizowanych agentów-pomocników. Świetne do delegacji inline, ale sesja-rodzic pozostaje koordynatorem i pojedynczym kontekstem. AgentsRoom Teams są o poziom wyżej: każdy węzeł zespołu to osobna top-level sesja Claude z własnym oknem, własnym stanem, własnym scrollbackiem. CrewAI, AutoGen i LangGraph to świetne frameworki Python dla flow multi-agentowych, ale żyją poza Twoim IDE i nie uruchamiają prawdziwych Claude Code, Codex ani Antigravity CLI end-to-end na Twoim lokalnym repo. n8n, Make, Pipedream i Retool dostarczają ten sam typ canvas editora, którego my używamy, ale są platformami automatyzacji ogólnego przeznaczenia, niezbudowanymi pod agentów AI do kodowania. AgentsRoom Teams to canvasowy edytor workflow multi-agentowego, ale podpięty konkretnie do Twoich agentów CLI, Twojego projektu, Twojego git, Twoich terminali i Twojej przeglądarki.
Jeśli budujesz systemy agentowe w Pythonie, dalej używaj CrewAI lub LangGraph do produkcyjnych pipeline'ów. Jeśli dowozisz kod z Claude Code, Codex CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe lub Kimi Code, Agent Teams to workflow zespołowy, który działa tam, gdzie naprawdę kodujesz.
FAQ
Czym to się różni od subagents Claude Code (Task tool, .claude/agents)?
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.
Czy to działa tylko z Claude Code?
Działa z każdym dostawcą wspieranym przez AgentsRoom (Claude Code, Codex CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code). 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.
Co to jest payload handoff?
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.
Czy agenci mogą faktycznie chodzić tam i z powrotem (Dev do QA do Dev)?
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.
Co się stanie, jeśli QA będzie odrzucał Dev w nieskończoność?
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.
Czy wszyscy agenci zespołu współdzielą ten sam workspace git?
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.
Czy wymaga to dodatkowej subskrypcji?
Nie. Teams są częścią AgentsRoom. Przynosisz własne klucze dostawców (Claude, Codex, OpenCode, Antigravity, Aider, Grok Build, Mistral Vibe, Kimi Code) 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.
Gdzie są przechowywane zespoły? Czy są commitowane do gita?
Zespoly projektowe zyja z roomem, synchronizowane z twoim kontem i cache'owane w {project}/.agentsroom/teams-cache.json (gitignored). Zespoly globalne rowniez sa synchronizowane z twoim kontem: biblioteka podaza za toba miedzy maszynami, z ~/.agentsroom/teams/ jako cachem offline. Dolaczone szablony zostaja lokalne: kazda maszyna instaluje je we wlasnym jezyku.
Co jeśli agent crashuje albo aplikacja restartuje się w trakcie runa?
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 sie po restarcie aplikacji: orkiestrator wraca do aktywnego kroku, otwiera terminal na nowo, a agent odzyskuje kontekst z notatek i narzedzi zespolu. Uruchomienie, ktorego zespol usunieto, jest zamykane automatycznie zamiast wisiec w nieskonczonosc.
Czy mogę uruchomić kilka zespołów równolegle na różnych ticketach?
Tak. Kazde uruchomienie jest niezalezne, identyfikowane przez runId. Mozesz miec trzy rozne zespoly zywe na trzech ticketach tego samego projektu. Wewnatrz jednego uruchomienia przebieg podaza za twoim grafem: sekwencyjnie domyslnie, rownolegle tam, gdzie narysujesz rownolegle galezie (na przyklad QA i Security przegladajace jednoczesnie), zawsze z deterministycznym zlaczeniem.
Czy dwaj agenci naprawde moga dzialac jednoczesnie?
Tak. Narysuj dwa polaczenia bez warunku z jednego wezla, a oba cele dzialaja jako rownolegle galezie, kazdy we wlasnym agencie i terminalu. Galezie maja glebokosc jednego wezla i musza zbiegac sie we wspolnym wezle laczacym, co edytor waliduje przed uruchomieniem. Gdy kazda galaz skonczy, zlaczenie dostaje scalony payload: podsumowania opisane rolami, zdeduplikowane ryzyka i wskazowki testowe oraz flagi scalone regula fail-safe (konflikt boolowski rozstrzyga sie na false).
Jak dokladnie dzialaja bramki jakosci?
Wpisujesz polecenie shell na wezle, na przyklad npm test, i opcjonalnie nazwe flagi (domyslnie checkPassed). Gdy agent zglasza koniec kroku, AgentsRoom uruchamia polecenie w workspace z limitem pieciu minut. Kod wyjscia 0 zapisuje true do flagi, kazdy inny false, nadpisujac to, co agent zadeklarowal o sobie. Przy niepowodzeniu ostatnie kilobajty wyjscia wedruja do nastepnego agenta: powrot laduje z prawdziwym stack trace, a wynik widac na osi czasu uruchomienia.
Czy krok moze wczytac moje procedury ze Skills Library?
Tak. Kazdy wezel moze przypiac skille z twojej Skills Library, projektowej lub globalnej. Agent dostaje polecenie wczytania kazdego z nich przed rozpoczeciem kroku: checklista review, runbook wdrozenia czy procedura testowa sa stosowane przy kazdym uruchomieniu, zamiast zalezec od pamieci agenta.
Zbuduj swój wymarzony zespół AI do programowania
Cztery szablony w zestawie z aplikacja. Otworz AgentsRoom, postaw wezly, narysuj polaczenia, uruchom na dowolnym tickecie. Twoja zaloga inzynieryjna AI jest o klikniecie stad.
Aplikacja towarzyszaca: monitoruj agentów w podrozy
Użyj Claude, Codex, Antigravity CLI lub innego dostawcy AI.
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.
Spojrzenie na AgentsRoom w akcji.