# ARD — Agentic Resource Discovery: A Camada que Faltava no Ecossistema de Agentes
> Entenda o ARD, a especificação que permite agentes descobrirem tools, skills e outros agentes automaticamente via catálogos e registries.
Source: https://agentify.ia.br/blog/ard-agentic-resource-discovery/
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](https://github.com/ards-project/ard-spec) (398 stars, 46 forks, 91 commits em julho de 2026), com documentação em [agenticresourcediscovery.org](https://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** — `` 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":
}
```
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": ,
"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": ,
"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:::
```
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.
-->