ARD спроектирован как надмножество существующих подходов к обнаружению агентов и инструментов. Он не заменяет другие реестры, а служит федеративной надстройкой, которая их объединяет.

• Универсальная оболочка: «карточку» AI Catalog может получить что угодно - MCP-сервер, навык (Skill), агент ACP, агент A2A, традиционный REST API или то, что появится следующим.
• Федеративное индексирование: опубликованную карточку может проиндексировать любой сервис обнаружения ARD. Вам не нужно выбирать между реестрами: сервис обнаружения может использовать их все, или вы можете курировать собственную подборку.

---

Как ARD соотносится с реестрами и каталогами инструментов?

В экосистеме уже есть много курируемых коллекций агентных ресурсов (agentic resources): реестры MCP-серверов и агентов A2A, каталоги плагинов вроде Open Plugins и платформенные каталоги инструментов некоторых партнёров. Каждая из них - централизованный каталог: в него подают ресурсы, ему принадлежит канонический список, и клиенты запрашивают именно этот список. Они полезны, но каждая - остров со своим порядком подключения, управлением и охватом.

ARD переворачивает это отношение. Вместо того чтобы публиковать ресурс в каждой коллекции, издатель описывает его один раз на собственном домене (yourdomain.com/.well-known/ard.json), и любой сервис обнаружения может проиндексировать его естественным образом - без центрального привратника и без повторной регистрации в каждой коллекции. Обнаружение становится свойством открытого интернета - так же, как поисковые системы обходят сайты, - а не списком, которым владеет один оператор.

В этой модели такие коллекции не исчезают - они становятся сервисами обнаружения ARD. Реестр, каталог плагинов или каталог инструментов может индексировать записи ARD со всего интернета, применять собственные правила курирования и доверия и предоставлять результат; клиенты выбирают, к каким из них обращаться, и они сочетаются между собой. Поэтому «ARD против реестра» - неверная постановка вопроса: ARD - это спецификация, которая позволяет многим курируемым коллекциям - публичным, принадлежащим поставщикам и внутренним - индексировать один и тот же опубликованный ресурс, и никому не приходится выбирать только одну.

---

Заменяет ли ARD протоколы MCP или OpenAPI?

Нет. ARD - это протокол обнаружения (оболочка), а не механизм исполнения. Он оборачивает существующие стандарты исполнения (такие как MCP, A2A и OpenAPI), используя стандартные и предложенные типы содержимого (media types) IANA, чтобы клиенты могли находить агентные ресурсы динамически. После обнаружения клиент подключается к агентному ресурсу и вызывает его через собственный механизм этого ресурса (например, JSON-RPC для MCP).

---

Чем ARD отличается от встроенного поиска инструментов в ИИ-клиентах?

Они тесно связаны. В каком-то смысле встроенный поиск инструментов клиента сам реализует обнаружение агентных ресурсов - в пределах тех инструментов, которые у клиента уже есть. Он выбирает из известного набора, которым управляет клиент, и внутри этой границы работает хорошо.

ARD описывает ту же идею в более общем виде и отделяет обнаружение от любого отдельного клиента. Возможности, нужные для задачи, могут приходить из многих мест - внутренних систем, сервисов поставщиков, публичных каталогов, навыков, MCP-серверов, API, рабочих процессов или агентов, - и ARD позволяет клиенту или организации обнаружить, какие из них вообще должны быть доступны, а не получать этот набор жёстко заданным в реализации клиента.

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

Именно отделение обнаружения от клиента делает это полезным на практике:

• Корпоративный контроль - организация может решить, какие ресурсы одобрены, а какие предпочтительны для конкретной задачи, и применить политики, права доступа и правила соответствия нормам один раз, централизованно, вместо ручной настройки каждого клиента.
• Федерация - сервисы обнаружения сочетаются между собой. Компания может запустить собственный сервис, который объединяет внутренние ресурсы с отобранными источниками поставщиков и публичными источниками, и предоставить его как единую конечную точку (endpoint), сохраняя контроль над тем, что в него входит.
• Переносимость - поскольку слой обнаружения отделён, одни и те же ресурсы можно находить и использовать в разных ИИ-клиентах и агентных средах (harnesses), а не привязывать их к набору инструментов одного клиента.
• Независимое развитие - ресурсы можно добавлять, обновлять или выводить из эксплуатации, не меняя клиент; только что опубликованная возможность становится доступной для обнаружения в тот момент, когда сервис её проиндексирует.

Коротко: встроенный поиск инструментов выбирает среди известных инструментов; ARD - это слой, который решает, какие инструменты должны быть известны, - а поиск инструментов клиента - один из естественных способов этим воспользоваться.

---

А как насчёт реестра агентов ACP

Список агентов ACP в реестре агентов ACP по структуре уже близок к манифесту ARD. Реестры ACP могут экспортировать манифесты своих каталогов как стандартные ленты ard.json, что даёт мгновенное обнаружение в масштабе интернета для агентов, работающих в контексте редактора, - без повторной регистрации этих агентов где-либо.