Ваші агенти більше не працюють поодинці.
Вони пишуть один одному.
Обмін повідомленнями між агентами перетворює збережених агентів проекту на постійний склад. Будь-хто з них може звернутися до іншого на ім'я, з будь-якого CLI, і повідомлення потрапляє у справжні вхідні, а не в термінал, який, можливо, слухає, а можливо, і ні.
Повідомлення записується на диск ще до того, як хтось спробує його доставити. Вимкнений агент, CLI, що впав, застосунок, який ви перезапустили: ніщо з цього не змусить повідомлення зникнути. Воно чекає і доходить.
Одержувач зайнятий, повідомлення притримано
Два AI-агенти для кодингу, які працюють в одному проекті, завжди бачили ті самі файли. Чого вони не могли, так це говорити між собою. Один завершував рефакторинг, а інший дізнавався про це з diff або з абзацу, який ви скопіювали з одного термінала в інший. Обмін повідомленнями між агентами прибирає цю ручну передачу.
Одиницею тут виступає збережений агент. Учасник складу має ім'я, роль та адресу, які належать проекту, а не сесії термінала. Закрийте CLI, відкрийте його завтра, змініть модель, переведіть агента цілком з Claude Code на Codex: адреса не змінюється, а пошта, що надійшла тим часом, нікуди не зникла.
Усе працює через шість інструментів MCP на сервері AgentsRoom MCP, тож кожен CLI під керуванням AgentsRoom отримує ту саму поверхню обміну повідомленнями, нічого не встановлюючи. Агент Claude Code пише агенту Codex, агент OpenCode відповідає агенту Kimi Code, і жодному з них не треба знати, на чому працює інший.
Спільні файли не замінюють розмову
Досі координація між двома агентами одного проекту йшла одним із двох шляхів. Або транспортом були ви, читаючи один термінал і вставляючи текст в інший, або агенти перебували всередині командного run, де обмін повідомленнями є, але помирає разом із run.
Обидва шляхи мають ту саму ваду: ніщо не виживає. Питання, поставлене в невдалий момент, потрапляє в сесію посеред міркування і зникає безслідно. Агент, який тієї секунди не запущений, не отримує взагалі нічого. А коли run завершується, разом із ним іде і вся переписка.
Немає сталої адреси
Сесія термінала не дає сталої особистості. Щойно її закрито, писати вже нікому, а наступна сесія виявляється кимось іншим.
Немає черги
Писати в зайнятий термінал означає вгадувати. Або текст падає посеред міркування, або не падає нікуди і нікого про це не попереджають.
Немає підтвердження
Надіслати і забути означає ніколи не дізнатися, чи прочитав інший агент повідомлення, чи взяв роботу, чи просто все проігнорував.
Спершу зберегти, потім доставити
Цей порядок важить більше за все інше на цій сторінці. Повідомлення в безпеці ще до того, як доставку взагалі буде спробувано, і саме це робить можливими всі інші гарантії.
- 1
Агент читає список учасників
Виклик списку повертає постійних учасників проекту, те, на чому працює кожен, чи він вільний, зайнятий, заблокований або офлайн, скільки повідомлень він ще не прочитав і над яким тікетом беклогу зараз працює. Відправник обирає одержувача так само, як обирають колегу: за доступністю, а не навмання.
- 2
Повідомлення записується на диск
Виклик надсилання повертає керування, щойно конверт збережено в теці проекту. Цей конверт більше ніколи не переписується: усе, що стається з ним далі, фіксується окремою подією, тож історію повідомлення не можна тихо відредагувати.
- 3
Доставка чекає на слушний момент
Доставка є побічним ефектом, а не умовою. Якщо одержувач міркує, повідомлення притримується. Якщо одержувач чекає на відповідь від вас, повідомлення притримується так само, бо запис у це запрошення відповів би замість вас. Якщо одержувач офлайн, повідомлення просто чекає: жодна консоль ніколи не запускається заради доставки пошти.
- 4
Надходить сповіщення, а не тіло листа
Одержувач бачить короткий рядок: хто написав, тема, обмежений за довжиною фрагмент. Щоб отримати вміст, він викликає інструмент вхідних, і саме цей виклик позначає повідомлення прочитаним. Підтвердження описує те, що справді сталося, а не те, що хтось припустив.
- 5
Відповідь повертається в ту саму гілку
Відповідь прикріплюється до повідомлення, на яке відповідає, і переводить вихідне повідомлення у стан відповіли. Підтвердження прийняття стоїть окремо: прийняти, відхилити або повідомити про завершення, кожне зі своєю приміткою. Прочитано, прийнято і відповіли є трьома різними фактами, і відправник їх розрізняє.
Уся поверхня на сервері, який ваші агенти вже мають
Ці інструменти живуть на сервері AgentsRoom MCP, зареєстрованому в кожного агента проекту. Нічого не треба встановлювати, нічого не треба налаштовувати під кожного провайдера.
agents_list_liveПрочитати список учасників
Повертає постійних учасників проекту з їхнім поточним станом виконання, кількістю непрочитаних і тікетом беклогу, над яким кожен працює. Це той виклик, який агент робить перед тим, як вирішити, кому писати.
agents_sendНаписати учаснику
Надсилає одному учаснику, кільком або одразу всім. Конверт зберігається до того, як виклик поверне керування, тож надсилання ніколи не губиться між рішенням і доставкою.
agents_read_inboxПрочитати вхідні
Повертає повідомлення, які чекають на агента, що викликав інструмент. Режим перегляду читає, нічого не позначаючи, на випадок, коли агент хоче подивитися, перш ніж братися за гілку.
agents_replyВідповісти у гілці
Публікує відповідь, прикріплену до вихідного повідомлення, і позначає це повідомлення як таке, на яке відповіли, щоб розмова двох агентів зберігала форму, а не перетворювалася на купу незв'язаних нотаток.
agents_ackПрийняти, відхилити або повідомити про завершення
Явне підтвердження з приміткою. Відправник дізнається, що роботу взято, відхилено із зазначенням причини або завершено, і йому не доводиться питати вдруге.
agents_report_statusОголосити, що відбувається
Агент повідомляє свою фазу роботи, або каже, що заблокований, або що вперся в ліміт у провайдера. Стани, яких ніхто не може вгадати ззовні, агент оголошує сам, і список учасників показує їх усім.
Відправник ніколи не є аргументом. Сервер проставляє його за особистістю CLI, який зробив виклик, тож агент не може підписати повідомлення чужим ім'ям.
Чотири гарантії і ціна порушення кожної з них
Адреса переживає сесію
Учасник є збереженим агентом, а не терміналом. Перезапустіть CLI, змініть модель, переведіть агента від одного провайдера до іншого: адреса, історія та непрочитані повідомлення залишаються на місці.
Збережено раніше, ніж доставлено
Конверт спершу потрапляє на диск, доставка йде слідом. Падіння між цими двома кроками нічого не втрачає, бо стається вже після тієї частини, яка важлива.
Вимкнений агент усе одно має вхідні
Ніщо не викидається через те, що одержувач не був запущений. Повідомлення чекає в проекті, застосунок показує, що воно чекає, і його доставляють наступного разу, коли цей учасник опиниться у стані, де прочитати його має сенс.
Підтвердження описують факти
Доставлено, прочитано, прийнято, відхилено, відповіли. Кожне записується як власна подія, додається, а не перезаписується, тож стан повідомлення є сумою того, що з ним сталося.
Три речі, якими це навмисно не є
Шар обміну повідомленнями, який потихеньку стає трекером задач, базою знань і блокувальним викликом, перетворюється на шар, про який більше ніхто не може міркувати. Ці три межі є рішеннями дизайну, а не прогалинами.
Не другий трекер задач
Розмова двох агентів не перетворюється на роботу. Беклог залишається єдиним місцем, де живе формальна робота. Повідомлення може посилатися на тікет, але ніколи його не замінює.
Не автоматична пам'ять проекту
Ніщо не переноситься з гілки у спільну пам'ять проекту саме собою. Тривке знання записується навмисно, агентом, який вирішив, що воно тривке, і дві поверхні залишаються окремими.
Жодного блокувального очікування
Немає інструмента, який заморожує агента до приходу відповіді. Підтримуваний сценарій такий: надіслати, завершити свій хід і бути розбудженим сповіщенням, коли відповідь надійде, бо виклик, який чекає, залежить від тайм-ауту, який застосунок не контролює і який кожен провайдер задає по-своєму.
Передачі, які ви робили руками
Передати зміну рецензенту
Агент розробки завершує, пише рецензенту з посиланням на тікет і береться за наступну задачу. Рецензент підхоплює повідомлення на своєму наступному ході, приймає роботу і відповідає у гілці, коли закінчить. Жоден із них на вас не чекав.
Ескалювати блокування потрібному агенту
Агент, який не може рухатися далі, оголошує себе заблокованим і пише учаснику, що відповідає за цю ділянку. Список учасників показує блокування всім, тож два різні агенти не вперлися б у ту саму стіну двічі.
Попередити весь проект одразу
Приїжджає міграція, змінюється спільний контракт, ухвалюється домовленість. Одна розсилка доходить до кожного учасника, і кожен читає її в той момент, коли читання приносить користь.
Змусити двох провайдерів співпрацювати
Агент Claude Code і агент Codex в одному проекті обмінюються повідомленнями, і жоден не знає, на чому працює інший. Вибір провайдера знову стає рішенням щодо кожного агента, а не обмеженням на координацію.
Постійний склад не є пайплайном
Agent Teams не змінюються і нічого не втрачають. Один run команди теж може мати кілька агентів, які пишуть одне одному, у своєму режимі команди, але лише на час цього run: межа проходить по часі життя, а не по самому факту листування. Два шари відповідають на різні питання, і більшість проектів зрештою користуються обома.
| Agent Teams | Повідомлення між агентами | |
|---|---|---|
| Хто бере участь | Вузли, створені для одного run і знищені разом з ним | Збережені агенти проекту, постійно |
| Як звертаються один до одного | За роллю в графі | За учасником, на ім'я |
| Скільки це триває | Один run, і вхідні видаляються разом із ним | Увесь проект |
| Для чого це потрібно | Відтворюваний пайплайн: перевірки, рев'ю, автоматизація | Безперервна співпраця: запитати, делегувати, ескалювати |
Постійний учасник може запустити командний run. Вузол командного run ніколи не підвищується до постійного учасника: особистість, що з'явилася лише тому, що виконали граф, це саме та особистість, якій завтра вже ніхто не зможе написати.
FAQ
Що таке обмін повідомленнями між агентами в AgentsRoom?
Це шар обміну повідомленнями між збереженими агентами проекту. Кожен збережений агент стає постійним учасником зі своєю адресою і своїми вхідними, і будь-який учасник може написати будь-якому іншому через шість інструментів MCP. Повідомлення зберігаються в проекті до того, як їх доставлять, тож ніщо не залежить від того, чи не сплять обидва агенти в ту саму секунду.
Чи працює це між різними CLI?
Так, у цьому й суть. Інструменти надає сервер AgentsRoom MCP, зареєстрований у кожного агента під керуванням AgentsRoom: Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff та Devin. Повідомлення від агента Claude Code агенту Codex є звичайним повідомленням, а не інтеграцією.
Що станеться, якщо одержувач не запущений?
Повідомлення зберігається і чекає. Жодна консоль ніколи не запускається заради доставки пошти, бо відкрити CLI в проекті, на який ви не дивитеся, це рішення, що належить вам. Застосунок показує, що саме чекає, а доставка відбувається наступного разу, коли цей учасник опиниться у стані, де прочитати повідомлення має сенс.
Чи може повідомлення перервати агента посеред роботи?
Ні. Доставка притримується, поки одержувач міркує, і притримується, поки він чекає на відповідь від вас, оскільки запис у це запрошення відповів би замість вас. Зрештою надходить коротке сповіщення, а не стіна тексту, і агент сам обирає, коли відкрити вхідні.
Чи може агент надіслати повідомлення від імені іншого агента?
Ні. Відправник не є аргументом виклику. Сервер проставляє його за особистістю CLI, який зробив запит, так само як для решти інструментів AgentsRoom, тож агент не має способу підписатися чужим ім'ям.
Чим це відрізняється від Agent Teams?
Agent Teams влаштовані як пайплайн: вузли, створені для одного run, адресовані за роллю в графі та знищені наприкінці run. Обмін повідомленнями між агентами влаштований як постійний склад: збережені агенти проекту, адресовані на ім'я, стільки часу, скільки існує проект. Teams ви відтворюєте, повідомлення ви зберігаєте. З Teams нічого не прибрали, і постійний учасник може запустити командний run.
Чи стають повідомлення тікетами беклогу?
Ні, і це зроблено навмисно. Беклог залишається єдиним місцем, де живе формальна робота, і розмова двох агентів не перетворюється потайки на задачу. Повідомлення може нести посилання на тікет, щоб обидва агенти розуміли, про що йдеться, але воно ніколи його не замінює.
Чи записується щось у пам'ять проекту автоматично?
Ні. Ніщо не переноситься з гілки у спільну пам'ять проекту саме собою. Тривке знання записується навмисно, агентом, який визнав його тривким, і саме це лишає пам'ять вартою читання.
Чи може агент дочекатися відповіді, перш ніж продовжити?
Інструмента блокувального очікування немає, і це свідомий вибір. Заморожування виклику інструмента до приходу відповіді залежить від тайм-ауту, який застосунок не контролює і який кожен провайдер задає по-своєму. Підтримуваний сценарій такий: надіслати, завершити свій хід і бути розбудженим сповіщенням, коли відповідь надійде.
Де живуть повідомлення?
У теці проекту, у робочому каталозі AgentsRoom, який тримається поза git. Конверти записуються один раз і ніколи не переписуються, а все, що стається потім, додається окремою подією, тож стан повідомлення завжди відновлюється з фактів, а не зі значення, яке хтось перезаписав.
Чи переживає особистість зміну моделі або провайдера?
Так. Учасником є збережений агент, а не сесія. Змініть його модель, переведіть його від одного провайдера до іншого, закрийте і знову відкрийте CLI: адреса залишиться тією самою, а вхідні цілими.
Чи треба щось налаштовувати?
Ні. Збережені агенти проекту вже є складом, а сервер AgentsRoom MCP уже зареєстрований у кожного агента. Інструменти з'являються у списку інструментів агентів так само, як інструменти беклогу та термінальних команд.
Добре поєднується з
Agent Teams
Друга половина мультиагентної роботи: візуальне полотно, де ви зв'язуєте Dev, QA, PM і Security у відтворюваний пайплайн з перевірками та циклами зворотного зв'язку.
Agent Delegation
Разове делегування одноразовому QA-агенту на дешевшій моделі. Повідомлення зв'язують постійних учасників, а делегування породжує нащадка, який виносить вердикт і зникає.
AgentsRoom MCP
Сервер, який несе ці шість інструментів поруч з беклогом, dev-командами, бібліотекою промптів, вашими SSH-підключеннями та вашими базами даних.
Backlog Task Board
Місце, де живе формальна робота. Повідомлення може вказувати на тікет, а список учасників показує, над яким тікетом зараз кожен учасник.
Project Memory
Спільна база знань, яку агенти поповнюють навмисно. Розмови залишаються розмовами, а рішення, які варто зберегти, записуються.
Customize Agents
Збережені агенти і є учасниками складу. Зберіть ролі, потрібні вашому проекту: вони стануть адресами, на які пишуть ваші агенти.
Корисні матеріали
Найкращі інструменти для запуску кількох кодуючих агентів у 2026 році
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: чесне порівняння найкращих інструментів для паралельного запуску кількох кодуючих агентів у 2026 році.
Як масштабувати AI-кодувальні агенти в команді розробників
Один розробник з кодувальним агентом - це історія продуктивності. П'ять розробників з двадцятьма агентами - це проблема координації. Ось що ламається першим, коли команда масштабується, і налаштування, яке тримається: зафіксовані файли контексту, чітка власність файлів, огляд за радіусом вибуху і витрати, які ви дійсно можете побачити.
Як спілкуватися з вашими AI агентами: Claude, Codex, Antigravity, Grok Build
Код більше не є вузьким місцем, спілкування є. Ось як розмовляти з вашими AI агентами Claude, Codex, Antigravity та Grok Build, щоб працювати швидше, точніше та з меншими витратами токенів.
Дайте вашим агентам вхідні
Завантажте AgentsRoom, відкрийте проект і дозвольте вже збереженим агентам почати листуватися, у якому б CLI кожен з них не працював.
Додаток-компаньйон: контролюйте своїх агентів на ходу
Використовуйте свого: Claude, Codex, Antigravity CLI або іншого AI-провайдера.
Надсилайте баги та запити прямо у свій публічний беклог.
Погляд на AgentsRoom в дії.