31 августа AWS вынесла в Weekly Roundup открытую спецификацию ARD и описала идею коротко: это что-то вроде DNS для AI-агентов. Для тех, кто уже пробует MCP в проде, новость важная: протокол ARD пытается закрыть дыру между «агент умеет подключаться к инструменту» и «агент вообще знает, какой инструмент ему нужен среди сотен внутренних и внешних сервисов».
Об этом сообщает The New Stack. Суть претензии к текущему стеку довольно приземлённая: MCP неплохо решает задачу подключения к инструментам и данным, но почти не помогает со следующим шагом — поиском. Пока у команды десяток серверов, это можно пережить. Когда у компании сотни или тысячи ресурсов, разбросанных по облакам, on-prem и SaaS-платформам, ручная настройка быстро превращается в тот самый «временный костыль», который потом живёт дольше продукта.
Именно на этот слой и нацелен протокол ARD, или Agentic Resource Discovery. По материалам спецификации, ARD не пытается заменить MCP, A2A, Skills или обычные API. Он работает раньше, на этапе discovery: помогает агенту ответить на три вопроса, без которых вся агентная автоматизация начинает буксовать. Где находится подходящая возможность, какую из нескольких вообще стоит выбрать и как проверить, что к ней безопасно подключаться. В этом смысле спор вокруг MCP выглядит слегка искусственным: проблема не в том, что MCP плох, а в том, что от него ждали больше, чем он изначально обещал.
Авторами ARD указаны Junjie Bu из Google, R.V. Guha из Microsoft и Shaun Smith из Hugging Face. Спецификация выпущена под лицензией Apache 2.0, а в её развитии участвуют инженеры Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce, ServiceNow и Snowflake. Google публично анонсировала ARD 17 июня 2026 года, а в актуальной версии спецификации на сайте проекта стоит пометка v0.91 от 26 августа 2026 года со статусом Proposal. То есть это не зацементированный стандарт, а рабочая версия, которую ещё шлифуют. Для рынка это, кстати, хороший сигнал: обсуждать discovery-слой начали до того, как разные вендоры успели окончательно закопаться в свои несовместимые каталоги.
Технически схема выглядит без лишней магии. У ARD есть два базовых элемента: каталоги и реестры. Организация публикует каталог своих агентных ресурсов на собственном домене, а реестры выступают чем-то вроде поисковиков: обходят эти каталоги, индексируют содержимое и отвечают на запросы агентов. В документации проекта говорится, что ресурсом может быть агент, MCP-сервер, Skill, плагин, API или workflow. Дальше важная оговорка: ARD не выполняет вызов сам. Он находит ресурс, возвращает метаданные и данные для проверки доверия, а затем клиент уже подключается к найденному ресурсу через его нативный протокол. Иначе говоря, MCP отвечает на вопрос «как говорить с инструментом», а ARD — «как вообще его найти и не нарваться на что попало».
Отсюда и практическая польза для разработчиков и платформенных команд. Во-первых, не нужно заранее зашивать в агента длинный список всех допустимых инструментов и тащить этот зоопарк в контекст. Во-вторых, появляется шанс построить федеративную модель, где внутренние реестры компании могут сосуществовать с внешними каталогами партнёров без тотальной миграции в одну экосистему. AWS в своей формулировке делает на этом акцент: издатель описывает ресурс один раз, а потребители могут находить его в разных каталогах и реестрах. Для enterprise это почти важнее красивых демо. Чем крупнее организация, тем дороже обходится не сам вызов инструмента, а хаос вокруг инвентаризации, допуска, версий и доверия.
Есть и более тонкий момент. Вокруг агентной инфраструктуры уже начала складываться знакомая история из мира облаков и observability: сначала рынок плодит закрытые реестры, потом внезапно выясняется, что интероперабельность дороже эксклюзивности. ARD в этом смысле пытается не столько изобрести новый протокол, сколько не допустить очередного вендор-локина на уровне discovery. У проекта даже специально разведены роли управления: на oversight board уже представлены Google, Hugging Face, Microsoft и Amazon, а среди мейнтейнеров есть как корпоративные участники, так и независимые члены. Это ещё не гарантирует идиллию, но хотя бы показывает, что авторы понимают политическую сторону стандартизации не хуже технической.
Для русскоязычной IT-аудитории вывод простой. Если вы строите агента для одной узкой задачи, весь разговор про discovery может показаться преждевременным. Но как только речь идёт о корпоративном поиске инструментов, внутренних сервисных каталогах, агентных маркетплейсах или платформе для нескольких команд, протокол ARD становится уже не теоретическим довеском, а потенциально обязательным слоем. MCP без discovery действительно решает только половину задачи. Вопрос теперь не в том, нужен ли такой слой, а в том, успеет ли отрасль договориться о нём раньше, чем каждый крупный игрок окончательно построит свой «открытый, но почему-то только для своих» реестр. Проверить исходные артефакты и саму спецификацию можно у .