AWS stödjer Agentisk Resursupptäckt som federationslager för Agent Registry

Amazon Web Services har ställt sin tyngd bakom specifikationen Agentic Resource Discovery och publicerade den 24 augusti 2026 en detaljerad redogörelse för hur den öppna standarden är avsedd att fungera tillsammans med AWS Agent Registry, dess hanterade katalog för AI‑agenter, verktyg och färdigheter som gick in i förhandsgranskning tidigare i år.

AWS‑inlägg presenterar ARD som svaret på ett problem som AWS:s egen produkt lämnar öppet. AWS Agent Registry, tillgänglig via Amazon Bedrock AgentCore, ger en organisation en centraliserad, sökbar katalog för agenter, MCP‑servrar, verktyg, agentskicklighet och anpassade resurser, men endast inom sin egen AWS‑miljö. De flesta företag kör agenter över flera moln, lokala infrastrukturer och SaaS‑plattformar, var och en med sin egen register och metadataformat, och att förena dessa miljöer idag innebär att bygga skräddarsydda anslutningar mellan varje par av register.

ARD föreslår det delade formatet som alternativ: om varje register beskriver resurser på samma sätt och exponerar upptäckt via ett gemensamt protokoll, beskriver publicister sina resurser en gång och konsumenter kan upptäcka dem överallt.

Inuti AWS Agent Registry-modellen

Registret, som för närvarande är i förhandsgranskning via Amazon Bedrock AgentCore, är byggt kring två koncept: register, som är kataloger en administratör skapar med egna behörighets- och godkännandinställningar, och poster, metadata‑poster som beskriver varje resurs. Publiceringsflödet går från administratör till publicist till kurator till konsument, med en godkännandebrunn innan någon post blir upptäckbar. Åtkomst styrs via AWS Identity and Access Management‑uppgifter eller JSON Web Tokens från en företags‑identitetsleverantör, och registret själv exponeras som en fjärr‑MCP‑ändpunkt, så att vilken MCP‑kompatibel klient som helst kan söka i det direkt.

Det styrningslagret är den del som AWS är noga med att bevara. I inlägget beskriver AWS ARD som ett interoperabilitetslager som ligger utanför verkställningspunkten: den organisation som publicerar en katalog kontrollerar vad som finns i den, vem som kan se den och när åtkomsten ska återkallas, medan Agent Registrys befintliga godkännande‑ och åtkomstkontroller förblir där policyn faktiskt verkställs. Formuleringen är avsiktlig: ARD hanterar att hitta saker, inte att lita på dem i produktion.

Vad ARD‑specifikationen faktiskt standardiserar

ARD är inte ett AWS‑projekt. Specifikationen tillkännagavs den 17 juni 2026 av en arbetsgrupp vars deltagare inkluderar Google, Microsoft, Hugging Face och GoDaddy, med Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow och Snowflake bland samarbetspartnerna vid lanseringen. Den är licensierad under Apache 2.0 och publicerad på agenticresourcediscovery.org, med referensimplementationer på GitHub. AWS bidrog med feedback under utvecklingen snarare än att författa specifikationen.

Googles tillkännagivande visar att arkitekturen vilar på två grundläggande byggstenar. En katalog är en fil som en organisation publicerar under sin egen domän (en ai-catalog.json på en välkänd sökväg) och beskriver dess tillgängliga agenter, MCP‑servrar, A2A‑agenter, OpenAPI‑verktyg eller nästlade kataloger, där domänägande fungerar som den kryptografiska grunden för publicistens identitet. Register fungerar som sökmotorer för dessa kataloger: de genomsöker, indexerar och svarar på enkla språk‑förfrågningar om upptäckt, returnerar träffar tillsammans med den verifierbara förtroendemetadata som en klient behöver för att bekräfta en publicistens identitet innan anslutning.

Den gräns som ARD drar är upptäckt, inte exekvering. En klient som hittar en resurs via ARD anropar den genom den mekanism som resursen naturligt stödjer: MCP, ett API, ett agent‑ramverk. Specifikationssajten är tydlig med att ARD inte är en körmiljö, inte en ersättning för MCP eller A2A‑protokollet, och inte en central katalog; designen förutsätter många upptäckningstjänster, var och en med egna förtroende‑ och rankningspolicyer. AWS:s analogi är DNS: lokala register federerar via det gemensamma protokollet utan bilaterala avtal eller proprietära anslutningar, på samma sätt som namnupplösning fungerar över nätverk.

Hur delarna passar ihop

För kunder av Agent Registry är budskapet federation utan migrering. En organisation med agentisk infrastruktur spridd över moln, lokala system och SaaS‑verktyg kan exponera allt i ARD‑formatet och göra det upptäckbart över miljöer samtidigt som kontrollen behålls lokalt, och kan publicera en katalog på sin egen domän för upptäckt av vilken ARD‑kompatibel klient som helst, vilket öppnar tvärorganisatoriska vägar som ett register från en enda leverantör inte kan nå.

AWS kommer också med en färdig produkt medan andra fortfarande bygger. Googles egna Agent Registry, en del av dess Gemini Enterprise Agent Platform, planeras att få inbyggt ARD‑stöd under de kommande månaderna; GitHub och Hugging Face är bland arbetsgruppens deltagare bakom specifikationen. Mönstret över alla tre moln är detsamma: ett hanterat, styrt register på insidan och ett öppet federationsprotokoll på utsidan.

Förbehållet är att integrationen som beskrivs i AWS‑inlägget är riktad, inte levererad. AWS anger vad de förväntar sig att ARD ska möjliggöra för Agent Registry‑kunder snarare än att meddela ett leveransdatum, och registret självt förblir i förhandsgranskning. Vad den 24 augusti 2026 fastställer är samstämmighet: den största molnleverantören har namngivit den öppna specifikation som den avser att federera med, och det är samma som Google och Microsoft bygger mot.