AWS совместно с инженерами Cisco предложила практическое решение для перехода от REST-сервисов к протоколу агентного взаимодействия A2A (Agent-to-Agent). Решение получило название agentic overlays — тонкие обёртки, которые превращают существующие REST-сервисы в агенты, способные участвовать в A2A-взаимодействии, не требуя переписывания бизнес-логики. Кроме того, они предоставляют REST API в виде инструментов, совместимых с протоколом MCP (Model Context Protocol).
Чтобы понять ценность подхода, необходимо разобраться в различиях между REST и A2A. REST API оптимизированы для детерминированной клиент-серверной интеграции: вызов конечной точки, передача параметров и получение предсказуемого ответа. A2A, напротив, спроектирован для взаимодействия между автономными агентами, которые обнаруживают друг друга через метаданные (agent card), согласовывают возможности и обмениваются структурированными сообщениями (обычно через JSON-RPC) для координации многошаговых задач. REST нацелен на стабильные интерфейсы и прямое выполнение, A2A — на координацию, управляемую рассуждениями.
| Подход | Описание | Недостатки |
|---|---|---|
| Раздельные REST и A2A стеки | Два набора конечных точек (/api/v2/ и /a2a/) с независимой реализацией | Двойные затраты на аутентификацию, тестирование, мониторинг; риск рассинхронизации |
| Рефакторинг с переиспользованием бизнес-логики | Изменение существующих REST-эндпоинтов для переиспользования кода в A2A | Требует изменений в работающих сервисах; высокая сложность |
| Agentic Overlays | Тонкая обёртка, трансформирующая REST-запросы в A2A и обратно | Дополнительный слой, но без изменений в бизнес-логике и минимальные риски |
Ключевая проблема в том, что существующие корпоративные системы построены на REST, и их полная перестройка под A2A — дорогостоящая и рискованная задача. До стандартизации A2A многие компании уже внедрили агентов в виде REST-сервисов, и теперь эти агенты не являются A2A-нативными. Распространённый подход — поддержка двух параллельных стеков (/api/v2/ и /a2a/) — ведёт к удвоению инфраструктуры, увеличению затрат и риску рассинхронизации. Альтернатива — рефакторинг существующих конечных точек с разделением бизнес-логики и транспортного уровня — также требует значительных изменений в коде.
Они также превращают REST API в инструменты, совместимые с протоколом MCP (Model Context Protocol).
Agentic overlays предлагают третий путь: тонкий слой, который ложится поверх существующего REST-сервиса и добавляет A2A-возможности без изменения его внутренней логики. Обёртка выступает в роли транслятора: она получает A2A-сообщения, преобразует их в REST-вызовы и обратно. Таким образом, один и тот же сервис одновременно продолжает работать как REST API и приобретает способность общаться с другими агентами по протоколу A2A. Более того, через MCP REST-эндпоинты становятся доступны как инструменты для больших языковых моделей.
Авторы публикации приводят сравнение трёх подходов: поддержка раздельных стеков, рефакторинг с переиспользованием бизнес-логики и применение agentic overlays. Первый подход требует двойной реализации аутентификации, валидации, развёртывания и наблюдения. Второй — изменений в коде REST-сервисов, что может быть рискованно для критических систем. Третий, agentic overlays, минимизирует изменения и позволяет пошагово вводить A2A-совместимость.
Репозиторий AWS включает эталонные архитектуры, примеры кода для создания обёрток и интеграции с MCP. Практическое применение позволит предприятиям постепенно переводить свои сервисы в экосистему агентов, не создавая параллельной инфраструктуры и не снижая надёжность существующих REST-систем.
