AWS supporta Agentic Resource Discovery come livello di federazione per Agent Registry

Amazon Web Services ha messo il suo peso a sostegno della specifica Agentic Resource Discovery, pubblicando un resoconto dettagliato il 24 agosto 2026 su come lo standard aperto debba funzionare accanto ad AWS Agent Registry, il suo catalogo gestito per agenti AI, strumenti e competenze, entrato in anteprima all’inizio di quest’anno.

Il post di AWS presenta ARD come risposta a un problema lasciato aperto dal prodotto di AWS. AWS Agent Registry, disponibile tramite Amazon Bedrock AgentCore, fornisce a un’organizzazione un catalogo centralizzato e ricercabile per agenti, server MCP, strumenti, competenze degli agenti e risorse personalizzate, ma solo all’interno del proprio ambiente AWS. La maggior parte delle imprese utilizza agenti su più cloud, infrastrutture on-premises e piattaforme SaaS, ognuna con il proprio registro e formato di metadati, e collegare oggi questi ambienti significa costruire connettori su misura tra ogni coppia di registri.

ARD propone l’alternativa a formato condiviso: se ogni registro descrive le risorse nello stesso modo e le rende scopribili tramite un protocollo comune, gli editori descrivono le loro risorse una sola volta e i consumatori le scoprono ovunque.

All’interno del modello AWS Agent Registry

Il registro, attualmente in anteprima tramite Amazon Bedrock AgentCore, è costruito attorno a due concetti: registri, che sono cataloghi che un amministratore crea con le proprie impostazioni di autorizzazione e approvazione, e record, le voci di metadati che descrivono ogni risorsa. Il flusso di pubblicazione procede da amministratore a editore a curatore a consumatore, con un punto di approvazione prima che qualsiasi record diventi scopribile. L’accesso è controllato tramite credenziali AWS Identity and Access Management o JSON Web Token da un provider di identità aziendale, e il registro stesso è esposto come endpoint MCP remoto, così qualsiasi client compatibile MCP può cercarlo direttamente.

Quello strato di governance è la parte che AWS si impegna a preservare. Nel post, AWS descrive ARD come uno strato di interoperabilità situato al di fuori del punto di applicazione: l’organizzazione che pubblica un catalogo controlla cosa contiene, chi può vederlo e quando revocare l’accesso, con i controlli di approvazione e accesso esistenti di Agent Registry che rimangono dove la politica è effettivamente applicata. Il linguaggio è deliberato: ARD gestisce la scoperta delle cose, non la loro affidabilità in produzione.

Cosa standardizza realmente la specifica ARD

ARD non è un progetto AWS. La specifica è stata annunciata il 17 giugno 2026 da un gruppo di lavoro i cui partecipanti includono Google, Microsoft, Hugging Face e GoDaddy, con Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow e Snowflake tra i collaboratori del lancio. È rilasciata sotto licenza Apache 2.0 e pubblicata su agenticresourcediscovery.org, con implementazioni di riferimento su GitHub. AWS ha fornito feedback durante lo sviluppo anziché redigere la specifica.

Secondo l’annuncio di Google, l’architettura si basa su due primitive. Un catalogo è un file che un’organizzazione pubblica sotto il proprio dominio (un ai-catalog.json in un percorso ben noto) descrivente i suoi agenti disponibili, server MCP, agenti A2A, strumenti OpenAPI o cataloghi annidati, con la proprietà del dominio che funge da base crittografica per l’identità dell’editore. I registri agiscono come motori di ricerca su tali cataloghi: eseguono crawling, indicizzazione e rispondono a richieste di scoperta in linguaggio naturale, restituendo corrispondenze insieme ai metadati di fiducia verificabili di cui un client ha bisogno per confermare l’identità dell’editore prima di connettersi.

Il confine che ARD traccia è la scoperta, non l’esecuzione. Un client che trova una risorsa tramite ARD la invoca attraverso qualunque meccanismo nativo della risorsa: MCP, un’API, un framework per agenti. Il sito della specifica è esplicito nel precisare che ARD non è un runtime, non è una sostituzione per MCP o il protocollo A2A, e non è un catalogo centrale; il design presuppone molti servizi di scoperta, ognuno dei quali applica le proprie politiche di fiducia e ranking. L’analogia di AWS è il DNS: i registri locali si federano tramite il protocollo condiviso senza accordi bilaterali o connettori proprietari, come avviene per la risoluzione dei nomi nelle reti.

Come i componenti si integrano

Per i clienti di Agent Registry, la proposta è una federazione senza migrazione. Un’organizzazione con infrastruttura agentica distribuita su cloud, sistemi on-premises e strumenti SaaS potrebbe esporre tutto nel formato ARD e renderlo scopribile tra ambienti mantenendo il controllo locale, e potrebbe pubblicare un catalogo sul proprio dominio per la scoperta da parte di qualsiasi client compatibile ARD, aprendo percorsi inter-organizzativi che un registro di un unico fornitore non può raggiungere.

AWS arriva anche con un prodotto pronto mentre gli altri sono ancora in fase di sviluppo. L’Agent Registry di Google, parte della sua Gemini Enterprise Agent Platform, prevede di aggiungere il supporto nativo a ARD nei prossimi mesi; GitHub e Hugging Face sono tra i partecipanti al gruppo di lavoro dietro la specifica. Il modello su tutti e tre i cloud è lo stesso: un registro gestito e governato internamente, un protocollo di federazione aperto all’esterno.

La precisazione è che l’integrazione descritta nel post di AWS è direzionale, non ancora rilasciata. AWS indica ciò che si aspetta che ARD consenta per i clienti di Agent Registry invece di annunciare una data di consegna, e il registro stesso rimane in anteprima. Ciò che il 24 agosto 2026 stabilisce è l’allineamento: il più grande provider cloud ha nominato la specifica aperta con cui intende federarsi, ed è la stessa verso cui Google e Microsoft stanno lavorando.