ARD — Agentic Resource Discovery: A Camada que Faltava no Ecossistema de Agentes

Imagine um hotel cinco estrelas com 200 quartos, spa, três restaurantes e um centro de conferências. Agora imagine que o concierge não tem acesso à lista de serviços. Ele sabe atender — é treinado, educado, eficiente — mas quando o hóspede pergunta “vocês têm um chef japonês?”, ele precisa ligar para cada setor, um por um, perguntando se existe. Multiplique isso por 50 hóspedes simultâneos.

Esse é o estado atual do ecossistema de agentes IA.

Temos o MCP para um agente chamar ferramentas. Temos o A2A para agentes conversarem entre si. Mas quando um agente precisa responder “quem, nesse ecossistema, sabe fazer o que eu preciso?” — não há protocolo padrão. Ele depende de configuração manual, listas estáticas ou, pior, hardcode de endpoints.

O ARD — Agentic Resource Discovery é a especificação que resolve esse gap. É a lista de serviços do hotel, atualizada em tempo real, com verificação de identidade e busca semântica. Publicada em 17 de junho de 2026 como v0.9 (Draft), já conta com contribuições de Google, Microsoft, Hugging Face, GoDaddy, GitHub, Cisco, Databricks, NVIDIA, Salesforce, ServiceNow e Snowflake.

Não é coincidência que essas empresas estejam todas na mesa. O discovery é o gargalo que impede agentes de operarem em ecossistemas abertos. Sem ele, cada integração é um contrato bilateral negociado manualmente. Com ele, a web de agentes funciona como a web de documentos: publicou, está descobrível.

O que é ARD

ARD é uma especificação aberta (Apache 2.0) que define como agentes de IA descobrem capabilities, ferramentas e outros agentes disponíveis em um ecossistema. Foi construída sobre o ai-catalog standard da Linux Foundation AI Catalog Working Group.

Os autores — Junjie Bu (Google), R.V. Guha (Microsoft) e Shaun Smith (Hugging Face) — atacam um problema fundamental: à medida que o número de agentes e ferramentas cresce, o discovery manual não escala.

O repositório oficial fica em github.com/ards-project/ard-spec (398 stars, 46 forks, 91 commits em julho de 2026), com documentação em agenticresourcediscovery.org.

A arquitetura se apoia em duas primitivas:

Catálogo estático — um arquivo ai-catalog.json que cada publisher hospeda no seu domínio
Registry dinâmico — uma API com endpoint POST /search para busca semântica em tempo real

Pense no catálogo como a plaquinha na porta do quarto de hotel (“Suíte Master, capacidade 4 pessoas, vista mar”). O registry é o sistema de reservas que cruza sua busca (“quarto com vista mar para amanhã”) com tudo que está disponível.

Catálogo Estático: ai-catalog.json

O ponto de entrada mais simples do ARD é o catálogo estático. Você cria um arquivo JSON e hospeda em /.well-known/ai-catalog.json no seu domínio. Qualquer agente que conheça essa convenção pode fazer discovery automático dos seus recursos.

Aqui está a estrutura real de um catálogo:

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Acme Corp AI",
    "identifier": "did:web:acme.corp"
  },
  "entries": [
    {
      "identifier": "urn:air:acme.corp:agents:invoice-processor",
      "displayName": "Invoice Processor Agent",
      "type": "application/a2a-agent-card+json",
      "url": "https://agents.acme.corp/invoice-processor/.well-known/agent.json",
      "description": "Processa faturas em PDF, extrai dados estruturados e reconcilia com o ERP",
      "capabilities": ["pdf-extraction", "data-reconciliation", "erp-integration"],
      "representativeQueries": [
        "processar fatura em PDF e extrair dados",
        "reconciliar nota fiscal com ERP"
      ],
      "trustManifest": {
        "identity": "spiffe://acme.corp/agents/invoice-processor",
        "identityType": "spiffe",
        "attestations": [
          { "type": "SOC2-Type2", "uri": "https://trust.acme.corp/reports/soc2.pdf" },
          { "type": "GDPR", "uri": "https://trust.acme.corp/compliance/gdpr" }
        ]
      }
    },
    {
      "identifier": "urn:air:acme.corp:tools:sentiment-analysis",
      "displayName": "Sentiment Analysis Tool",
      "type": "application/mcp-server-card+json",
      "url": "https://tools.acme.corp/sentiment/mcp.json",
      "description": "Análise de sentimento multilíngue via MCP server",
      "capabilities": ["text-analysis", "multilingual", "batch-processing"],
      "representativeQueries": [
        "analisar sentimento de reviews em português",
        "classificar tom de mensagens de suporte"
      ]
    }
  ]
}

Observe os pontos-chave:

type diferencia o tipo de recurso. O ARD suporta application/a2a-agent-card+json (agentes A2A), application/mcp-server-card+json (MCP servers), application/ai-skill, application/ai-registry+json e application/ai-catalog+json
capabilities permite busca por competência, não só por nome
representativeQueries são exemplos de perguntas em linguagem natural que o recurso responde — os registries usam esses exemplos para construir embeddings semânticos e ranquear resultados
trustManifest inclui identidade verificável e attestations de compliance
Cada entry exige exatamente um de url (referência remota) ou data (artefato inline) — nunca ambos

O catálogo estático é determinístico e cacheável. Não exige infraestrutura além de um web server. Um desenvolvedor indie pode publicar um ai-catalog.json no mesmo domínio onde já hospeda seu site e tornar seus tools descobríveis por qualquer agente que implemente ARD.

Mecanismos de Discovery

Para que agentes encontrem o catálogo, o ARD define quatro mecanismos de discovery:

Well-Known URI — /.well-known/ai-catalog.json (o padrão primário)
Agentmap em robots.txt — diretiva Agentmap: apontando para o catálogo
HTML Link Tag — <link rel="ai-catalog" href="/ai-catalog.json"> no head
DNS Service Binding records — para discovery a nível de infraestrutura

Isso é deliberado. O catálogo funciona como o robots.txt funciona para crawlers: uma convenção simples que qualquer agente sabe onde buscar.

Registry Dinâmico: POST /search

O catálogo estático resolve o caso de “eu conheço o domínio e quero saber o que ele oferece”. Mas e quando você precisa buscar “quem no ecossistema faz análise de sentimento em português?”

Para isso existe o registry dinâmico. O ARD define uma API com três endpoints:

Endpoint	Método	Obrigatório?	Função
`/search`	POST	✅ Sim	Busca semântica com filtros
`/explore`	POST	Opcional	Agregações e facets
`/agents`	GET	Opcional	Listagem determinística completa

O endpoint obrigatório é o POST /search. Aqui está um request real:

{
  "query": {
    "text": "process invoices and extract structured data from PDF documents",
    "filter": {
      "type": ["application/a2a-agent-card+json"],
      "trustManifest.attestations.type": ["SOC2-Type2"]
    }
  },
  "federation": "auto",
  "pageSize": 5
}

E a resposta:

{
  "results": [
    {
      "identifier": "urn:air:acme.corp:agents:invoice-processor",
      "displayName": "Invoice Processor Agent",
      "type": "application/a2a-agent-card+json",
      "url": "https://agents.acme.corp/invoice-processor/.well-known/agent.json",
      "description": "Processa faturas em PDF, extrai dados estruturados e reconcilia com o ERP",
      "score": 92,
      "source": "https://registry.acme.corp/api/v1/"
    },
    {
      "identifier": "urn:air:fintech.io:agents:doc-extractor",
      "displayName": "Document Extraction Service",
      "type": "application/a2a-agent-card+json",
      "url": "https://api.fintech.io/.well-known/agent.json",
      "description": "Extração de dados de documentos financeiros com OCR avançado",
      "score": 78,
      "source": "https://finder.external.org/api/"
    }
  ],
  "referrals": [
    {
      "identifier": "urn:air:nlweb.ai:registry:public",
      "displayName": "Public Agent Finder",
      "type": "application/ai-registry+json",
      "url": "https://finder.nlweb.ai/search"
    }
  ],
  "pageToken": "eyJwYWdlIjogMn0="
}

O campo score merece atenção: é um valor de 0 a 100 representando relevância semântica da busca — não é um trust score. Um agente com score 92 é altamente relevante para a query textual, mas a decisão de confiar nele depende do trustManifest.

Repare no array referrals na resposta: quando o registry está no modo referrals ou auto, ele pode retornar ponteiros para outros registries que o cliente pode consultar. Isso é a federação em ação.

Identificadores URN: Endereçamento Global de Recursos

Cada recurso no ARD recebe um identificador único no formato URN (Uniform Resource Name) ancorado ao domínio do publisher:

urn:air:<publisher>:<namespace>:<resource-name>

Exemplos concretos:

URN	O que identifica
`urn:air:acme.corp:agents:invoice-processor`	Agente de processamento de faturas da Acme
`urn:air:huggingface.co:tools:text-generation`	Tool de geração de texto do Hugging Face
`urn:air:snowflake.com:agents:cortex-analyst`	Agente Cortex Analyst da Snowflake

O design é domain-anchored por uma razão: o domínio funciona como raiz de confiança. Se o URN diz urn:air:acme.corp:..., você sabe que o publisher controla acme.corp e pode verificar a identidade via DNS/TLS. Não existe um registro central — o namespace é tão distribuído quanto a própria web.

Isso resolve o problema de colisão de nomes sem exigir uma autoridade centralizada. Dois publishers podem ter um agente chamado “invoice-processor” sem conflito, porque o domínio os diferencia.

Trust Manifest: Verificação Criptográfica

Discovery sem trust é um vetor de ataque. Se qualquer agente pode se listar em um registry, como o consumidor sabe que aquele “Invoice Processor” não é um impostor?

O ARD resolve isso com o trustManifest — um objeto de metadados criptográficos que acompanha cada entry do catálogo. Ele cobre três dimensões:

1. Identidade

O publisher prova quem é através de mecanismos padronizados:

HTTPS FQDN — o mais simples: o recurso está no domínio X, e o TLS do domínio X prova ownership
SPIFFE IDs — identidade workload-level para ambientes cloud-native (ex: spiffe://acme.corp/agents/invoice-processor)
DIDs (Decentralized Identifiers) — para cenários onde identidade descentralizada é necessária

2. Attestations

Certificações e compliance verificáveis. Cada attestation tem um type e um uri apontando para o documento de prova:

{ "type": "SOC2-Type2", "uri": "https://trust.acme.corp/reports/soc2.pdf" }
{ "type": "HIPAA-Audit", "uri": "https://trust.acme.corp/compliance/hipaa" }
{ "type": "GDPR", "uri": "https://trust.acme.corp/compliance/gdpr" }

Não é um campo free-text. O formato estruturado permite que um agente consumidor filtre programaticamente por compliance requirements antes de consumir o recurso.

3. Proveniência

Metadados sobre a origem do recurso: quem criou, quando foi publicado, qual versão da spec implementa, histórico de atualizações.

O trustManifest não substitui uma avaliação de segurança completa — mas dá ao agente consumidor informações verificáveis para tomar decisões de trust automaticamente. Um agente enterprise pode ser configurado com uma política: “só consumir recursos com attestation SOC2 e identidade via SPIFFE”. O registry filtra antes de retornar resultados.

Federação: Como Registries Conversam

Em produção, não vai existir um único registry global. Empresas terão registries privados, provedores de cloud terão registries públicos, comunidades open-source terão os deles. A spec define três modos de federação para interconexão:

Modo	Comportamento	Use case
auto	Merge automático — o registry combina resultados locais com resultados de registries federados	Discovery amplo, maximiza cobertura
referrals	Retorna ponteiros para outros registries em vez de resultados diretos	Quando o registro federado exige autenticação separada
none	Só resultados locais, sem federação	Ambientes isolados, compliance strict

Na prática, federação funciona assim: seu agente faz POST /search no registry corporativo. O registry verifica localmente, e se estiver no modo auto, também consulta registries federados (ex: o registry público do Hugging Face). Os resultados voltam unificados, com indicação de origem.

O modo referrals é mais conservador — o registry diz “não tenho isso, mas o registry X pode ter” e retorna o endpoint dele. O agente decide se quer seguir o referral. Isso é útil quando registries federados exigem autenticação própria ou operam sob jurisdições diferentes.

O modo none existe para ambientes regulados onde nenhum dado deve sair do perímetro — bancos, hospitais, governo. O registry funciona como catálogo interno e ponto final.

ARD vs MCP vs A2A: O Stack Completo

“Mais um protocolo? Por que não resolve tudo com MCP?”

Porque cada um resolve uma camada diferente — e as três são necessárias:

Dimensão	MCP	A2A	ARD
Pergunta que responde	“Como chamo essa tool?”	“Como falo com esse agente?”	“Quem sabe fazer o que eu preciso?”
Camada	Execução	Comunicação	Discovery
Analogia	O telefone	A língua franca	A lista telefônica
Publisher	Anthropic	Google	Google + Microsoft + Hugging Face
Timing	Nov 2024	Abr 2025	Jun 2026
Pré-requisito	—	—	MCP e/ou A2A

ARD não substitui MCP ou A2A. É a camada que senta na frente deles. O fluxo completo funciona assim:

ARD — Agente busca “quem processa faturas em PDF com compliance SOC2?”
A2A — Agente inicia comunicação com o Invoice Processor descoberto
MCP — Durante a conversa, o Invoice Processor chama tools de OCR e ERP via MCP

Sem ARD, o passo 1 é manual — um humano configura quais agentes cada sistema conhece. Com ARD, esse discovery acontece programaticamente, em tempo real, com verificação de trust.

Os três protocolos resolvem camadas diferentes: MCP deu braços aos agentes (tools). A2A deu voz (comunicação peer-to-peer). ARD dá visão (discovery do ecossistema).

Quem Já Implementou

A spec tem pouco mais de um mês desde a publicação, mas as implementações já estão em produção ou em beta avançado:

Hugging Face — A implementação de referência. O Discover Tool (hf discover search) faz busca semântica sobre os Spaces, retornando agentes e tools no formato ARD. Se você já usa o Hugging Face, pode testar hoje.

Snowflake — Cortex Agents com auto-registro ARD. Quando você deploya um agente via Cortex, ele se registra automaticamente no registry corporativo, ficando descobrível por outros agentes do mesmo tenant.

Google Cloud — Agent Registry no Gemini Enterprise Agent Platform. Anunciado na Cloud Next ’26, disponível em breve. Será o registry nativo para quem usa Vertex AI Agent Builder.

GoDaddy — Agent Name Service (ANS), uma abordagem fascinante que usa DNS e PKI existentes como infra de identidade para agentes. Parceria com Cloudflare e Infoblox. Em vez de inventar uma nova camada de identidade, reutiliza a infraestrutura de nomes que já opera na internet há décadas.

IETF — O draft draft-hood-agtp-ard-00 está em processo de formalização, sinalizando que o ARD pode se tornar um padrão da internet (RFC), não só uma spec de indústria.

Implementações independentes — O Suganthan.com publicou um ai-catalog.json no seu domínio e relatou que um agente externo o descobriu automaticamente e interagiu com seus recursos — validando o modelo de discovery descentralizado na prática. Isso demonstra que ARD não é só para big tech: qualquer publisher com um domínio e um JSON pode participar do ecossistema.

O que Muda pra Você

Se você trabalha com agentes de IA — como desenvolvedor, arquiteto, ou product owner — o ARD altera o jogo em três dimensões:

Se você publica ferramentas ou agentes

Publicar um ai-catalog.json no seu domínio é o novo “SEO para agentes”. Assim como você otimiza páginas para o Google encontrá-las, agora precisa publicar metadados estruturados para agentes encontrarem seus serviços.

O custo é mínimo — um arquivo JSON estático no well-known path. O retorno potencial é descobribilidade automática por qualquer agente que implemente ARD. Se você mantém um MCP server público ou um agente A2A, o catálogo é o que conecta esse recurso ao ecossistema sem depender de cadastro manual em marketplaces terceiros.

Se você constrói sistemas multi-agente

Discovery dinâmico via registry significa que seu orquestrador não precisa de uma lista estática de agentes disponíveis. Ele pode buscar capabilities em tempo real, adaptar-se a novos agentes que aparecem no ecossistema, e respeitar políticas de trust automaticamente.

Isso transforma arquiteturas multi-agente de “configuração manual para cada integração” para “discovery e composição em runtime”.

Se você opera agentes em enterprise

O trust manifest é a peça que faltava para governança. Políticas corporativas podem ser expressas como filtros de registry: “só agentes com SPIFFE ID do nosso cluster”, “só recursos com SOC2 e GDPR”, “federar com o registry da consultoria X mas não com registries públicos”.

Isso dá ao security team controle programático sobre quais recursos os agentes internos podem descobrir e consumir — sem bloquear a agilidade dos times que deployam novos agentes.

MCP para execução, A2A para comunicação, ARD para discovery. Cada camada resolve um problema distinto, e juntas formam a infraestrutura para agentes operarem em ecossistemas abertos — não em silos configurados à mão.

O ARD v0.9 ainda é draft. Vai evoluir, schemas vão mudar, e haverá edge cases não cobertos. Mas o modelo mental — catálogo estático para publishers, registry dinâmico para busca, trustManifest para segurança, federação para escala — já está claro. E já está em produção.

Se você publica tools ou agentes: crie seu ai-catalog.json. Se você consome: comece a integrar busca via registry. O custo de adoção é baixo, e o ecossistema não vai esperar.