A2A вошёл в AAIF. Проблема предприятия — непрерывность между протоколами.

17 августа Agentic AI Foundation (AAIF) объявила, что Agent2Agent, или A2A, вошёл в фонд как hosted-проект. Теперь A2A находится в той же специализированной структуре Linux Foundation, что и Model Context Protocol (MCP), agentgateway, AGENTS.md и goose.

Это существенная консолидация управления. Но это не запуск нового протокола, не слияние A2A и MCP и не появление корпоративной плоскости управления. A2A уже перешёл под эгиду Linux Foundation в июне 2025 года. Новый шаг помещает его в AAIF — фонд, созданный в декабре 2025 года для нейтрального совместного управления открытой инфраструктурой агентных систем.

Для автономных организаций главное следствие связано не столько с выбором «победившего» протокола, сколько с тем, где теперь проходит операционная граница. Одна бизнес-операция всё чаще будет пересекать несколько протоколов: агент делегирует задачу через A2A, другой агент обращается к инструменту через MCP, а результат меняет запись о клиенте, инициирует платёж или воздействует на производственную систему. Организация всё равно должна видеть в этой цепочке одну управляемую работу.

Что изменилось: управление стандартами стало более цельным

AAIF определяет A2A как открытый протокол, через который агенты из разных организаций и фреймворков могут находить возможности друг друга, обмениваться сообщениями, делегировать задачи и сотрудничать, не раскрывая внутреннюю реализацию. MCP решает другую задачу: соединяет модели и агентов с инструментами и контекстными ресурсами. Это соседние, но не одинаковые проблемы.

Размещение обоих проектов в AAIF делает их совместное существование понятнее. В текущем перечне фонда представлены важные части формирующегося агентного стека: взаимодействие агентов, подключение к инструментам, шлюзовая инфраструктура, файлы инструкций для агентов и агентный проект. Общая институциональная среда может упростить согласованную работу над стандартами и даёт предприятиям более ясную точку наблюдения за развитием открытой инфраструктуры.

Этот переход важен потому, что A2A — не малоизвестная инициатива в поиске первых пользователей. В апреле 2026 года Linux Foundation сообщила о поддержке со стороны более чем 150 организаций, интеграциях на платформах Google, Microsoft и AWS, активных промышленных внедрениях и стабильной спецификации 1.0. Это показатели на апрель, а не новая августовская цифра. Но они объясняют, почему место управления проектом имеет значение.

Что не изменилось: общая организация не превращает протоколы в среду исполнения

Управление со стороны AAIF не создаёт для предприятия общую идентичность исполнения. Оно не переносит автоматически бизнес-цель из делегирования A2A в вызов инструмента по MCP. Оно не решает, должно ли сужаться полномочие при передаче задачи, не хранит состояние процесса, необходимое для понимания последующего эффекта, и не собирает доказательства для аудита из всех участвующих систем.

A2A и MCP также не стали взаимозаменяемыми. A2A может структурировать коммуникацию и делегирование между агентами. MCP может подключать агента к инструментам и контекстным ресурсам. Одна задача способна использовать любой из них отдельно или оба последовательно. Общий фонд не превращает такую последовательность в единую транзакцию и не создаёт общую модель авторизации либо единый аудиторский след.

“Совместимость протоколов ценна. Непрерывность организационного исполнения — отдельная инженерная обязанность.

Эту разницу легко не заметить: в удачной демонстрации передача выглядит бесшовной. Оркестрирующий агент передаёт работу специалисту по A2A. Специалист запрашивает систему или выполняет операцию через MCP. Пользователь получает ответ или завершённую задачу. На уровне протоколов каждое сообщение может быть корректным. Но на уровне организации ключевые вопросы могут остаться разорванными: кто начал работу, с какой целью, в каких ограниченных полномочиях, по какой версии политики и какие доказательства подтверждают полученный эффект?

Управлять нужно бизнес-исполнением

Зрелая автономная организация должна рассматривать делегирование по A2A и последующие вызовы MCP как события одного наблюдаемого контура исполнения, если они продвигают одну бизнес-цель. Этот контур не заменяет протоколы. Это контекст управления и запись времени исполнения, сохраняющиеся при переходе между протокольными границами.

Он должен как минимум связывать пять элементов. Первый — устойчивый идентификатор исполнения, который передаётся или надёжно сопоставляется между делегированием и использованием инструментов. Второй — инициирующий субъект и ответственный владелец со стороны организации. Третий — заявленная бизнес-цель и границы работы. Четвёртый — полномочия и ограничения каждого участника, включая их сужение при делегировании. Пятый — доказательства, достаточные для восстановления существенной цепочки от запроса до эффекта.

Это не призыв втиснуть каждое сообщение каждого протокола в одну закрытую корпоративную схему. Такой подход смешал бы открытую совместимость с конкретной реализацией предприятия. Требование практичнее: управляемая среда исполнения должна уметь прикреплять, передавать, отображать или коррелировать контекст исполнения организации при переходе работы между протоколами. Там, где передача невозможна, среда должна фиксировать явное сопоставление, а не молча восстанавливать непрерывность задним числом.

Конкретная передача работы

Представим исключение в закупочном процессе. Агент снабжения делегирует проверку поставщика агенту-специалисту через A2A. Специалист через подключённые по MCP системы проверяет данные одобренных поставщиков и условия договора. Он возвращает рекомендацию. Затем другой агент может создать заявку на закупку через ещё одно инструментальное подключение.

Предприятие не должно считать достаточной записью три несвязанных журнала: диалог A2A, журнал доступа к инструменту и событие в системе закупок. Нужно установить, относились ли все три события к одному исключению; получил ли специалист только полномочие на проверку, а не на закупку; осталась ли заявка в одобренных пределах; и какие факты и условия политики обосновали результат. Это непрерывность исполнения, а не предпочтение A2A или MCP.

Проектируйте стык, а не только конечную точку

Большинство сбоев контроля в многоагентных системах, вероятно, будут проявляться именно на стыках. Локальный агент может корректно проверить входящую задачу A2A. Инструментальный шлюз может корректно авторизовать запрос MCP. Но объединённая система всё равно способна потерять связь между запросом и полномочием, которое его оправдывало. Вызов инструмента может быть допустим для вызывающего агента, но выходить за пределы цели делегированной работы.

Поэтому среда исполнения должна контролировать сам переход. До принятия делегирования ей следует зафиксировать идентичность исполнения, ответственного владельца, цель и допустимый объём. Перед вызовом инструмента, создающим существенный эффект, она должна проверить связь вызова с активным исполнением и соответствие полномочиям текущего агента в рамках этого исполнения. После операции необходимо сохранить запись о результате, которую можно связать с исходной работой, а не только с транспортным запросом.

• Рассматривайте делегирование как управляемый переход: фиксируйте родительское исполнение, получателя, цель, объём работы и доступные получателю полномочия.
• Требуйте, чтобы существенные вызовы инструментов ссылались на активный контекст исполнения или явно с ним сопоставлялись; запросы без такой связи отклоняйте либо направляйте на проверку.
• Делайте телеметрию протоколов, решения об авторизации и доказательства эффекта связываемыми через устойчивые идентификаторы и зафиксированные сопоставления.
• Аудируйте полный путь бизнес-эффекта через агентов, шлюзы и инструменты, а не только соответствие каждого отдельного перехода.

Почему это важно сейчас

Консолидированный набор проектов AAIF показывает, что экосистема открытых агентных стандартов становится более структурированной. Для совместимости это хорошая новость. Но смешанное исполнение через несколько протоколов станет и более обычным. По мере того как организации одновременно внедряют взаимодействие агентов и подключение к инструментам, проявится простой операционный факт: стандарты определяют, как компоненты обмениваются данными; ответственность за доказательство того, что объединённая система сделала и почему ей было разрешено это сделать, остаётся у организации.

Архитектурный ответ должен быть дисциплинированным. Используйте протоколы для тех границ, которые они стандартизируют. Не ждите, что управление стандартами само создаст семантику корпоративной среды исполнения. Постройте единый наблюдаемый контур исполнения над протокольным уровнем и подчините ему делегирование, доступ к инструментам, проверки политик и сбор доказательств.

Вступление A2A в AAIF делает ландшафт протоколов более цельным. Следующая корпоративная задача сложнее и важнее: обеспечить, чтобы бизнес-исполнение оставалось понятным, авторизованным и проверяемым, пересекая этот ландшафт.