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 sześć 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, a nie warunkiem. Jeśli odbiorca myśli, wiadomość zostaje wstrzymana. Jeśli odbiorca czeka na odpowiedź od ciebie, wiadomość też zostaje wstrzymana, bo pisanie w ten prompt byłoby odpowiedzią w twoim imieniu. Jeśli odbiorca jest offline, wiadomość po prostu czeka: żadna konsola nie jest uruchamiana po to, żeby dostarczyć pocztę.
- 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_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.
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.
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 sześć 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 i Devin. 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ść zostaje zapisana i czeka. Żadna konsola nie jest uruchamiana po to, żeby dostarczyć pocztę, bo otwarcie CLI w projekcie, na który nie patrzysz, to decyzja, która należy do ciebie. Aplikacja pokazuje, co czeka, a dostarczenie następuje przy najbliższej okazji, gdy ten członek jest w stanie, w którym czytanie ma sens.
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.
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 sześć 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.
Spojrzenie na AgentsRoom w akcji.