Протоколу A2A від Google виповнився рік — 9 квітня. Сто п'ятдесят організацій підписались. Двадцять дві тисячі зірок на GitHub. П'ять продакшн SDK. Конкуруючий протокол ACP від IBM злився з ним під крилом Linux Foundation. Azure AI Foundry та Amazon Bedrock AgentCore — обидва його вбудували.

За кожною метрикою, окрім тієї, що має значення, A2A переміг.

Метрика, що має значення: жоден великий агентний SDK сьогодні не має нативної підтримки A2A. Жоден. Протокол, який мав дозволити будь-якому AI-агенту знаходити й делегувати завдання будь-якому іншому агенту — незалежно від вендора — весь свій перший рік збирав логотипи, поки SDK, якими реально користуються розробники, рухались у протилежному напрямку.

Тринадцять днів, чотири рови

Між 3 та 15 квітня 2026 року чотири компанії випустили власні фічі мульти-агентної делегації. Жодна з них не сумісна з іншими.

3 квітня Microsoft випустив Agent Framework v1.0 — єдиний фреймворк, що хоча б намагається координувати між вендорами, з конекторами для Claude, GPT, Gemini та Bedrock. Підтримка A2A? "Coming soon." 8 квітня Anthropic запустив Managed Agents у публічну бету: sandbox-виконання, збереження стану, мульти-агентна координація — тільки Claude, жодної згадки про A2A. 9 квітня сам A2A відсвяткував свій перший рік прес-релізом, повним цифр і без жодної інтеграції в SDK. А 15 квітня OpenAI випустив Agents SDK v0.14 з Sandbox Agents та handoff-примітивами — теоретично модель-агностичний, на практиці без A2A.

Чотири вендори. Тринадцять днів. Чотири несумісні діалекти однієї й тієї ж ідеї. А єдиний протокол, створений для їхнього об'єднання, сидів у кутку зі своїми 150 організаціями-підписантами і дивився.

Як виглядає "нуль впровадження" в коді

Ось модель делегації від Anthropic. Ви створюєте managed agent через REST API — він працює в sandbox Anthropic — а ваш координатор делегує через сесії:

import anthropic

client = anthropic.Anthropic()

# Створюємо managed agent (працює в хмарному sandbox Anthropic)
agent = client.agents.create(
    model="claude-sonnet-4-20260514",
    instructions="You are a research specialist.",
    tools=[{"type": "web_search"}],
)

# Стартуємо сесію — координатор відправляє підзадачу
session = client.sessions.create(
    agent_id=agent.id,
    messages=[{"role": "user", "content": "Analyze A2A adoption metrics"}]
)

А ось підхід OpenAI — інший рантайм, зовсім інша філософія:

from openai_agents import Agent, handoff

research_agent = Agent(name="researcher", model="gpt-4.1")
coding_agent = Agent(name="coder", model="gpt-4.1")

# Handoff: research_agent передає повний контроль coding_agent
research_agent.handoffs = [handoff(coding_agent)]

Два блоки коду. Дві екосистеми. Нуль спільної поверхні інтерфейсу. Ваш Claude-агент не може зробити handoff() до OpenAI-агента, а ваш OpenAI-агент не може викликати sessions.create() на інфраструктурі Anthropic. Вони буквально не поділяють жодного спільного виклику методу.

A2A визначає AgentCards для discovery, життєвий цикл задач для делегації та стрімінг — все вендор-нейтральне. Його створили як шар, що мав зробити обидва фрагменти коду вище непотрібними. Натомість обидва SDK вийшли, навіть не визнавши його існування.

Чому 150 логотипів не конвертнулись

A2A має все, що потрібно стандарту, крім того, що змушує стандарти приживатися: безшовна інтеграція в точці використання. Немає pip install a2a, який вбудовується в проєкт на Anthropic чи OpenAI. Немає middleware, що автоматично перетворює handoff() на A2A-задачу. Протокол живе у власному репозиторії, з власними SDK, вимагаючи від розробників будувати й підтримувати прошарки-перекладачі між їхнім реальним фреймворком оркестрації та моделлю задач A2A.

Якщо сьогодні спробувати зв'язати вендорські SDK через A2A, натрапляєте на класичну проблему N-квадрат: кожна пара вендорських SDK потребує власного моста. Три вендори — шість мостів. Чотири — дванадцять. Масштабується приблизно як факс-апарати.

Далі — латенсі. Кожен хоп трансляції протоколу додає відчутний overhead — достатній, щоб ланцюжок із трьох агентів через bridge-шари спалював помітний wall-clock час ще до початку будь-якого мислення. Для агентних циклів, що ітеративно проходять через reasoning та використання інструментів, це накопичується швидко.

І governance залишається сліпою зоною по всьому фронту. Ваш координатор-агент не може інспектувати reasoning суб-агента, що працює на інфраструктурі іншого вендора. Ви довіряєте результату, який фундаментально не можете перевірити. Специфікація A2A теж цього не адресує.

Ставка Microsoft — і чому вона цікава

Agent Framework v1.0 від Microsoft — це аутсайдер, за яким варто стежити. Це єдиний робочий фреймворк, що координує Claude, GPT, Gemini та Bedrock в одному графі делегації. A2A він поки не використовує — та відмітка "coming soon" несе на собі чималий вантаж — але він доводить, що мульти-вендорна оркестрація технічно можлива, коли один вендор контролює шар маршрутизації.

Підступ: хтось має володіти шаром маршрутизації. Microsoft добровільно вступає. Це не інтероп — це інший вид lock-in, на один поверх вище.

Прагматична архітектура

Рішення для тих, хто будує сьогодні, просте, але гірке: обирайте одно-вендорну оркестрацію й використовуйте MCP-інструменти як запасний вихід для інтеропу. Агентний фреймворк одного вендора володіє графом делегації, MCP обробляє зовнішні дані та доступ до інструментів. Це саме той lock-in, який мульти-модельна обіцянка мала запобігти.

MCP довів, що доступ до інструментів можна стандартизувати — один протокол, кожен вендор впровадив його за місяці. Делегація агент-агенту — та сама проблема на рівень вище, і A2A — очевидний кандидат на її вирішення. Специфікація надійна. Governance реальний. Організаційна підтримка широка.

Але протокол, який не вбудований у SDK, до яких тягнуться розробники — це протокол, що існує лише на папері. A2A виповнився рік. У нього є все, окрім єдиного, що рахується: рядка в чужому import-стейтменті.