Agentic Resource Discovery: catálogo confiável sem confundir descoberta com autorização

O que Agentic Resource Discovery resolve

Agentic Resource Discovery, ou ARD, responde a uma pergunta cada vez mais comum: como um agente de IA encontra ferramentas, skills e outros agentes sem depender de uma lista privada, desatualizada ou mantida dentro de uma única plataforma? A apresentação pública do Agentic Resource Discovery pelo Google Developers Blog, em 17 de junho de 2026, descreve ARD como uma especificação aberta para publicar, descobrir e verificar recursos de agentes na web.

O centro da ideia é simples. Uma organização publica um catálogo sob seu próprio domínio, muitas vezes referido pelo arquivo ai-catalog.json, e esse catálogo descreve capacidades que agentes podem encontrar. Em vez de um agente adivinhar endpoints, ler documentação humana ou depender de integrações manuais, ele consulta metadados estruturados: quem publica, que tipo de recurso existe, qual interface nativa deve ser usada e como verificar a origem antes de tentar conexão.

Para usuários de phone agents, a parte importante é a fronteira. ARD melhora a descoberta de recursos para agentes de IA; ele não transforma descoberta em execução. Saber que uma ferramenta existe não significa que ela está habilitada no telefone, que o usuário consentiu, que o Android concedeu permissão ou que uma ação sensível foi aprovada. Essa separação acompanha todo o artigo.

Como catálogos e registros publicam capacidades

O fluxo começa no publicador. Uma empresa, projeto ou serviço mantém um catálogo em seu domínio e descreve ali seus recursos agentic: ferramentas, skills, agentes, catálogos aninhados e interfaces que aceitam conexão. O arquivo ai-catalog.json funciona como um ponto previsível de leitura para clientes e registros, mas o valor real está no conjunto de metadados: nome, descrição, tipo de capacidade, protocolo anunciado, localização, versão, escopos e sinais de confiança.

Há duas rotas práticas de descoberta. Na primeira, um cliente já sabe qual parceiro quer consultar e busca o catálogo diretamente no domínio desse parceiro. Na segunda, um registro rastreia catálogos públicos, indexa capacidades e permite busca por intenção em linguagem natural ou por filtros. A especificação e o trabalho público no repositório do ARD mostram essa arquitetura como uma camada aberta e em evolução, não como um único diretório central obrigatório.

Um registro não é corretor de execução. Ele ajuda a encontrar capacidades compatíveis com uma intenção, pode devolver metadados de verificação e reduz descoberta manual. A decisão de conectar, habilitar e usar uma capacidade continua com o cliente, o runtime do agente e o usuário.

O que a verificação do publicador prova

Verificação resolve um problema real: antes de um agente se conectar a uma ferramenta, ele precisa saber se o catálogo veio do publicador certo e se os metadados não foram trocados no caminho. Segundo o anúncio de ARD, a descoberta em produção pode incluir metadados de publicador verificáveis criptograficamente antes de uma conexão direta pelo protocolo nativo. Esse detalhe muda a confiança de uma lista solta para uma origem verificável.

Mesmo assim, identidade correta não é autorização. Um publicador legítimo pode oferecer uma ferramenta poderosa demais para um usuário específico, uma versão antiga pode ter comportamento diferente, um endpoint pode exigir escopos amplos, e uma capacidade bem descrita pode ser inadequada para um contexto móvel. Verificação responde quem publicou e se o catálogo parece íntegro; ela não responde se a ação deve acontecer agora, neste aparelho, nesta conta e para este alvo.

Essa distinção evita dois erros. O primeiro é tratar domínio controlado como selo de segurança total. O segundo é rejeitar descoberta aberta por medo de que todo recurso descoberto seja executado automaticamente. Entre esses extremos existe um desenho mais prático: verificar antes de conectar, testar antes de habilitar e pedir aprovação antes de ações com efeito externo, leitura sensível ou controle do dispositivo.

Como ARD entrega a conexão para MCP, A2A, OpenAPI e contratos de apps

ARD não tenta virar o protocolo universal de chamada. O catálogo anuncia onde está a capacidade e qual interface deve ser usada; depois disso, a conexão acontece no protocolo nativo. Uma entrada pode apontar para um servidor MCP, um agente A2A, uma ferramenta OpenAPI ou outro contrato documentado. O papel do ARD é resolver metadados e confiança inicial, não substituir o canal de execução.

Isso importa muito em ambientes móveis. Um catálogo pode dizer que existe uma capacidade para consultar dados, preparar uma ação ou interagir com um serviço. Ainda assim, um app no telefone precisa expor um contrato chamável, um intent, uma API local, um conector ou uma experiência de revisão. Para entender a parte específica de apps que oferecem ações chamáveis por máquina, a leitura complementar é App Intents e apps chamáveis por máquina: o que muda para agentes de IA.

A saída correta de ARD é uma conexão mais informada. O agente não deve inventar um endpoint; ele escolhe entre recursos publicados, verifica origem, valida o protocolo anunciado e só então passa para a camada que realmente conversa com a capacidade. Em um phone agent, essa passagem ainda precisa respeitar o que o Android, o app de destino e a política do runtime permitem.

Por que descoberta não é autorização no telefone

No telefone, a diferença entre encontrar uma capacidade e ter autoridade para usá-la fica concreta. Um catálogo de ferramentas ai-catalog.json pode informar que existe uma ferramenta para enviar mensagem, ler localização, criar evento ou executar uma integração. Isso não concede permissão Android, não escolhe o destinatário certo, não aprova uma consequência de conta e não registra consentimento do usuário.

A orientação oficial de Android sobre permissões recomenda pedir permissões em contexto quando uma funcionalidade precisa delas, e também deixa o tratamento de negação sob responsabilidade do app. A documentação de permissões em tempo de execução do Android é útil justamente por separar o que o sistema concede de outras decisões: uma permissão de localização, por exemplo, permite acesso técnico sob regras do Android; ela não autoriza automaticamente compartilhar essa localização com qualquer serviço descoberto.

Quando a discussão entra em skills, permissões e ações sensíveis, vale aprofundar em Segurança de habilidades de agentes de IA no celular. Para a camada de identidade, autoridade e registro de atividade, o contexto mais amplo está em Identidade, permissões e trilhas de auditoria para agentes de IA no telefone. Aqui, a regra operacional é direta: descoberta aponta possibilidades; autorização decide o que pode acontecer.

Checklist antes de conectar e antes de executar

Um bom fluxo de phone agent não começa pela execução. Ele começa por perguntas pequenas, observáveis e reversíveis. A sequência abaixo ajuda equipes de produto, desenvolvedores e usuários avançados a testar recursos descobertos sem transformar um catálogo em passe livre para ações no Android.

1. Confirme o publicador. Verifique domínio, metadados e sinais de integridade antes de aceitar o recurso como candidato.
2. Cheque frescor e versão. Um catálogo antigo, um endpoint movido ou uma skill sem versão clara muda o risco de integração.
3. Valide a interface nativa. MCP, A2A, OpenAPI ou contrato de app precisam responder de forma previsível ao cliente usado.
4. Revise escopos e entradas. O recurso deve pedir apenas o que precisa para a tarefa, com campos e alvos claros.
5. Habilite localmente. O runtime do telefone deve permitir aquela ferramenta ou plugin antes de qualquer chamada.
6. Comece por baixo risco. Teste leitura visível, consulta simples ou simulação antes de uma ação com efeito externo.
7. Valide alvo e consequência. Destinatário, conta, app, valor, localização e conteúdo precisam aparecer antes da aprovação quando importam.
8. Mostre o resultado. O usuário deve conseguir ver o que foi preparado, enviado, aberto ou alterado.
9. Registre e permita revogação. Histórico, parada, desabilitação e troca de endpoint são parte do controle, não detalhe administrativo.

O ponto mais prático está nos testes de falha. O recurso deve se comportar bem quando o usuário nega permissão, quando a rede cai, quando o endpoint muda ou quando o app de destino não aceita a ação. Um agente que só parece confiável no caminho feliz ainda não está pronto para tarefas móveis reais.

Como a FoneClaw separa visibilidade de catálogo e autoridade no telefone

Na FoneClaw, usamos a ideia de catálogo como uma forma de tornar ferramentas visíveis, pesquisáveis e governadas dentro do runtime Android. Isso não é uma declaração de implementação de ARD. É a mesma distinção aplicada de forma prática: ver uma ferramenta, plugin ou capacidade no catálogo ajuda o modelo configurado a planejar; executar uma ação no telefone passa por suporte local, política de ferramenta, permissões e resultado visível.

Dados públicos de 1 de agosto de 2026 mostram a FoneClaw 0.1.0 com melhorias em gerenciamento por ferramenta, contratos mais seguros, recuperação de permissões e continuação de plugins confiáveis. As notas em dados públicos de versão da FoneClaw diferenciam ferramentas integradas de fluxos de plugin assinados, e o catálogo público de ferramentas da FoneClaw mostra uma base datada com mais de 100 ferramentas integradas organizadas por risco e política de aprovação.

O modelo configurado dentro da FoneClaw fornece entendimento, raciocínio e planejamento. A FoneClaw invoca ferramentas Android suportadas, guia permissões sob demanda, respeita controles de habilitação e mostra resultados para que o usuário acompanhe a tarefa. Quando uma proposta envolve plugin, ela deve aparecer como proposta visível e seguir o caminho controlado de instalação e continuação; descoberta silenciosa e instalação invisível não fazem parte do escopo que defendemos.

Para quem quer a explicação completa da passagem de intenção para ação no Android, sem repetir toda a arquitetura aqui, o guia Controle do celular por agente de IA: como funciona no Android mostra como permissões, aprovação e ações suportadas se conectam no uso diário.

O que testar antes de adotar um registro de recursos para agentes

Antes de adotar um registro de recursos agentic, equipes devem medir a qualidade da descoberta e a qualidade da recusa. Uma busca por intenção que retorna dez ferramentas irrelevantes gera ruído. Um catálogo correto, mas antigo, aumenta risco operacional. Uma verificação que falha sem explicar por quê impede suporte. Uma política que nega uma ação sem mostrar caminho alternativo deixa o usuário preso.

A decisão madura não é escolher entre descoberta aberta e controle rígido. É manter os dois observáveis. ARD pode tornar recursos mais fáceis de encontrar e verificar; o runtime do telefone decide o que fica habilitado, quando pedir permissão, quando exigir aprovação, quando registrar atividade e quando revogar. Para agentes Android, essa separação é o que transforma um catálogo útil em uma experiência confiável.