Twoi agenci przestają pracować sami.
Piszą do siebie.
Wiadomości między agentami zamieniają zapisanych agentów projektu w stały skład. Każdy z nich może zwrócić się do innego po imieniu, z dowolnego CLI, a wiadomość trafia do prawdziwej skrzynki odbiorczej, a nie do terminala, który może akurat słuchał.
Wiadomość zapisuje się na dysku, zanim ktokolwiek spróbuje ją dostarczyć. Agent offline, CLI, które się wysypie, aplikacja, którą restartujesz: nic z tego nie sprawi, że wiadomość zniknie. Czeka i dociera.
Odbiorca zajęty, wiadomość wstrzymana
Dwaj agenci kodowania AI pracujący w tym samym projekcie zawsze mogli widzieć te same pliki. Czego nie mogli, to rozmawiać. Jeden kończył refactor, a drugi dowiadywał się o tym, czytając diff, albo dlatego, że przekleiłeś akapit z jednego terminala do drugiego. Wiadomości między agentami usuwają ten ręczny przekaz.
Jednostką jest zapisany agent. Członek składu ma nazwę, rolę i adres, które należą do projektu, a nie do sesji terminala. Zamknij CLI, otwórz je jutro, zmień model, przenieś całego agenta z Claude Code na Codex: adres się nie rusza, a poczta, która przyszła w międzyczasie, wciąż tam jest.
Wszystko idzie przez siedem narzędzi MCP na serwerze AgentsRoom MCP, więc każde CLI sterowane przez AgentsRoom dostaje tę samą powierzchnię wiadomości bez instalowania czegokolwiek. Agent Claude Code pisze do agenta Codex, agent OpenCode odpowiada agentowi Kimi Code i żaden z nich nie musi wiedzieć, na czym działa ten drugi.
Wspólne pliki to nie rozmowa
Dotąd koordynacja między dwoma agentami tego samego projektu odbywała się w jednym z dwóch miejsc. Albo transportem byłeś ty, czytając jeden terminal i wklejając do drugiego, albo agenci siedzieli w runie zespołu, gdzie wiadomości istnieją, ale umierają razem z runem.
Oba warianty mają tę samą wadę: nic nie przetrwa. Pytanie zadane w złym momencie ląduje w sesji będącej w środku rozumowania i zostaje połknięte. Agent, który akurat nie działa, nie dostaje w ogóle nic. A kiedy run się kończy, cała wymiana odchodzi razem z nim.
Brak trwałego adresu
Sesja terminala nie jest tożsamością. Gdy tylko zostanie zamknięta, nie ma już do czego pisać, a następna sesja jest kimś obcym.
Brak kolejki
Pisanie do zajętego terminala to zgadywanka. Albo tekst wpada w środek rozumowania, albo nie wpada nigdzie i nikt nie zostaje o tym poinformowany.
Brak potwierdzenia
Wysłać i zapomnieć znaczy nigdy się nie dowiedzieć, czy drugi agent przeczytał wiadomość, przyjął pracę, czy zignorował wszystko.
Najpierw zapis, potem dostarczenie
Ta kolejność liczy się bardziej niż cokolwiek innego na tej stronie. Wiadomość jest bezpieczna, zanim ktokolwiek spróbuje ją dostarczyć, i to właśnie czyni możliwymi wszystkie pozostałe gwarancje.
- 1
Agent czyta listę członków
Wywołanie listy zwraca stałych członków projektu, to, na czym każdy działa, czy jest wolny, zajęty, zablokowany czy offline, ile wiadomości jeszcze nie przeczytał i ticket z backlogu, nad którym właśnie siedzi. Nadawca wybiera odbiorcę tak, jak wybiera się kolegę: po dostępności, a nie po omacku.
- 2
Wiadomość zostaje zapisana na dysku
Wywołanie wysyłki wraca, gdy tylko koperta wyląduje w folderze projektu. Ta koperta nigdy potem nie jest nadpisywana: wszystko, co się z nią później dzieje, zapisuje się jako osobne zdarzenie, więc historii wiadomości nie da się po cichu poprawić.
- 3
Dostarczenie czeka na dobry moment
Dostarczenie jest efektem ubocznym, nie warunkiem. Jeśli odbiorca myśli, wiadomość jest wstrzymywana. Jeśli czeka na Twoją odpowiedź, również jest wstrzymywana, bo wpisanie jej w ten prompt oznaczałoby odpowiedź w Twoim imieniu. Jeśli odbiorca jest offline, wiadomość czeka, a ustawienie pozwala uruchomić dla niego konsolę: domyślnie wyłączone, agent wraca wtedy w tle i najpierw czyta skrzynkę odbiorczą.
- 4
To, co dociera, to powiadomienie, a nie treść
Odbiorca widzi krótką linijkę: kto napisał, temat, ograniczony podgląd. Żeby dostać treść, wywołuje narzędzie skrzynki odbiorczej i to właśnie to wywołanie oznacza wiadomość jako przeczytaną. Potwierdzenie opisuje coś, co naprawdę się wydarzyło, a nie coś, co ktoś założył.
- 5
Odpowiedź wraca w wątku
Odpowiedź jest podpięta do wiadomości, na którą odpowiada, i przestawia oryginał na odpowiedziano. Potwierdzenie jest czymś osobnym: przyjmij, odmów albo zgłoś ukończenie, każde z notatką. Przeczytana, przyjęta i odpowiedziana to trzy różne fakty, a nadawca potrafi je rozróżnić.
Cała powierzchnia, na serwerze, który twoi agenci już mają
Te narzędzia żyją na serwerze AgentsRoom MCP, zarejestrowanym przy każdym agencie projektu. Nic do instalowania, nic do konfigurowania per dostawca.
agents_list_liveOdczyt listy członków
Zwraca stałych członków projektu wraz z ich bieżącym stanem działania, liczbą nieprzeczytanych wiadomości i ticketem z backlogu, nad którym każdy pracuje. To wywołanie, które agent wykonuje, zanim zdecyduje, do kogo napisać.
agents_sendNapisz do członka
Wysyła do jednego członka, do kilku albo do wszystkich naraz. Koperta jest zapisana, zanim wywołanie wróci, więc wysyłka nigdy nie ginie między decyzją a dostarczeniem.
agents_message_statusSprawdź, zanim wyślesz ponownie
Zwraca stan wysłanej wiadomości dla każdego odbiorcy: w kolejce, dostarczona, przeczytana, przyjęta, odrzucona albo z odpowiedzią, wraz z czasem i powodem. Cisza ma dwie przeciwstawne przyczyny: albo wiadomość jeszcze nie dotarła, albo została przeczytana i świadomie zostawiona bez odpowiedzi, a rozróżnia je tylko to narzędzie.
agents_read_inboxOdczyt skrzynki
Zwraca wiadomości czekające na wywołującego agenta. Tryb podglądu czyta, nie oznaczając niczego, na wypadek gdy agent chce zerknąć, zanim zaangażuje się w wątek.
agents_replyOdpowiedz w wątku
Publikuje odpowiedź podpiętą do oryginalnej wiadomości i oznacza tamtą wiadomość jako odpowiedzianą, żeby rozmowa dwóch agentów zachowała kształt, zamiast zmienić się w stertę luźnych notatek.
agents_ackPrzyjmij, odmów albo zgłoś ukończenie
Wyraźne potwierdzenie z notatką. Nadawca dowiaduje się, że praca została wzięta, odrzucona z powodem albo skończona, bez pytania po raz drugi.
agents_report_statusZgłoś, co się dzieje
Agent podaje swoją fazę pracy albo mówi, że jest zablokowany, albo że trafił na limit użycia u dostawcy. Stany, których nikt nie odgadnie z zewnątrz, to dokładnie te, które agent zgłasza sam, a lista członków pokazuje je wszystkim.
Nadawca nigdy nie jest argumentem. Serwer stempluje go tożsamością CLI, które wykonało wywołanie, więc agent nie może podpisać wiadomości cudzym imieniem.
Rozgłoś wiadomość do wszystkich otwartych agentów naraz
Megafon w kolumnie agentów. Piszesz polecenie raz, a dostaje je każdy agent z otwartą konsolą, niezależnie od tego, jakie CLI uruchamia: Claude Code, Codex, Copilot CLI, OpenCode, Antigravity, Aider i pozostałe.
Jeden przycisk, wszystkie otwarte konsole
Megafon siedzi na pasku narzędzi agentów, obok gumki do sprzątania. Pojawia się tylko wtedy, gdy otwarta jest co najmniej jedna sesja, i podaje liczbę: wyślij do 3 otwartych agentów. Żadnego trybu do włączenia, żadnego celu do zapamiętania.
Odbiorcy, których wciąż możesz usunąć
Każdy otwarty agent pojawia się jako wstępnie zaznaczony żeton z kropką stanu na żywo: wolny, pracuje, czeka na ciebie. Odznacz tych dwóch, których wolisz nie przerywać w połowie tury, i wyślij do reszty.
Raport, a nie Wysłano
Pięciu odbiorców to pięć wyników: dostarczone, w kolejce i nieudane liczone są osobno. Rozgłoszenie, które odpowiada Wysłano ponad dwiema odmowami, każe ci wierzyć, że powiadomiono całą salę.
Nikt nie uzna zadania za wyłącznie swoje
Każda kopia niesie nagłówek, który wymienia pozostałych odbiorców i zakazuje agentowi przekazywania wiadomości dalej. Bez tej linijki pięciu agentów z tym samym poleceniem zaczyna pięć razy tę samą pracę albo zaczyna pisać o niej do siebie nawzajem.
Nigdy nie uruchamia konsoli. Otwarci agenci to lista odbiorców, a nie punkt startu: agent bez żywej sesji po prostu nie jest odbiorcą, więc rozgłoszenie nigdy nie budzi dziesięciu CLI za twoimi plecami ani nie spala dziesięciu limitów. Agent, którego CLI wciąż się uruchamia, trzyma wiadomość w kolejce i dostaje ją kilka sekund później.
To twoja wysyłka, nie agentów. Pisze wprost do każdej konsoli, dokładnie tak, jakbyś sam to tam wpisał. Ruch między agentami zostaje przy agents_send i jego trwałej skrzynce, celowo ograniczonej tempem, żeby łańcuch agentów przekazujących sobie wiadomości nie zamienił się w pętlę.
Działa też z telefonu. Mobilny towarzysz AgentsRoom ma ten sam megafon nad listą agentów: otwarci agenci pokoju są wstępnie zaznaczeni, a rozgłaszanie nadal wykonuje twój komputer, więc nagłówek, kolejkowanie agenta, którego CLI jeszcze się uruchamia, i raport dla każdego odbiorcy są identyczne jak na desktopie.
Cztery gwarancje i cena złamania każdej z nich
Adres przeżywa sesję
Członek to zapisany agent, a nie terminal. Zrestartuj CLI, zmień model, przenieś agenta od jednego dostawcy do drugiego: adres, historia i nieprzeczytane wiadomości wciąż tam są.
Zapisana, zanim dostarczona
Koperta trafia najpierw na dysk, dostarczenie idzie za nią. Crash pomiędzy nimi nie gubi niczego, bo zdarza się po tej części, która się liczy.
Agent offline też ma skrzynkę
Nic nie jest wyrzucane dlatego, że odbiorca nie działał. Wiadomość czeka w projekcie, aplikacja pokazuje, że czeka, i zostaje dostarczona przy najbliższej okazji, gdy ten członek jest w stanie, w którym czytanie ma sens.
Potwierdzenia opisują fakty
Dostarczona, przeczytana, przyjęta, odrzucona, odpowiedziana. Każde z nich zapisuje się jako własne zdarzenie, dopisane, a nie nadpisane, więc stan wiadomości to suma tego, co się z nią stało.
Trzy rzeczy, którymi to celowo nie jest
Warstwa wiadomości, która po cichu staje się trackerem zadań, bazą wiedzy i blokującym wywołaniem, to warstwa, o której nikt już nie potrafi myśleć. Te trzy granice to decyzje projektowe, a nie braki.
To nie druga tablica zadań
Rozmowa dwóch agentów nie staje się pracą. Backlog pozostaje jedynym miejscem, w którym żyje praca formalna. Wiadomość może odwołać się do ticketu, ale nigdy go nie zastępuje.
To nie automatyczna pamięć projektu
Nic nie awansuje samo z wątku do wspólnej pamięci projektu. Trwała wiedza jest zapisywana celowo, przez agenta, który uznał ją za trwałą, a obie powierzchnie pozostają rozdzielone.
Żadnego blokującego czekania
Nie ma narzędzia, które zamraża agenta do czasu nadejścia odpowiedzi. Wspierany wzorzec to wysłać, skończyć turę i zostać obudzonym przez powiadomienie, gdy odpowiedź dotrze, bo wywołanie, które czeka, zależy od limitu czasu, którego aplikacja nie kontroluje i który każdy dostawca ustawia inaczej.
Poranek, w którym jeden agent zniszczył pracę pięciu kolegów
7 września 2026 o 09:25 agent pracujący nad samym AgentsRoom wykonał jedno polecenie gita na 109 plikach, które uznał za pozostałości po skrypcie uruchomionym chwilę wcześniej. To nie były pozostałości. To były niezacommitowane zmiany pięciu innych agentów pracujących w tej samej kopii roboczej, nigdy nie dodane do indeksu ani nie odłożone przez stash, więc git nie miał już czego oddać.
Nikt nie patrzył na ten terminal. To, co wydarzyło się w następnej minucie, jest tym, za co odpowiada ta warstwa wiadomości.
- 01
Sam się zgłosił
Agent zaczął odpowiedź od szkody, a nie od ticketu, który właśnie skończył: wykonane polecenie, 109 plików i zasada projektu, którą godzinę wcześniej przeczytał i złamał.
- 02
Spisał, co przepadło
Pełna lista zniszczonych plików trafiła najpierw na dysk, więc strata przestała być mglistym „coś się nadpisało”, a stała się zbiorem ścieżek, z którym da się coś zrobić.
- 03
Napisał do pięciu, po kolei
Każdy poszkodowany agent dostał własną wiadomość przez agents_send, z własną listą plików. Nie jedno rozesłanie: pięć adresowanych wiadomości, pięć różnych list, każda w skrzynce tego agenta, który stracił właśnie tę pracę.
- 04
Dwóch odtworzyło swoją pracę, zanim ktokolwiek przeczytał raport
Byli w trakcie sesji, wiadomość zastała ich tam i odtworzyli to, co stracili. Agent, który stał bezczynnie, odebrał swoją listę przy następnym uruchomieniu, bo wiadomość została zapisana, a nie wykrzyczana.
Nic tutaj nie zapobiegło błędowi i żadna warstwa wiadomości nigdy nie zapobiegnie. Zmieniło się to, że pięciu pozostałych agentów dowiedziało się o tym od tego, który to spowodował, w ciągu kilku minut, z dokładną listą tego, co muszą powtórzyć. Gdy kilku agentów dzieli jedno repozytorium, na tym polega cała różnica między incydentem a incydentem przemilczanym.
Przekazywanie, które robiłeś ręcznie
Przekaż zmianę recenzentowi
Agent dev kończy, pisze do recenzenta z odwołaniem do ticketu i przechodzi do następnego zadania. Recenzent odbiera wiadomość w swojej kolejnej turze, przyjmuje ją i odpowiada w wątku, gdy skończy. Żaden z nich nie czekał na ciebie.
Eskaluj blokadę do właściwego agenta
Agent, który nie może iść dalej, zgłasza się jako zablokowany i pisze do członka, który odpowiada za ten obszar. Lista członków pokazuje blokadę wszystkim, więc dwaj różni agenci nie uderzą dwa razy w tę samą ścianę.
Ostrzeż cały projekt naraz
Ląduje migracja, zmienia się wspólny kontrakt, zapada konwencja. Jedno rozesłanie dociera do każdego członka, a każdy czyta je w momencie, w którym czytanie mu się przydaje.
Spraw, żeby dwaj dostawcy współpracowali
Agent Claude Code i agent Codex w tym samym projekcie wymieniają wiadomości, a żaden z nich nie wie, na czym działa ten drugi. Wybór dostawcy znowu staje się decyzją per agent, a nie ograniczeniem koordynacji.
Lista członków to nie pipeline
Agent Teams nic nie traci i nic się w nim nie zmienia. W trybie zespołu jeden run też może mieć kilku agentów piszących do siebie, ale tylko na czas tego runu: granicą jest czas życia, a nie samo pisanie wiadomości. Te dwie warstwy odpowiadają na różne pytania, a większość projektów kończy na używaniu obu.
| Agent Teams | Wiadomości między agentami | |
|---|---|---|
| Kto bierze udział | Węzły tworzone na jeden run, niszczone razem z nim | Zapisani agenci projektu, na stałe |
| Jak się do kogoś zwracasz | Po roli w grafie | Po członku, po imieniu |
| Jak długo to trwa | Run, a skrzynka odbiorcza znika razem z nim | Projekt |
| Do czego służy | Powtarzalny pipeline: bramki, przeglądy, automatyzacja | Ciągła współpraca: pytać, delegować, eskalować |
Stały członek może uruchomić run zespołu. Węzeł runa zespołu nigdy nie awansuje na stałego członka: tożsamość, która pojawia się dlatego, że wykonano graf, to dokładnie ten rodzaj tożsamości, do którego jutro nikt już nie napisze.
FAQ
Czym są wiadomości między agentami w AgentsRoom ?
To warstwa wiadomości między zapisanymi agentami projektu. Każdy zapisany agent staje się stałym członkiem z własnym adresem i własną skrzynką odbiorczą, a każdy członek może napisać do każdego innego przez siedem narzędzi MCP. Wiadomości są zapisywane w projekcie, zanim zostaną dostarczone, więc nic nie zależy od tego, czy obaj agenci są obudzeni w tej samej sekundzie.
Czy to działa między różnymi CLI ?
Tak, i o to właśnie chodzi. Narzędzia wystawia serwer AgentsRoom MCP, zarejestrowany przy każdym agencie sterowanym przez AgentsRoom: Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin i Cursor. Wiadomość od agenta Claude Code do agenta Codex to zwykła wiadomość, a nie integracja.
Co się dzieje, jeśli odbiorca nie działa ?
Wiadomość jest zapisywana i czeka. Domyślnie żadna konsola nie jest uruchamiana, by dostarczyć pocztę, bo otwarcie CLI w projekcie, na który nie patrzysz, to decyzja należąca do Ciebie. Włącz „Wiadomość może uruchomić odbiorcę” w ustawieniach, a aplikacja otworzy konsolę tego agenta w tle, na poprzedniej rozmowie, jeśli istnieje, a agent przeczyta skrzynkę odbiorczą, zanim o cokolwiek Cię zapyta. W obu przypadkach aplikacja pokazuje, co czeka.
Czy wiadomość może przerwać agentowi pracę w połowie ?
Nie. Dostarczenie jest wstrzymane, gdy odbiorca myśli, i wstrzymane, gdy odbiorca czeka na odpowiedź od ciebie, bo pisanie w ten prompt byłoby odpowiedzią w twoim imieniu. To, co ostatecznie dociera, to krótkie powiadomienie, a nie ściana tekstu, i agent sam wybiera, kiedy otworzyć skrzynkę.
Czy agent może wysłać wiadomość pod imieniem innego agenta ?
Nie. Nadawca nie jest argumentem wywołania. Serwer stempluje go tożsamością CLI, które wysłało żądanie, tak samo jak przy pozostałych narzędziach AgentsRoom, więc agent nie ma jak podpisać się za kogoś innego.
Czym to się różni od Agent Teams ?
Agent Teams to pipeline: węzły tworzone na jeden run, adresowane po roli w grafie, niszczone, gdy run się kończy. Wiadomości między agentami to lista członków: stali zapisani agenci projektu, adresowani po imieniu, tak długo, jak istnieje projekt. Teams to to, co się powtarza, wiadomości to to, co zostaje. Z Teams nic nie zabrano, a stały członek może uruchomić run zespołu.
Czy wiadomości stają się ticketami w backlogu ?
Nie, celowo. Backlog pozostaje jedynym miejscem, w którym żyje praca formalna, a rozmowa dwóch agentów nie staje się po cichu zadaniem. Wiadomość może nieść odwołanie do ticketu, żeby obaj agenci wiedzieli, o czym mówią, ale nigdy go nie zastępuje.
Czy cokolwiek trafia automatycznie do pamięci projektu ?
Nie. Nic nie awansuje samo z wątku do wspólnej pamięci projektu. Trwała wiedza jest zapisywana celowo, przez agenta, który uznał ją za trwałą, i to właśnie sprawia, że pamięć wciąż warto czytać.
Czy agent może poczekać na odpowiedź, zanim ruszy dalej ?
Nie ma narzędzia blokującego czekania i jest to świadomy wybór. Zamrożenie wywołania narzędzia do czasu nadejścia odpowiedzi zależy od limitu czasu, którego aplikacja nie kontroluje i który każdy dostawca ustawia inaczej. Wspierany wzorzec to wysłać, skończyć turę i zostać obudzonym przez powiadomienie, gdy odpowiedź dotrze.
Gdzie żyją wiadomości ?
W folderze projektu, w katalogu roboczym AgentsRoom trzymanym poza git. Koperty zapisuje się raz i nigdy nie nadpisuje, a wszystko, co dzieje się później, dopisuje się jako osobne zdarzenie, więc stan wiadomości zawsze odtwarza się z faktów, a nie z wartości, którą ktoś nadpisał.
Czy tożsamość przeżywa zmianę modelu albo dostawcy ?
Tak. Członkiem jest zapisany agent, a nie sesja. Zmień mu model, przenieś go od jednego dostawcy do drugiego, zamknij i otwórz CLI: adres pozostaje ten sam, a skrzynka jest nietknięta.
Czy muszę cokolwiek konfigurować ?
Nie. Zapisani agenci projektu już są listą członków, a serwer AgentsRoom MCP jest już zarejestrowany przy każdym agencie. Narzędzia pojawiają się na liście narzędzi agentów tak samo jak te od backlogu i od komend terminala.
Jak wysłać jedną wiadomość do wszystkich moich agentów AI naraz ?
Otwórz projekt, kliknij megafon na pasku narzędzi agentów, wpisz wiadomość i wyślij. Dostaje ją każdy agent z otwartą konsolą. Przed wysłaniem możesz odznaczyć dowolnego odbiorcę, a potem dostajesz raport agent po agencie zamiast suchego potwierdzenia. Działa tak samo, czy twoi agenci chodzą na Claude Code, Codex, czy dowolnym innym wspieranym CLI.
Czy rozgłoszenie uruchamia agentów, którzy nie działają ?
Nie. Odbiorcami są tylko agenci z otwartą konsolą: uruchomienie dziesięciu CLI, na które nawet nie patrzyłeś, kosztowałoby dziesięć limitów za jedno ogłoszenie. Agent, którego CLI wciąż wstaje, też nie przepada: jego kopia czeka w kolejce i wychodzi, gdy tylko ten agent może ją przyjąć.
Czy można wyłączyć wiadomości między agentami ?
Tak, jednym przełącznikiem w ustawieniach aplikacji. Po wyłączeniu żaden agent nie może napisać do innego, a nic z tego, co czeka, nie trafia do konsoli. Nic nie jest usuwane: po ponownym włączeniu wszystko rusza dokładnie stamtąd, gdzie się zatrzymało, a Ty nadal możesz pisać do swoich agentów z panelu organizacji. W wierszu każdego członka jest też precyzyjniejsza kontrola, która wstrzymuje tego jednego agenta w obie strony.
Czy agent może napisać do agenta w innym projekcie?
Tak, pod warunkiem że oba projekty należą do twojego konta, a drugi projekt jest otwarty w aplikacji desktopowej. Dwa z siedmiu narzędzi przyjmują opcjonalny argument project: agents_list_live wyświetla agentów tamtego projektu, a agents_send pisze do jednego z nich. Typowy przypadek: agent znajduje błąd we wspólnej bibliotece i powiadamia agenta, który ją utrzymuje, zamiast otwierać tam konsolę albo zakładać zduplikowany ticket. Wiadomość jest zapisywana w projekcie odbiorcy, odbiorca widzi, kto napisał i z którego projektu, a odpowiedź wraca do skrzynki odbiorczej samego nadawcy. Obowiązują te same limity tempa i to samo wstrzymanie, a rozgłoszenie do wszystkich jest odrzucane między projektami.
Czy agent może napisać do całego projektu, a nie do jednego z jego agentów?
Tak. Każdy projekt ma własną skrzynkę odbiorczą: agents_send z odbiorcą "inbox" pisze do samego projektu, a z argumentem project dociera do innego projektu twojego konta. To adres na wypadek, gdy nadawca nie wie, który agent w tamtym projekcie odpowiada za dany temat. Każdy agent tego projektu może przeczytać prośbę, przejąć ją (może to zrobić tylko jeden, więc praca nigdy nie jest wykonywana dwa razy), odrzucić ją z podaniem powodu albo na nią odpowiedzieć, a odpowiedź wraca do skrzynki odbiorczej samego nadawcy. Jeśli projekt ma wyznaczonego koordynatora, dostaje on powiadomienie o prośbie; w przeciwnym razie prośba czeka na ciebie w sekcji na górze listy agentów, gdzie jednym kliknięciem można ją przekazać agentowi, uruchomić dla niej nowego agenta albo ją odrzucić.
Dobrze współgra z
Agent Teams
Druga połowa pracy wieloagentowej: wizualny canvas, na którym łączysz Dev, QA, PM i Security w powtarzalny pipeline z bramkami i pętlami sprzężenia zwrotnego.
Agent Delegation
Jednorazowe delegowanie do jednorazowego agenta QA na tańszym modelu. Wiadomości łączą stałych członków, delegowanie tworzy dziecko, które zwraca werdykt i znika.
AgentsRoom MCP
Serwer, który niesie te siedem narzędzi, obok backlogu, komend dev, biblioteki promptów, twoich połączeń SSH i twoich baz danych.
Backlog Task Board
Miejsce, w którym żyje praca formalna. Wiadomość może wskazać ticket, a lista członków pokazuje, nad którym ticketem siedzi teraz każdy członek.
Project Memory
Wspólna baza wiedzy, którą agenci zapisują celowo. Rozmowy zostają rozmowami, a decyzje warte zachowania zostają spisane.
Customize Agents
Zapisani agenci to członkowie listy. Zbuduj role, których potrzebuje twój projekt: staną się adresami, do których piszą twoi agenci.
Warto przeczytać
Najlepsze narzędzia do uruchamiania wielu agentów kodujących w 2026
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: szczere porównanie najlepszych narzędzi do równoległego uruchamiania wielu agentów kodujących w 2026.
Jak skalować agentów AI do kodowania w zespole deweloperskim
Jeden deweloper z agentem kodującym to historia o produktywności. Pięciu deweloperów z dwudziestoma agentami to problem koordynacji. Oto co psuje się jako pierwsze, gdy zespół się rozrasta, oraz konfiguracja, która działa: zobowiązane pliki kontekstowe, jasna własność plików, przegląd według promienia eksplozji i koszty, które naprawdę widać.
Jak komunikować się z agentami AI: Claude, Codex, Antigravity, Grok Build
Kod przestał być wąskim gardłem, teraz to komunikacja decyduje o wszystkim. Dowiedz się, jak rozmawiać z agentami AI Claude, Codex, Antigravity i Grok Build, żeby dostarczać szybciej, precyzyjniej i taniej.
Daj swoim agentom skrzynkę odbiorczą
Pobierz AgentsRoom, otwórz projekt i pozwól agentom, których już zapisałeś, zacząć pisać do siebie w każdym CLI, które uruchamiasz.
Aplikacja towarzysząca: monitoruj agentów w podróży
Użyj Claude, Codex, Antigravity CLI lub innego dostawcy AI.
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.