AWS bakker Agentic Resource Discovery som federationslag for Agent Registry

Amazon Web Services har lagt sin vægt bag specifikationen Agentic Resource Discovery og offentliggjorde den 24. august 2026 en detaljeret redegørelse for, hvordan den åbne standard skal fungere sammen med AWS Agent Registry, dens administrerede katalog for AI‑agenter, værktøjer og færdigheder, som gik i preview tidligere i år.

Det AWS‑indlæg præsenterer ARD som svaret på et problem, som AWS’s eget produkt efterlader uløst. AWS Agent Registry, tilgængelig via Amazon Bedrock AgentCore, giver en organisation et centraliseret, søgbart katalog for agenter, MCP‑servere, værktøjer, agent‑færdigheder og brugerdefinerede ressourcer, men kun inden for sit eget AWS‑miljø. De fleste virksomheder kører agenter på tværs af flere sky‑platforme, on‑premise‑infrastruktur og SaaS‑tjenester, hver med sit eget register og metadataformat, og at bygge bro mellem disse miljøer i dag betyder at udvikle skræddersyede forbindelser mellem hver kombination af registre.

ARD foreslår det fælles‑format alternativ: hvis hvert register beskriver ressourcer på samme måde og eksponerer opdagelse via en fælles protokol, beskriver udgivere deres ressourcer én gang, og forbrugere kan finde dem overalt.

Inden for AWS Agent Registry‑modellen

Registeret, som i øjeblikket er i preview via Amazon Bedrock AgentCore, er bygget omkring to begreber: registre, som er kataloger en administrator opretter med sine egne autorisations‑ og godkendelsesindstillinger, og poster, metadata‑indgangene der beskriver hver ressource. Publiceringsarbejdsgangen går fra administrator til udgiver til kurator til forbruger, med en godkendelsesgate før nogen post bliver søgbar. Adgang styres via AWS Identity and Access Management‑legitimationsoplysninger eller JSON Web Tokens fra en virksomhedens identitetsudbyder, og selve registret eksponeres som et fjern‑MCP‑endpoint, så enhver MCP‑kompatibel klient kan søge i det direkte.

Dette styringslag er den del, som AWS er omhyggelig med at bevare. I indlægget beskriver AWS ARD som et interoperabilitetslag, der ligger uden for håndhævelsespunktet: den organisation, der udgiver et katalog, kontrollerer hvad der er i det, hvem der kan se det, og hvornår adgangen skal tilbagekaldes, mens Agent Registrys eksisterende godkendelses‑ og adgangskontroller forbliver, hvor politikken faktisk håndhæves. Formuleringen er bevidst: ARD håndterer at finde ting, ikke at stole på dem i produktion.

Hvad ARD‑specifikationen faktisk standardiserer

ARD er ikke et AWS‑projekt. Specifikationen blev annonceret den 17. juni 2026 af en arbejdsgruppe, hvis deltagere inkluderer Google, Microsoft, Hugging Face og GoDaddy, med Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow og Snowflake blandt samarbejderne ved lanceringen. Den er licenseret under Apache 2.0 og offentliggjort på agenticresourcediscovery.org, med reference‑implementeringer på GitHub. AWS bidrog med feedback under udviklingen i stedet for at forfatte specifikationen.

Ifølge Googles annoncering hviler arkitekturen på to grundlæggende elementer. Et katalog er en fil, som en organisation udgiver under sit eget domæne (et ai-catalog.json på en velkendt sti), der beskriver de tilgængelige agenter, MCP‑servere, A2A‑agenter, OpenAPI‑værktøjer eller indlejrede kataloger, hvor domæneeje fungerer som den kryptografiske basis for udgiverens identitet. Registre fungerer som søgemaskiner over disse kataloger: de crawler, indekserer og besvarer naturlige forespørgsler om opdagelse, returnerer resultater sammen med den verificerbare tillids‑metadata, som en klient har brug for at bekræfte udgiverens identitet, før den opretter forbindelse.

Den grænse, som ARD trækker, er opdagelse, ikke udførelse. En klient, der finder en ressource via ARD, kalder den gennem den mekanisme, som ressourcen naturligt understøtter: MCP, et API, et agent‑framework. Specifikationens egen side gør det klart, at ARD ikke er et runtime‑miljø, ikke en erstatning for MCP eller A2A‑protokollen, og ikke et centralt katalog; designet forudsætter mange opdagelsestjenester, som hver anvender deres egne tillids‑ og rangeringspolitikker. AWS’s analogi er DNS: lokale registre federerer gennem den fælles protokol uden bilaterale aftaler eller proprietære forbindelser, på samme måde som navneopløsning fungerer på tværs af netværk.

Hvordan brikkerne passer sammen

For Agent Registry‑kunder er budskabet federation uden migration. En organisation med agent‑infrastruktur spredt over sky‑platforme, on‑premise‑systemer og SaaS‑værktøjer kan eksponere alt i ARD‑formatet og gøre det søgbart på tværs af miljøer, mens den bevarer kontrol lokalt, og kan udgive et katalog på sit eget domæne, så enhver ARD‑kompatibel klient kan opdage det, hvilket åbner tvær‑organisatoriske veje, som et enkelt‑leverandør‑register ikke kan nå.

AWS kommer også med et færdigt produkt, mens andre stadig er under udvikling. Googles egen Agent Registry, som er en del af Gemini Enterprise Agent Platform, forventes at få indbygget native ARD‑understøttelse i de kommende måneder; GitHub og Hugging Face er blandt arbejdsgruppens deltagere bag specifikationen. Mønsteret på tværs af alle tre sky‑platforme er det samme: et administreret, styret register indvendigt og en åben federationsprotokol udvendigt.

Forbeholdet er, at integrationen beskrevet i AWS‑indlægget er retningsbestemt, ikke leveret. AWS angiver, hvad de forventer, at ARD skal muliggøre for Agent Registry‑kunder, i stedet for at annoncere en leveringsdato, og registret forbliver i preview. Det, som den 24. august 2026 fastslår, er enighed: den største cloud‑udbyder har navngivet den åbne specifikation, de har til hensigt at federere med, og det er den samme, som Google og Microsoft arbejder hen imod.