AWS Apoia a Agentic Resource Discovery como Camada de Federação para o Registro de Agentes

A Amazon Web Services colocou seu peso por trás da especificação Agentic Resource Discovery, publicando um relato detalhado em 24 de agosto de 2026 sobre como o padrão aberto deve funcionar ao lado do AWS Agent Registry, seu catálogo gerenciado para agentes de IA, ferramentas e habilidades que entrou em pré‑visualização no início deste ano.

A publicação da AWS apresenta o ARD como a resposta para um problema que o próprio produto da AWS deixa em aberto. O AWS Agent Registry, disponível através do Amazon Bedrock AgentCore, fornece a uma organização um catálogo centralizado e pesquisável de agentes, servidores MCP, ferramentas, habilidades de agentes e recursos personalizados, porém apenas dentro do seu próprio ambiente AWS. A maioria das empresas opera agentes em múltiplas nuvens, infraestruturas on‑premises e plataformas SaaS, cada uma com seu próprio registro e formato de metadados, e conectar esses ambientes hoje significa construir conectores sob medida entre cada par de registros.

O ARD propõe a alternativa de formato compartilhado: se cada registro descreve recursos da mesma forma e expõe a descoberta por meio de um protocolo comum, os publicadores descrevem seus recursos uma única vez e os consumidores os descobrem em qualquer lugar.

Dentro do Modelo do AWS Agent Registry

O registro, atualmente em pré‑visualização através do Amazon Bedrock AgentCore, é construído em torno de dois conceitos: registros, que são catálogos que um administrador cria com suas próprias configurações de autorização e aprovação, e entradas, os metadados que descrevem cada recurso. O fluxo de publicação segue de administrador para publicador, para curador, para consumidor, com um ponto de aprovação antes que qualquer entrada se torne descobrível. O acesso é controlado por credenciais do AWS Identity and Access Management ou por JSON Web Tokens de um provedor de identidade corporativo, e o próprio registro é exposto como um endpoint MCP remoto, de modo que qualquer cliente compatível com MCP pode pesquisá‑lo diretamente.

Essa camada de governança é a parte que a AWS se preocupa em preservar. Na publicação, a AWS descreve o ARD como uma camada de interoperabilidade que fica fora do ponto de aplicação: a organização que publica um catálogo controla o que está nele, quem pode vê‑lo e quando revogar o acesso, enquanto os controles de aprovação e acesso existentes do Agent Registry permanecem onde a política é realmente aplicada. A redação é deliberada: o ARD lida com a descoberta de recursos, não com a confiança deles em produção.

O que a Especificação ARD Realmente Padroniza

O ARD não é um projeto da AWS. A especificação foi anunciada em 17 de junho de 2026 por um grupo de trabalho cujos participantes incluem Google, Microsoft, Hugging Face e GoDaddy, com Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow e Snowflake entre os colaboradores do lançamento. Ela está licenciada sob Apache 2.0 e publicada em agenticresourcediscovery.org, com implementações de referência no GitHub. A AWS contribuiu com feedback durante o desenvolvimento, em vez de redigir a especificação.

De acordo com o anúncio do Google, a arquitetura se baseia em dois primitivos. Um catálogo é um arquivo que uma organização publica sob seu próprio domínio (um ai-catalog.json em um caminho bem‑conhecido) descrevendo seus agentes disponíveis, servidores MCP, agentes A2A, ferramentas OpenAPI ou catálogos aninhados, com a propriedade do domínio servindo como base criptográfica para a identidade do publicador. Os registros funcionam como mecanismos de busca sobre esses catálogos: eles rastreiam, indexam e respondem a solicitações de descoberta em linguagem natural, retornando correspondências juntamente com os metadados de confiança verificáveis que um cliente precisa para confirmar a identidade do publicador antes de se conectar.

O limite que o ARD estabelece é a descoberta, não a execução. Um cliente que encontra um recurso via ARD o invoca por meio de qualquer mecanismo que o recurso suporte nativamente: MCP, uma API, um framework de agente. O próprio site da especificação deixa claro que o ARD não é um runtime, não substitui o MCP ou o protocolo A2A, e não é um catálogo central; o design pressupõe múltiplos serviços de descoberta, cada um aplicando suas próprias políticas de confiança e classificação. A analogia da AWS é o DNS: registros locais federam por meio do protocolo compartilhado sem acordos bilaterais ou conectores proprietários, da mesma forma que a resolução de nomes funciona em redes.

Como as Peças se Encaixam

Para os clientes do Agent Registry, a proposta é federar sem migração. Uma organização com infraestrutura agêncica distribuída entre nuvens, sistemas on‑premises e ferramentas SaaS poderia expor tudo no formato do ARD e torná‑lo descobrível em diferentes ambientes, mantendo o controle local, e poderia publicar um catálogo em seu próprio domínio para descoberta por qualquer cliente compatível com ARD, abrindo caminhos interorganizacionais que um registro de fornecedor único não consegue alcançar.

A AWS também está chegando com o produto pronto enquanto outros ainda estão em desenvolvimento. O próprio Agent Registry da Google, parte da sua Gemini Enterprise Agent Platform, está programado para adicionar suporte nativo ao ARD nos próximos meses; GitHub e Hugging Face estão entre os participantes do grupo de trabalho por trás da especificação. O padrão em todas as três nuvens é o mesmo: um registro gerenciado e governado internamente, e um protocolo aberto de federação externamente.

A ressalva é que a integração descrita na publicação da AWS é direcional, não está disponível ainda. A AWS indica o que espera que o ARD possibilite para os clientes do Agent Registry, em vez de anunciar uma data de entrega, e o registro ainda permanece em pré‑visualização. O que 24 de agosto de 2026 estabelece é alinhamento: o maior provedor de nuvem nomeou a especificação aberta com a qual pretende federar, e é a mesma que Google e Microsoft estão desenvolvendo.