AWS wspiera Agentic Resource Discovery jako warstwę federacji dla Agent Registry

Amazon Web Services poprzeć specyfikację Agentic Resource Discovery, publikując szczegółowy opis 24 sierpnia 2026 r., jak otwarty standard ma współpracować z AWS Agent Registry, zarządzanym katalogiem agentów AI, narzędzi i umiejętności, który wszedł w fazę podglądu wcześniej w tym roku.

Wpis AWS post przedstawia ARD jako odpowiedź na problem, który pozostawia otwarte własny produkt AWS. AWS Agent Registry, dostępny poprzez Amazon Bedrock AgentCore, zapewnia organizacji scentralizowany, przeszukiwalny katalog agentów, serwerów MCP, narzędzi, umiejętności agentów i zasobów niestandardowych, ale wyłącznie w obrębie własnego środowiska AWS. Większość przedsiębiorstw uruchamia agentów w wielu chmurach, infrastrukturze lokalnej i platformach SaaS, z których każda posiada własny rejestr i format metadanych, a łączenie tych środowisk wymaga dziś budowania dedykowanych łączników pomiędzy każdą parą rejestrów.

ARD proponuje alternatywę w postaci wspólnego formatu: jeśli każdy rejestr opisuje zasoby w ten sam sposób i udostępnia ich odkrywanie poprzez wspólny protokół, wydawcy opisują swoje zasoby raz, a konsumenci mogą je odkrywać wszędzie.

Wewnątrz modelu AWS Agent Registry

Rejestr, obecnie w fazie podglądu poprzez Amazon Bedrock AgentCore, opiera się na dwóch koncepcjach: rejestrach, które są katalogami tworzonymi przez administratora z własnymi ustawieniami autoryzacji i zatwierdzania, oraz rekordach, czyli wpisach metadanych opisujących każdy zasób. Proces publikacji przebiega od administratora do wydawcy, kuratora i konsumenta, z bramką zatwierdzającą przed udostępnieniem jakiegokolwiek rekordu do odkrywania. Dostęp kontrolowany jest za pomocą poświadczeń AWS Identity and Access Management lub tokenów JSON Web Token od dostawcy tożsamości korporacyjnej, a sam rejestr udostępniany jest jako zdalny punkt końcowy MCP, dzięki czemu każdy klient kompatybilny z MCP może go przeszukiwać bezpośrednio.

Ta warstwa zarządzania jest częścią, którą AWS starannie zachowuje. W wpisie AWS opisuje ARD jako warstwę interoperacyjności znajdującą się poza punktem egzekwowania: organizacja publikująca katalog kontroluje, co się w nim znajduje, kto może je zobaczyć i kiedy odwołać dostęp, przy czym istniejące mechanizmy zatwierdzania i kontroli dostępu Agent Registry pozostają tam, gdzie polityka jest faktycznie egzekwowana. Sformułowanie jest celowe: ARD zajmuje się znajdowaniem zasobów, a nie ich wdrażaniem do produkcji.

Co specyfikacja ARD faktycznie standaryzuje

ARD nie jest projektem AWS. Specyfikacja została ogłoszona 17 czerwca 2026 r. przez grupę roboczą, w której uczestniczą Google, Microsoft, Hugging Face i GoDaddy, a wśród współpracowników przy uruchomieniu znajdują się Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow i Snowflake. Jest licencjonowana na licencji Apache 2.0 i opublikowana pod adresem agenticresourcediscovery.org, z implementacjami referencyjnymi na GitHubie. AWS wniósł uwagi w trakcie rozwoju, a nie opracował specyfikacji.

Zgodnie z ogłoszeniem Google, architektura opiera się na dwóch podstawowych elementach. Katalog to plik, który organizacja publikuje pod własną domeną (ai-catalog.json pod dobrze znaną ścieżką), opisujący dostępnych agentów, serwery MCP, agentów A2A, narzędzia OpenAPI lub zagnieżdżone katalogi, przy czym własność domeny służy jako kryptograficzna podstawa tożsamości wydawcy. Rejestry działają jako silniki wyszukiwania tych katalogów: przeszukują, indeksują i odpowiadają na zapytania odkrywania w języku naturalnym, zwracając dopasowania wraz z weryfikowalnymi metadanymi zaufania, których klient potrzebuje, aby potwierdzić tożsamość wydawcy przed nawiązaniem połączenia.

Granica wyznaczona przez ARD to odkrywanie, a nie wykonywanie. Klient, który znajdzie zasób za pośrednictwem ARD, wywołuje go przy użyciu dowolnego mechanizmu, którym zasób natywnie się posługuje: MCP, API, frameworka agenta. Strona specyfikacji wyraźnie podkreśla, że ARD nie jest środowiskiem uruchomieniowym, nie zastępuje MCP ani protokołu A2A i nie jest centralnym katalogiem; projekt zakłada wiele usług odkrywania, z których każda stosuje własne zasady zaufania i rankingowania. Analogia AWS to DNS: lokalne rejestry federują się poprzez wspólny protokół bez dwustronnych umów czy własnościowych łączników, tak jak działa rozwiązywanie nazw w sieciach.

Jak elementy współgrają ze sobą

Dla klientów Agent Registry oferta brzmi: federacja bez migracji. Organizacja posiadająca infrastrukturę agentową rozproszoną w chmurach, systemach lokalnych i narzędziach SaaS może udostępnić wszystko w formacie ARD i uczynić to odkrywalnym w różnych środowiskach, zachowując jednocześnie lokalną kontrolę, a także opublikować katalog pod własną domeną, aby był dostępny dla dowolnego klienta kompatybilnego z ARD, otwierając ścieżki międzyorganizacyjne, które nie są osiągalne dla rejestru jednego dostawcy.

AWS również wprowadza produkt, podczas gdy inni wciąż go budują. Własny Agent Registry Google, będący częścią platformy Gemini Enterprise Agent Platform, ma w najbliższych miesiącach uzyskać natywną obsługę ARD; GitHub i Hugging Face należą do uczestników grupy roboczej stojącej za specyfikacją. Wzorzec we wszystkich trzech chmurach jest taki sam: zarządzany, kontrolowany rejestr po wewnętrznej stronie oraz otwarty protokół federacji po stronie zewnętrznej.

Zastrzeżenie brzmi, że opisane w wpisie AWS połączenie jest jednostronne, a nie dostarczone jako gotowy produkt. AWS określa, co oczekuje, że ARD umożliwi klientom Agent Registry, zamiast podawać datę wdrożenia, a sam rejestr pozostaje w fazie podglądu. To, co 24 sierpnia 2026 r. ustanawia, to zgodność: największy dostawca chmur wymienił otwartą specyfikację, z którą zamierza się federować, i jest to ta sama, do której dążą Google i Microsoft.