A2A 1.0: чому для комунікації між агентами потрібен справжній протокол

Передати одному агенту URL іншого — ще не означає налагодити співпрацю. Системам потрібно виявити доступні можливості, узгодити завдання, обмінюватися оновленнями, передавати артефакти й обробляти збої, не розкриваючи приватної пам’яті чи деталей реалізації. Agent2Agent, або A2A, — спроба стандартизувати цей міжсистемний інтерфейс.

12 березня 2026 року проєкт A2A оголосив версію 1.0 своїм першим стабільним релізом, готовим для production. Його центральний об’єкт — не повідомлення в чаті, а завдання з власним ідентифікатором, життєвим циклом і результатом. Агент може опублікувати Agent Card з описом своїх можливостей і підтримуваних способів взаємодії. Інша система може надіслати завдання, отримувати оновлення статусу, стежити за проміжним виконанням у потоковому режимі або чекати асинхронного сповіщення. Результати подаються як артефакти, а не залишаються лише в неформальному записі розмови.

Це важливо, коли агентів створюють різні команди, на різних фреймворках або в різних постачальників. Агент, який приймає завдання, може залишатися «чорною скринькою». Щоб прийняти запит із чіткими межами, йому не потрібно розкривати внутрішній промпт, модель, пам’ять або інструменти.

MCP та A2A працюють із різними межами

MCP зазвичай підключає AI-застосунок до інструментів і даних. A2A підключає один агентний застосунок до іншого. Перший розширює доступні агенту можливості, другий дає змогу передавати відповідальність за завдання через межу між системами.

Їх можна використовувати разом. Координатор може делегувати дослідницьке завдання через A2A, а спеціалізований агент — шукати в погоджених репозиторіях за допомогою інструментів MCP. Але поєднання протоколів не об’єднує їхні моделі довіри. Координатору все одно потрібно знати, що можна розкрити спеціалісту, які результати приймати й хто відповідає за фінальну дію.

Більше агентів не означає автоматично більше інтелекту

Мультиагентна архітектура додає цінності, коли друга система надає інформацію, можливості або незалежну перевірку, яких один агент не може отримати сам. Вона створює зайві витрати, коли ролі лише повторюють ті самі міркування, витрачаючи додаткові токени й збільшуючи затримку.

Типові збої знайомі з розподіленої роботи: неповне передавання завдання, суперечливі оновлення, дублювання зусиль, тайм-аути та прогалини у відповідальності. Віддалений спеціаліст може повернути гарно оформлений, але хибний артефакт. Агент-координатор може прийняти його, бо формулювання звучать упевнено. Два агенти можуть раз по раз звертатися один до одного без жодного поступу.

Рішення — не довший промпт для координації, а чіткіший контракт:

• визначте пакет вхідних даних і те, яку інформацію дозволено розкривати;
• задайте чітку умову завершення завдання;
• вимагайте структурованих станів виконання та помилок;
• встановіть обмеження часу, вартості й повторних спроб;
• перевіряйте артефакт незалежно;
• зберігайте відповідальність за людиною або сервісом, які ініціювали завдання.

Практична перевірка доцільності

Перш ніж запроваджувати A2A, виконайте те саме робоче навантаження одним агентом зі звичайними інструментами. Якщо така система надійно справляється із завданням, другий агент може бути зайвим. Якщо спеціалізація виправдана, спочатку виокремте одну ділянку взаємодії: наприклад, дослідження, code review або генерацію медіа. Виміряйте, чи покращує передавання завдання якість або пропускну здатність достатньо, щоб компенсувати витрати на оркестрацію.

Interoperability корисна, бо зменшує витрати на взаємодію через межі систем. Вона не робить ці межі безпечними за замовчуванням. Сприймайте Agent Cards як інтерфейси, які можна виявити, історії завдань — як потенційно чутливі записи, а артефакти від віддалених систем — як недовірені до завершення перевірки.

Про рівень інструментів читайте в матеріалі «MCP стає інфраструктурою». Про дозволи й відновлення — у статті «Безпека AI-агентів».

Першоджерела

• A2A Protocol v1.0 announcement
• A2A official specification
• Google Cloud donation of A2A to the Linux Foundation

Примітка про джерела й адаптацію: стаття також спирається на загальні концепції мультиагентної архітектури з AI Agents in Depth: Design Principles and Engineering Practice авторства Bojie Li та співавторів, поширюваної за Apache License 2.0. Текст, структуру, приклади й висновки самостійно переписано та розширено для Stariy.com.