Resolvendo o problema ARD com Agentic Resource Discovery

O ARD não é só mais um protocolo de descoberta: é a primeira camada de interoperabilidade projetada exclusivamente para agentes autônomos operarem em ambientes corporativos reais, onde ferramentas vivem em silos, APIs têm contratos distintos e segurança exige granularidade por recurso. Ele resolve o que os FDEs já enfrentavam na prática: a necessidade de mapear manualmente cada integração antes de um agente executar até mesmo uma consulta simples no Jira ou no Datadog. O modelo de dois níveis (Catalogs + Registries) replica, com propósito técnico claro, a arquitetura de descoberta usada em sistemas como Kubernetes (Service Catalog) e OpenAPI Registry, mas com foco em *intenção do agente*, não em consumo humano.

Isso explica por que a Snowflake foi a primeira a adotar oficialmente o ARD: sua plataforma já opera como um hub de dados federados. Agora, ao publicar seu catálogo ARD, ela permite que qualquer agente autorizado, seja da Microsoft Discovery, seja de um pipeline interno da Syensqo, descubra, valide e invoque recursos de transformação de dados sem hardcoding, sem credenciais embutidas e com políticas de acesso respeitadas nativamente.

Em 19 de junho, a Snowflake anunciou suporte ao ARD como implementação concreta, não como conceito ou especificação. Em 22 de junho, a notícia atual confirma que o protocolo está ativo, com guia de início rápido disponível e convite explícito para publicação de catálogos. Ou seja: saiu do estágio de whitepaper para o de infraestrutura operacional. A diferença entre o anúncio da Microsoft Discovery (abril) e agora é que, então, o foco era em orquestração interna de agentes; hoje, o ARD permite que agentes de diferentes plataformas, Discovery, Vertex AI, Einstein Copilot, descubram e consumam recursos uns dos outros dentro do mesmo domínio corporativo.

Agentes que não conseguem descobrir ferramentas por conta própria viram caixas pretas gerenciadas por humanos, o oposto da promessa de autonomia. O ARD reduz o custo operacional de manter agentes em produção: sem ele, cada nova integração exige revisão de código, teste de segurança, atualização de documentação e treinamento de prompts. Com ele, basta registrar o recurso no catálogo com metadados estruturados (ex: 'suporta POST /v1/tickets', 'requer role: support_agent', 'aceita input_schema: JiraTicketCreate'). O agente lê, valida e usa, tudo em tempo de execução.