Моделі та платформи ШІ
AWS підтримує Agentic Resource Discovery як шар федерації для Agent Registry
Додайте Unite.AI до бажаних джерел у Google
Amazon Web Services підтримала специфікацію Agentic Resource Discovery, опублікувавши докладний опис 24 серпня 2026 року про те, як відкритий стандарт має працювати разом з AWS Agent Registry — керованим каталогом для AI‑агентів, інструментів та навичок, який увійшов у прев’ю на початку цього року.
У посту AWS ARD представлено як відповідь на проблему, яку залишає відкритою власний продукт AWS. AWS Agent Registry, доступний через Amazon Bedrock AgentCore, надає організації централізований, пошуковий каталог агентів, MCP‑серверів, інструментів, навичок агентів та власних ресурсів, проте лише в межах власного середовища AWS. Більшість підприємств експлуатують агентів у кількох хмарах, локальній інфраструктурі та SaaS‑платформах, кожна з яких має власний реєстр і формат метаданих, і сьогодні з’єднання цих середовищ означає створення індивідуальних конекторів між кожною парою реєстрів.
ARD пропонує альтернативу спільного формату: якщо кожен реєстр описує ресурси однаково і надає їх виявлення через спільний протокол, видавці описують свої ресурси один раз, а споживачі знаходять їх скрізь.
Внутрішня модель AWS Agent Registry
Реєстр, який наразі перебуває у прев’ю через Amazon Bedrock AgentCore, побудований навколо двох концепцій: реєстри — каталоги, які адміністратор створює зі своїми налаштуваннями авторизації та схвалення, та записи — метадані, що описують кожен ресурс. Робочий процес публікації проходить від адміністратора до видавця, куратора та споживача, з пунктом схвалення перед тим, як будь‑який запис стане доступним для виявлення. Доступ контролюється за допомогою облікових даних AWS Identity and Access Management або JSON Web Token від корпоративного провайдера ідентифікації, а сам реєстр виставляється як віддалена MCP‑точка, тому будь‑який клієнт, сумісний з MCP, може шукати його безпосередньо.
Цей шар управління — саме те, що AWS намагається зберегти. У пості AWS описує ARD як шар взаємодії, що розташований поза точкою примусових дій: організація, яка публікує каталог, контролює його вміст, хто може його бачити і коли відкликати доступ, при цьому існуючі механізми схвалення та контролю доступу в Agent Registry залишаються там, де політика фактично застосовується. Формулювання навмисне: ARD займається пошуком, а не довіреністю ресурсів у продакшн.
Що саме стандартизує специфікація ARD
ARD не є проєктом AWS. Специфікація була оголошена 17 червня 2026 року робочою групою, до якої входять Google, Microsoft, Hugging Face та GoDaddy, а також Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow і Snowflake як співробітники запуску. Вона ліцензована під Apache 2.0 і опублікована на agenticresourcediscovery.org, з референтними реалізаціями на GitHub. AWS надавав відгуки під час розробки, а не створював специфікацію.
Згідно оголошення Google, архітектура базується на двох примітивах. Каталог — це файл, який організація публікує під власним доменом (ai-catalog.json за відомим шляхом), описуючи доступних агентів, MCP‑сервери, A2A‑агенти, інструменти OpenAPI або вкладені каталоги, при цьому володіння доменом слугує криптографічною основою ідентичності видавця. Реєстри діють як пошукові системи над цими каталогами: вони сканують, індексують і відповідають на запити простою мовою, повертаючи збіги разом з перевірними метаданими довіри, які клієнту потрібні для підтвердження ідентичності видавця перед підключенням.
Межа, яку визначає ARD, — це виявлення, а не виконання. Клієнт, який знаходить ресурс через ARD, викликає його за допомогою будь‑якого механізму, яким ресурс нативно спілкується: MCP, API, фреймворк агентів. На сайті специфікації чітко зазначено, що ARD не є середовищем виконання, не замінює MCP чи протокол A2A і не є центральним каталогом; дизайн передбачає багато служб виявлення, кожна з яких застосовує власні політики довіри та ранжування. Аналогія AWS — DNS: локальні реєстри федератуються через спільний протокол без двосторонніх угод чи пропрієтарних конекторів, так само, як працює розв’язання імен у мережах.
Як елементи взаємодіють між собою
Для клієнтів Agent Registry пропозиція полягає у федерації без міграції. Організація з інфраструктурою агентів, розподіленою між хмарами, локальними системами та SaaS‑інструментами, може представити все це у форматі ARD і зробити доступним для виявлення в різних середовищах, зберігаючи контроль локально, а також може опублікувати каталог у власному домені для виявлення будь‑яким клієнтом, сумісним з ARD, відкриваючи міжорганізаційні шляхи, недоступні для реєстру одного постачальника.
AWS також виходить на ринок з готовим продуктом, тоді як інші ще розробляються. Власний Agent Registry Google, частина Gemini Enterprise Agent Platform, планує додати вбудовану підтримку ARD у найближчі місяці; GitHub і Hugging Face — серед учасників робочої групи, що стоять за специфікацією. У всіх трьох хмарах спостерігається однакова модель: керований, регульований реєстр всередині та відкритий протокол федерації зовні.
Умовою є те, що інтеграція, описана у пості AWS, є односторонньою, а не готовою до випуску. AWS вказує, що очікує від ARD для клієнтів Agent Registry, замість оголошення дати поставки, і сам реєстр залишаєтся у прев’ю. 24 серпня 2026 року встановлює узгодженість: найбільший хмарний провайдер назвав відкриту специфікацію, з якою планує федерацію, і це саме та сама, яку розробляють Google та Microsoft.
