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 swój wymarzony zespół AI do programowania na wizualnym canvasie, dokładnie jak workflow n8n. Krawędzie warunkowe, pętle feedback, retry, max-cycles guard. Zapisz raz, uruchamiaj na każdym tickecie i patrz, jak Twoi agenci podają sobie pałeczkę 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, Gemini CLI lub Aider 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, Gemini 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, Gemini 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.
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ć.
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.
Szablony zespołów w zestawie
Trzy szablony startowe są dostarczane z aplikacją: Dev do QA, Dev do QA z pętlą feedback i Dev do Security do QA. Duplikuj, edytuj, uruchamiaj. Zacznij 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.
Jak działa run zespołu
Otwórz zakładkę Teams
W widoku projektu zakładka Teams listuje trzy szablony startowe (Dev do QA, Dev do QA z pętlą feedback, Dev do Security do QA) plus dowolny zespół, który już zapisałeś. Zduplikuj szablon lub 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 kończy, AgentsRoom buduje payload handoff (podsumowanie feature'a przez agenta lub przez Haiku, git diff, ryzyka, podpowiedzi testowe, flagi), dopisuje notatkę do NOTES.md, wybiera właściwą krawędź wyjściową na podstawie flag i spawnuje agenta N+1 z tym payloadem jako kontekstem wejściowym.
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.
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 Gemini 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, Gemini CLI lub Aider, 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, Gemini CLI, Aider). 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, Gemini, Aider) 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?
Zespoły z scope projektu żyją z roomem, synchronizowane do chmury i cachowane w {project}/.agentsroom/teams-cache.json (gitignored). Zespoły globalne żyją w ~/.agentsroom/teams/{teamId}.json na Twojej maszynie, jeden plik na zespół. Decydujesz, który scope pasuje do każdego workflow.
Co jeśli agent crashuje albo aplikacja restartuje się w trakcie runa?
Stan runa jest persystowany na dysku w {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl). NOTES.md jest append-only, każdy zapis stanu jest atomowy. Agenci mogą wszystko odczytać w dowolnym momencie przez team_read_notes lub team_get_context. Warstwa orkiestracji jest hardenowana, żeby w pełni odtwarzać przerwany run przy restarcie aplikacji, ale historia na dysku jest już crash-safe.
Czy mogę uruchomić kilka zespołów równolegle na różnych ticketach?
Tak. Każdy run zespołu jest niezależny i identyfikowany przez swój runId. Możesz mieć zespół Dev do QA działający na tickecie A, zespół Dev do Security do QA na tickecie B i zespół PM do Architect do Dev na tickecie C, wszystkie żywe w tym samym projekcie. Wewnątrz pojedynczego runa wykonanie jest sekwencyjne (jeden węzeł aktywny naraz) dla przewidywalności.
Zbuduj swój wymarzony zespół AI do programowania
Trzy szablony są w komplecie z aplikacją. Otwórz AgentsRoom, upuszczaj węzły, rysuj krawędzie, uruchamiaj na dowolnym tickecie. Twoja ekipa AI inżynieryjna jest o jedno kliknięcie.
Aplikacja towarzyszaca: monitoruj agentów w podrozy
Działa z Claude, Codex, OpenCode, Gemini CLI i Aider
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.