AWS связала трёх ИИ-агентов в двух аккаунтах через протокол A2A

Вы сделали корпоративного ИИ-помощника на LangChain, а поставщик сервиса проверки безопасности использует Strands. Теперь нужно связать их: передать задачу, проверить доступ и объяснить внешнему сервису, какие внутренние правила действуют у заказчика. Обычно здесь появляется отдельный интеграционный слой, который приходится поддерживать обеим командам.

AWS опубликовала пример такой связки через Agent-to-Agent, или A2A. В нём три агента работают в двух AWS-аккаунтах, обмениваются задачами и запрашивают друг у друга контекст. Практическая ценность материала — в конкретной схеме взаимодействия между компаниями: разные фреймворки, отдельные системы идентификации и обратный вызов к заказчику.

Как внешний агент узнаёт правила компании

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

Поэтому внешний агент обращается к третьему участнику — внутреннему агенту контекста. Тот предоставляет сведения об аккаунтах, применимых политиках и контактах для эскалации. Получив контекст, SaaS-агент завершает проверку и возвращает результат корпоративному оркестратору, который готовит ответ пользователю.

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

В демонстрации данные о нарушениях синтетические. Реальное подключение к AWS Config, Security Hub или GuardDuty авторы описывают как следующий шаг для промышленной системы. Поэтому пример показывает организацию взаимодействия, но не доказывает качество автоматического аудита безопасности.

Что именно стандартизирует A2A

При запуске оркестратор загружает Agent Card внешнего агента — описание его возможностей. На основе опубликованных навыков он создаёт инструменты LangChain, а модель выбирает подходящий инструмент по вопросу пользователя. Отдельно прописывать маршрут для каждого вопроса в этой схеме не требуется.

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

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

В этой архитектуре A2A также имеет отдельную роль от MCP. Через MCP агент может подключать собственные инструменты и источники данных. Через A2A он передаёт работу другому агенту. Один сервис способен использовать оба протокола: MCP внутри, A2A для взаимодействия с заказчиком.

Где заканчивается готовый пример

Каждая сторона использует собственный пул пользователей Amazon Cognito. При подключении компании обмениваются публичными параметрами: адресами, идентификаторами клиентов и областями доступа. Секреты между ними не передаются, хотя внутри каждой стороны секреты для получения токенов есть и хранятся в Secrets Manager.

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

Развёртывание разбито на три Jupyter-ноутбука. Указанные авторами оценки этапов составляют около 3, 5 и 20 минут; подготовка аккаунтов и разрешений потребует дополнительного времени. Инфраструктура платная, причём часть ресурсов работает постоянно, включая NAT-шлюз, задачи Fargate и балансировщик.

Разработчику этот пример стоит изучить, если агент должен работать с сервисами партнёров или разных внутренних команд. Начать можно с одного сценария: передать задачу внешнему агенту, разрешить ограниченный запрос контекста и проверить весь путь с токенами обеих сторон. Именно этот участок AWS разобрала достаточно предметно, чтобы использовать материал как основу собственного прототипа.