Вітаємо на черговій порції знань. Уявіть, що ви керуєте компанією і найняли команду геніальних фахівців, першокласного плановальника подорожей, експерта з адаптації персоналу та спеціаліста з іТ-підтримки. Але ніхто з них не спілкується один з одним. Щоразу, коли завдання потребує участі двох із них, вам доводиться ходити між столами і самому передавати інформацію. Саме так зараз працює більшість AI-агентів. Вони діють ізольовано, навіть коли для вирішення проблеми явно потрібна командна робота. Тож сьогодні ми поговоримо про те, як агенти можуть спілкуватися, передавати роботу та діяти як справжні команди. Я – Мірко Петерс. Це не якась футуристична концепція. Мультиагентна оркестрація вже відбувається. І вона працює завдяки протоколу під назвою A2AI. Ми почнемо з проблеми, розберемо цей протокол по частинах і подивимося, як Майкрософт використовує його в Coopilot Studio та Azure AI. Беріть каву і погнали.

Отже, у чому справжня проблема? Сьогоднішні AI-агенти – це точно такі ж ізольовані фахівці. Кожен має власні знання, інструменти та цілі. Агент прогнозу погоди знає прогноз. Агент готелів знає про наявність місць, але вони нічим не діляться. Тепер уявіть користувача, який планує поїздку до Сіятла наступного тижня і шукає готель біля офісу. Єдиний агент мав би одночасно бути експертом з погоди, подорожей і місцевого бізнесу. Це означає величезні роздуті запити, які намагаються втиснути всі можливості в одну систему, і такі запити постійно ламаються. Старим рішенням був спеціальний програмний код. Ви писали міст між агентом погоди та агентом готелів, потім ще один між готельним і авіаційним агентами, і ще один для агента календаря. Спочатку це працює, але щоразу, коли ви додаєте нового агента, ви будуєте ще одну інтеграцію. Дуже скоро ви отримуєте спагеті-кошмар із прямих з'єднань, де одна зміна ламає все.

Зростання продуктивності, яке мав забезпечити AI, з'їдається роботою з обслуговування системи. Давайте подивимося на реальний бізнес-біль. У вашій організації вже є процеси з передачею завдань. Створюється тікет, хтось його сортує, хтось вирішує, хтось реєструє, і кожен крок є етапом передачі. У старому світі ви автоматизуєте кожен крок окремим агентом, а потім тижнями витрачаєте час, щоб з'єднати їх між собою. Але що, якби існував протокол, який дозволяв би агентам знаходити один одного та співпрацювати без жодних спеціальних мостів? Це саме те, що робить A2A. Простою мовою, A2A – це стандартний спосіб для агентів спілкуватися, передавати роботу та досягати цілий як одна команда. Що таке A2A? Просте визначення. A2A означає агент-агенту. Це відкритий протокол, що дозволяєши агентам спілкуватися безпосередньо між собою, незалежно від того, хто їх створив. Ви можете сприймати це як HTTP для агентів.

HTTP – це мова, якою спілкуються веб-браузери та сервери, а A2A робить те саме для агентів. Агент, створений вашою ІТ-командою в Microsoft Co-Pilot Studio, може спілкуватися з агентом іншої компанії в Google Cloud, якщо обидва підтримують A2A. Це також немаленький проєкт. A2A спонсорується вісьмома великими компаніями, включаючи Google, Microsoft, Cisco, Salesforce, SAP та інші, і розміщується Linux Foundation. Версія 1.0 є стабільною та готовою до реального використання, що означає, що жоден окремий вендор не контролює протокол. Це не розробка Google чи Microsoft. Це індустріальний стандарт. Дизайн свідомо зроблений простим. A2A базується на існуючих веб-стандартах, таких як HTTP та JSON-RPC, які вже знає кожен розробник. Тут немає нічого екзотичного чи закритого. Це дозволяє підприємствам легко впроваджувати його без заміни існуючої інфраструктури. Можливо, ви чули про інший протокол під назвою MCP або Model Context Protocol.

Ось у чому різниця. MCP – це зв'язок-агент-інструмент, тобто він підключає агента до зовнішніх джерел, даних та ARRI. A2A – це зв'язок-агент-агент, що з'єднує агентів безпосередньо один з одним.

Мирикальне з'єднання агента з його інструментами, а A2A – як горизонтальний зв'язок між агентами. Ще одне конструктивне рішення. A2A розглядає агентів як чорні скриньки. Тому, коли один агент спілкується з іншим, він не бачить внутрішніх міркувань, інструментів чи приватних даних іншого агента. Він бачить лише надіслане завдання та результат, який отримує у відповідь. Це зберігає конфіденційність та інтелектуальну власність. Агенту погоди не потрібно знати, як готельний агент бронює номери, йому потрібно лише передати прогноз. Тепер розглянемо перший елемент пазла – картку агента. Картка агента – це його резюме. Кожен сумісний Z2A-агент публікує документ, що називається карткою агента. Ця картка є машиносчитованим документом, який розміщується за стандартною URL-адресою на домені агента, зокрема за шляхом Well-known agent CAD.JSON. Якщо ви знаєте, де знаходиться агент, ви можете отримати його картку і дізнатися все необхідне для роботи з ним.

Сприймайте картку агента як резюме або візитну картку. Вона повідомляє іншим агентам, хто ви і що ви можете робити. Картка містить ім'я агента, текстовий опис його можливостей та теги навичок, що допомагають у пошуку. Тут також вказано URL-адресу кінцевої точки для запитів, вимоги до автентифікації, а також формати вхідних і вихідних даних. Ось конкретний приклад. Припустімо, у вас є агент-фахівець із погоди. У його картці агента сказано, я можу надати поточну погоду та прогноз на 5 днів для будь-якого міста. Він перелічує своє Ari Endpoint, приймає назву міста і повертає температуру та погодні умови у форматі JSON. Це все. Це просто чітка декларація можливостей без розкриття секретів чи внутрішньої логіки. Виявлення працює так. Агент-оркестратор має список відомих URL-адрес агентів або ви можете налаштувати їх самостійно. Коли надходить завдання, оркестратор отримує картки агентів, читає описи та вирішує, який агент підходить найкраще.

Картка погоди вказує на погоду, тому туди спрямовуються погодні завдання. Картка готелів вказує на готелі, тому туди спрямовуються завдання щодо готелів. Зверніть увагу, центральний реєстр не потрібен. Агентам не потрібно реєструватися в глобальному каталозі. Вони просто публікують свою картку за відомою адресою і будь-який інший агент, що знає URL, може їх знайти. Це свідоме дизайнерське рішення, яке робить систему децентралізованою та гнучкою. Ви можете додати нового фахівця до мережі, просто надавши оркестратору його URL, і виявлення відбудеться автоматично. Отже, оркестратор знає, хто доступний. Але як вони насправді передають роботу? Як працює комунікація A2A? Отже, оркестратор знає, які агенти доступні за допомогою картки агента. Але як саме ці агенти передають роботу один одному? Відповідь проста. Уся комунікація відбувається через HTTP з використанням повідомлень JSONRPC, протоколу, що лежить в основі більшості сучасних веб-сервісів.

Нічого специфічного чи складного, просто стандартний веб-трафік між двома агентами. Ось у чому справа. Не всі завдання однакові. A2A підтримує три різні моделі взаємодії, залежно від ваших потреб. Миттєва відповідь обробляє швидкі запити, на які віддалений агент може відповісти негайно. Ви надсилаєте запит, отримуєте відповідь одразу, і справу зроблено. Запит до агента погоди щодо сьогоднішнього прогнозу працює саме так, а синхронна відповідь швидко і просто. Потокова передача обробляє довші завдання. Можливо, агенту-фахівцю потрібно шукати в кількох базах даних або виконувати складний аналіз. Замість того, щоб змушувати вас чекати однієї відповіді, агент надсилає оновлення статусу в процесі роботи через серверні події. Ви отримуєте звіти про прогрес протягом виконання, а наприкінці – остаточний результат. Відстеження доставки посилки працює так само. Ви бачите кожен крок у реальному часі.

Асинхронне сповіщення обробляє тривалі завдання, виконання яких може зайняти в агента хвилини, години або навіть дні. Онбординг співробітників – вдалий приклад. Один фахівець створює IT-облікові записи, а інший займається оформленням пільг протягом кількох днів. Агент-клієнт подає запит, отримує ID-завдання та продовжує свою роботу. Згодом віддалений агент надсилає результат через WebHub. Клієнт також може будь-коли перевірити прогрес, опитуючи цей ID-завдання. Кожна взаємодія має однакову структуру, де все організовано як завдання. Коли клієнт надсилає запит, віддалений агент створює завдання та повертає ID-завдання. Цей ID стає ідентифікатором для відстеження всього подальшого процесу. Повідомлення всередині завдання мають роль, яка вказує відправника, та частини, що можуть бути звичайним текстом, бінарними даними, як от зображення чи документи, JSON-пакетами або посиланнями на файли. Автентифікація відповідає стандартним веб-конвенціям, от, арі-ключі, токени доступу.

Звичні методи, нічого нового вивчати не потрібно. Картка агента вказує клієнту, який метод автентифікації використовувати, і клієнт обробляє це так само, як і для будь-якого іншого арі-виклику. Ось як це виглядає на практиці. Припустімо, оркестратору потрібні дані про погоду для поїздки. Він надсилає завдання фахівцю з погоди. Фахівець з погоди підтверджує запит, починає обробку та надсилає оновлення статусу. Отримання даних. Аналіз результатів. Готово. Потім він надсилає фінальний прогноз. Оркестратор ніколи не бачить внутрішніх інструментів погодного агента, його арі-ключів чи процесу міркування. Він бачить лише результат. Це ключовий принцип дизайну, чіткі межі між агентами та відсутність витоку внутрішнього стану. Але самого лише A2A і недостатньо. Вам потрібен розумний керівник для координації всіх цих фахівців. Це підводить нас до патерну «Оркестратор-фахівець». Патерн «Оркестратор-фахівець».

Саме тут усе поєднується. Патерн «Оркестратор-фахівець» є найпоширенішою архітектурою в сучасних багатоагентних системах. Уявіть це як компанію з відділами IT, HR, фінанси, де кожен займається своєю сферою. У вас є центральний орган прийняття рішень, який спрямовує роботу до спеціалізованих команд, і кожна команда фокусується на тому, що вміє найкраще. «Оркестратор» бачить загальну картину. Він отримує запит користувача, визначає, що потрібно зробити, і вирішує, який фахівець може виконати кожну частину. Якщо користувач запитує «Сплануй поїздку до Сіетла наступного тижня». «Оркестратор» не бронює квитки чи готелі самостійно. Він знає, що є фахівець з авіаквитків, фахівець з готелів та фахівець з погоди. Він розбиває запит на ці частини та делегує кожну з них. Кожен фахівець має вузьку спеціалізацію. Один агент займається бронюванням квитків, інший – пошуком готелів, а третій – сортуванням інцидентів.

Їм не потрібно знати про сфери відповідальності одне одного. Спеціаліст з авіаперельотів знає авіакомпанії, маршрути та ціни. Йому не потрібно знати нічого про типи номерів у готелях чи правила скасування бронювання. Така вузька спеціалізація робить кожного агента простим, легким в обслуговуванні та тестуванні. Ось важлива частина. Оркестратор не виконує завдання. Він спрямовує роботу та об'єднує результати. Це його єдина робота. Роль оркестратора – бути розумним диспетчером, а не суперагентом, який намагається зробити все. Коли ви дозволяєте оркестратору виконувати роботу спеціалістів, ви втрачаєте всі переваги цього підходу. Це знову перетворюється на монолітний безлад. Остерігайтеся поширеної помилки. Деякі команди створюють зони відповідальності спеціалістів, що перетинаються. Два агенти стверджують, що можуть займатися підтримкою клієнтів або пошуком даних, що створює плутанину при маршрутизації.

Оркестратор не знає, кого обрати, і користувачі отримують суперечливі результати. Рішення просте. Кожен спеціаліст має чітко окреслену сферу діяльності без перетинів. Якщо два агенти можуть робити одне й те саме, об'єднайте їх або чіткіше розділіть сфери їхньої роботи. Microsoft Coopilot Studio використовує цей шаблон як рідний. Ваш головний Coopilot діє як оркестратор, а дочірні та підключені агенти виступають як спеціалісти. Коли користувач запитує щось, що охоплює кілька сфер, головний Coopilot делегує завдання потрібним спеціалістам через A2A. Це вбудовано в платформу, тому вам не потрібно писати логіку оркестрації з нуля. Головна перевага тут – модульність. Потрібно замінити постачальника послуг з бронювання готелів. Замініть спеціаліста з готелів, не чіпаючи оркестратор чи будь-якого іншого агента. Додаєте нові можливості. Створіть нового спеціаліста, зареєструйте його в оркестраторі і готово.

Кожен агент залишається невеликим, керованим і незалежним у розгортанні. Це і є головна мета переходу від монолітних агентів до мультиагентної системи. Отже, у нас є протокол, картки агентів і шаблон. Давайте побачимо це в дії на реальних сценаріях.

За старого підходу цей єдиний асистент мав би знати все, погоду, перельоти, готелі, ресторани, все одразу. Це забагато для одного запиту. ZE2I-оркестратор розбиває це завдання. Він надсилає завдання спеціалісту з погоди з проханням надати прогноз на ці конкретні дні. Водночас він просить фахівця з авіаперельотів знайти рейси з прибуттям у вівторок вранці та вилютом у четвер ввечері, а фахівця з готелів підібрати житло поблизу центру Сіетла на три ночі. Кожен фахівець працює незалежно і їм не потрібно спілкуватися з іншими агентами, адже кожен має власні джерела даних, інструменти та експертизу. Оркестратор збирає всі результати і об'єднує їх в одну відповідь. Користувач бачить єдину відповідь. Ось прогноз погоди. Це ваші варіанти перельотів, а ось три готелі неподалік офісу. За лаштунками три окремі агенти працювали разом без будь-якого спеціального інтеграційного коду. Тепер розглянемо бізнес-сценарій.

Припустимо, надходить запит «Мій ноутбук не підключається до VPN». Оркестратор визначає, що це проблема з мережею. Він передає тікет фахівцю з інструкцій, який знає стандартні кроки вирішення. Перевірити статус VPN клієнта, підтвердити мережеві облікові дані, перезапустити службу. Цей фахівець повертає перелік кроків. Потім оркестратор передає результат фахівцю з реєстрації тікетів, який записує вирішення в систему. Усе це відбувається за секунди без участі людини, і IT-команда залучається лише тоді, коли автоматизовані кроки не вирішують проблему. Онбординг співробітників – ще один приклад, але він триває днями, а не секундами. Новий працівник приєднується до компанії. Оркестратор запускає IT-фахівця для створення облікових записів та призначення техніки, що може зайняти кілька годин. Водночас він залучає фахівця з HR-пільг для заповнення форм, а згодом – фахівця з адміністрування для надання доступу до робочого місця та перепустки.

Кожен фахівець виконує своє довготривале завдання незалежно, а оркестратор відстежує прогрес за допомогою тих ID-завдань, про які ми згадували раніше. Отже, якщо IT-фахівець завершує роботу, оркестратор знає про це, а якщо фахівець з адміністрування затримується, він може нагадати. Користувач бачить один злагоджений процес онбордингу, але за лаштунками це ціла команда, що працює протягом кількох днів. І це не просто теорія. Коука Коула Бевара Джаз Ефрика вже використовує агентів Co-Pilot Studios Dynamics 365 для автоматизації циклів планування. Раніше їхні планувальники витрачали до півтори години щодня на рутинні завдання. Завдяки мультиагентній оркестрації ці цикли виконуються самостійно. Оркестратор делегує завдання фахівцям, які відповідають за різні частини процесу планування ланцюга постачання. Результат – економія понад години на людину щодня завдяки тому, що агенти взаємодіють між собою, а не люди переносять дані між системами.

Отже, модель залишається незмінною в усіх цих прикладах. Кожен агент – це самодостатній експерт, який знає свою сферу та має власні інструменти, і йому не потрібно знати нічого про інших агентів. A2A забезпечує простий рівень комунікації, щоб вони могли співпрацювати без написання спеціального коду. Ви отримуєте стандартний протокол і розумний оркестратор без мостів, прямих інтеграцій та головного болю з обслуговуванням. Microsoft повністю підтримує цей підхід. Подивімося, яку це вписуються Co-Pilot Studio та Azure AI. Екосистема Microsoft – Co-Pilot Studio та Azure AI. Отже, яке місце Microsoft займає в усьому цьому? Саме в центрі. Co-Pilot Studio тепер підтримує A2A і нативно, і ця функція стала загальнодоступною з квітня 2026 року-року. Це не попередня версія і не бета. Це готове до використання рішення, доступне для будь-якого відповідного клієнта вже сьогодні. Ось у чому справа. Ви можете підключати зовнішні агенти до свого оркестратора Co-Pilot Studio.

Коли я кажу «зовнішні», я маю на увазі справді зовнішні. Агенти, створені на Google Cloud, AWS чи будь-якій іншій платформі, що підпримує протокол A2A. Оркестратору байдуже, де розміщений агент, чи на якому фреймворку він був побудований. Якщо він розмовляє мовою A2A, він може приєднатися до команди. Налаштування просто. У Co-Pilot Studio ви створюєте так званий підключений агент. Ви вставляєте URL-адресу кінцевої точки агента. Co-Pilot Studio автоматично отримує картку агента за цією URL-адресою, тобто той самий JSON-файл картки агента, про який ми говорили. Він считує можливості агента, вимоги до автентифікації, а також формати вхідних і вихідних даних. Потім він створює спеціальний коннектор у фоновому режимі, і ваш оркестратор може одразу почати делегувати завдання. Вам не потрібна ручна інтеграція чи спеціальний код. Просто вставте URL-адресу, і все готово. З боку Azure Service Azure AI Foundry Agent також підтримує A2A.

Він має спеціальну кінцеву точку ARIA 2A, яка дозволяє оркестраторам із відкритим кодом, як от Autogen, LongChain та Semantic Kernel, викликати агентів Foundry. Тож, якщо ви створили агентів за допомогою цих фреймворків, ви можете інтегрувати їх в екосистему Microsoft, нічого не переписуючи. Це дорога з двостороннім рухом. Microsoft дотримується тієї ж моделі оркестратор-спеціаліст, яку ми описували. Головний агент, у кого Pilot Studio удіє як оркестратор, а дочірні та підключені агенти – як спеціалісти. Кожен із них обробляє свій домен, а оркестратор спрямовує і об'єднує результати. Це та сама архітектура, яка просто працює на платформі Microsoft. Але є нюанс – існують певні обмеження, про які вам варто знати. По-перше, кожен додатковий крок оркестрації додає затримку. Якщо ваш головний агент викликає підключеного агента, а той викликає іншого спеціаліста, кожен такий крок збільшує мережавий час.

Для розмов у реальному часі занадто велика кількість переходів може зробити роботу системи повільною. По-друге, надмірне делегування створює хаос у маршрутизації. Якщо у вас забагато спеціалістів із доменами, що перетинаються, оркестратор починає приймати помилкові рішення щодо маршрутизації. Отже, тримайте кількість спеціалістів у межах норми, а домени чітко розмежуваними. По-третє, існує певне обмеження щодо агентів даних Фебрі. Вони не працюють, коли головний агент розгорнутий у Microsoft 365 Co-Pilot. Якщо ваше розгортання орієнтоване на М365, плануйте роботу відповідно. Ці обмеження реальні, але з ними можна працювати. Платформа достатньо зріла для промислового використання, і Microsoft активно працює над усуненням цих прогалин. Тепер давайте з'єднаємо крапки та поглянемо на загальну картину. Розділ про підключення, як усе це працює разом. Зробімо крок назад і подивимося, як ці частини взаємодіють.

A2A – це телефонна система, яку агенти використовують для виклику один одного. Картки агентів – це ваша телефонна книга. Вони показують, кому телефонувати та за що відповідає кожен агент. Оркестратор – це секретар, який спрямовує кожен дзвінок у потрібний відділ. Жоден із цих елементів не працює окремо. Вам потрібні всі три. Без телефонної книги ви не знаєте, кому телефонувати. Без секретаря ніхто не керує потоком запитів. А без телефонної системи секретар не може нікого з'єднати. Вони працюють лише як команда. Саме тут на допомогу приходить модульність. Коли ваші спеціалісти модульні, ви можете додавати нові функції, не ламаючи те, що вже працює. Скажімо, ви хочете додати спеціаліста з оренди авто до свого помічника з подорожей, ви створюєте його, публікуєте картку агента, надаєте оркестратору його URL. Готово. Спеціаліст з авіаквитків та спеціаліст з готелів залишаються незмінними. Оркестратор також не змінюється.

Ви просто підключаєте новий елемент, і система адаптується. Оскільки протокол відкритий, ви ніколи не будете прив'язані до одного постачальника. Ваш оркестратор може працювати в Co-Pilot Studio, агент з погоди у Google Cloud, агент з готелів на AWS, а внутрішні системи на Azure. Вони всі розмовляють однією мовою. У цьому краса відкритого стандарту. Це запобігає прив'язки до постачальника і дозволяє обирати найкращий інструмент для кожного завдання. A2A – це не створення одного надрозумного агента, який знає все. Це створення гнучкої робочої сили зі спеціалістів, яких можна переставляти відповідно до потреб. Ви не замінюєте агентів, ви їх перегруповуєте. Ви додаєте нових. Ви змінюєте старих. Система розвивається разом з вами, замість того, щоб ставати вузьким місцем. Отже, що ви можете зробити з цими знаннями вже сьогодні? Практичні висновки. Починайте з малого. Оберіть один повторюваний процес у вашій організації, що охоплює кілька систем.

Наприклад, вирішення тікетів, адаптація співробітників або звіти про витрати. Щось із чіткою передачею завдань між етапами. Потім створіть прототип з одним оркестратором і двома спеціалістами. Вам не потрібна грандіозна архітектура. Вам потрібен лише робочий приклад, на якому можна вчитися. Використовуйте інструменти, які вже це підтримують. Coopilot Studio має вбудовану підтримку A2A, як і Azure AI Foundry. Вам не потрібно будувати протокол з нуля чи писати спеціальний код інтеграції. Ставте URL, налаштуйте своїх агентів і починайте делегувати. Остерігайтеся поширених помилок. Стежте, щоб спеціалізовані області агентів не перетиналися. Якщо два агенти можуть робити одне й те саме, об'єднайте їх або чіткіше розділіть сфери. Нехай оркестратор займається маршрути за цією, а не виконанням. І стежте за затримками через переходи в оркестрації. Якщо час відповіді зростає, можливо, у вас забагато рівнів делегування.

Найкращий перший крок – простий. Сплануйте передачу завдань у вашому робочому процесі, де інформація передається між людьми чи між системами. Це саме ті місця, де агенти можуть взяти роботу на себе. Кожна передача – це можливість. Отже, система A2A у двох словах. Три прості елементи, що працюють разом. Агенти перестають бути ізольованими і починають діяти як справжня команда. Оберіть один робочий процес із чіткою передачею завдань і будуйте від цього. Підписуйтесь на прості пояснення і залишайте коментар, якщо все стало зрозуміло.