Roteamento de capacidades de agentes de IA no Android: AutoAttach, Suggest e Fallback

Do pedido Android aos candidatos de capacidade

Imagine um pedido simples: “mande para a Paula a foto desta tela e diga que eu reviso mais tarde”. Um agente Android não deve carregar todas as ferramentas, Skills, Workflows e Plugins em cada resposta. Ele precisa transformar o pedido em candidatos de capacidade: ler a tela atual, capturar ou anexar contexto, localizar contato, preparar mensagem, selecionar app de envio, pedir aprovação e recuperar o fluxo se uma permissão faltar.

Roteamento de capacidades de agentes de IA é esse processo de selecionar o caminho provável antes da execução. Ele não é um glossário de ferramentas. Também não é autorização. A correspondência semântica pode dizer que “mensagem” se aproxima de envio por SMS ou app de comunicação, mas ainda faltam alvo, permissão, confirmação e resultado visível. Quando construímos a FoneClaw, aprendemos que a qualidade do roteamento aparece justamente nesses limites pequenos: o agente escolhe candidatos úteis sem agir antes da hora.

O ranking começa com sinais de contexto. Qual app está aberto? O usuário anexou a tela atual? Existe um contato claro? A tarefa envolve arquivo, calendário, sistema, mensagem, navegação ou informação? Há capacidade instalada, habilitada e adequada ao dispositivo? A partir disso, o agente monta um conjunto de candidatos e escolhe entre anexar contexto automaticamente, sugerir uma rota ao usuário ou cair para um caminho de fallback.

Para definições amplas de ferramentas, Plugins, Skills, Workflows e Shortcuts, mantemos a camada conceitual em Ferramentas, Plugins, Skills, Workflows e Shortcuts na FoneClaw: guia de camadas. Esta página fica no mecanismo: como um pedido vira decisão de capacidade.

Quando usar AutoAttach, Suggest ou Fallback

AutoAttach é a rota de alta confiança para adicionar contexto ou metadados que ajudam o agente a decidir. No exemplo da Paula, se o usuário está usando o assistente flutuante e toca para anexar a tela atual, a FoneClaw pode usar esse contexto no planejamento. AutoAttach não executa ferramenta sensível. Ele prepara o entendimento: “a tela atual é relevante para este pedido” ou “esta capacidade local combina com a intenção”.

Suggest entra quando há mais de uma opção plausível ou quando a ação muda o resultado de forma perceptível. Se “Paula” pode ser mais de um contato, se há mais de um app de mensagem, ou se o agente detecta uma Skill possível mas ainda não deve assumi-la, a experiência deve apresentar uma escolha. Suggest deixa o usuário decidir sem transformar incerteza em execução.

Fallback mantém o fluxo vivo quando o roteador não encontra uma rota segura. Se a capacidade de envio não está disponível, se a permissão foi negada, se o Plugin necessário não está ativado, ou se o alvo continua ambíguo, o agente pode preparar o texto para revisão, abrir a tela certa, pedir dados mínimos ou explicar o bloqueio. Fallback não ignora política e não substitui aprovação; ele oferece uma continuação útil dentro do que é suportado.

A diferença entre AutoAttach e Suggest é o grau de decisão do usuário naquele ponto. AutoAttach melhora o contexto da tarefa quando o risco é baixo e a ligação é clara. Suggest aparece quando a escolha muda o caminho da ação. Fallback aparece quando o sistema precisa parar de fingir certeza e preservar utilidade.

Separe descoberta, anexação, ativação, aprovação e execução

O erro mais caro em roteamento de ferramentas Android é tratar “encontrado” como “pronto para executar”. Um agente pode descobrir uma capacidade em um catálogo, identificar metadados de um Plugin, reconhecer uma Skill aplicável ou encontrar uma ferramenta integrada. Isso ainda não significa que a capacidade esteja instalada, ativada, autorizada, aprovada ou adequada ao estado do telefone.

A máquina de estados precisa ser explícita. Descoberta identifica candidatos. Anexação adiciona contexto ou metadados ao planejamento. Instalação, quando existe, é uma decisão separada e visível. Ativação torna uma capacidade disponível dentro de um escopo governado. Aprovação decide se uma ação concreta pode seguir. Execução realiza a ação suportada. Verificação confirma o resultado. Recuperação orienta o usuário quando qualquer estado falha.

O movimento do ecossistema confirma essa separação. O Google Developers descreve Agent Plugins como uma especificação para empacotar Skills, ferramentas e servidores MCP, com metadados compartilhados. Empacotar não significa confiar automaticamente. Da mesma forma, o Agent finder do GitHub Copilot ranqueia recursos relevantes sob demanda, mas descoberta não é instalação silenciosa nem autorização universal. Usamos esses sinais como evidência de um padrão de produto: encontrar uma capacidade e permitir que ela aja são decisões diferentes.

Para o pedido da Paula, essa máquina evita saltos perigosos. O agente pode descobrir que existe um caminho de mensagem, anexar a tela atual, sugerir o contato correto, pedir aprovação do conteúdo e só então usar uma ferramenta de envio suportada. Se qualquer estado estiver incompleto, o fluxo deve pausar ou cair para fallback.

Manifests, dependências, metadados e confiança

Um roteador de capacidades precisa de entradas confiáveis. O manifest informa identidade, escopo e capacidades declaradas. Dependências dizem o que precisa existir antes da ativação. Metadados de contexto ajudam a decidir se a capacidade combina com o pedido atual. Confiança mede se a correspondência é clara o bastante para AutoAttach, se precisa de Suggest ou se deve cair para Fallback.

Metadados sozinhos não tornam uma extensão confiável. Um Plugin pode declarar uma capacidade útil e ainda assim exigir revisão de ativação. Uma Skill pode parecer aplicável e ainda precisar de prévia e confirmação antes de ser salva como rascunho desativado. Uma dependência pode estar ausente, antiga ou incompatível com o aparelho. Um roteador maduro trata esses casos como estados do ciclo de vida, não como exceções invisíveis.

Snapshots atômicos de capacidade ajudam a evitar estados parciais. Se uma atualização de capacidades falha no meio, o agente não deve misturar metade do catálogo novo com metade do antigo. O usuário precisa de um conjunto coerente: ou a última versão aceita continua válida, ou a nova ativação é revisada antes de entrar no fluxo. Isso reduz falsos positivos, principalmente em roteamento de plugins e skills.

A confiança também deve ser calibrada contra casos negativos. Se o pedido é “organize isso”, o contexto pode apontar para nota, calendário, tarefa, arquivo ou mensagem. A escolha correta talvez seja Suggest. Se o pedido é “resuma esta tela” e o usuário acabou de anexar a tela atual, AutoAttach faz sentido. Se o pedido exige uma capacidade ausente, Fallback preserva a experiência sem inventar execução.

Recuperação quando a capacidade falta, expira ou fica ambígua

Recuperação não é apenas tentar de novo com o modelo. Quando uma capacidade está ausente, o agente precisa dizer o que faltou e oferecer um caminho viável: usar uma ferramenta integrada, sugerir uma Skill, orientar ativação de Plugin revisado ou preparar uma resposta manual. Quando a dependência está expirada, o fluxo precisa atualizar ou pausar antes de executar. Quando a permissão Android foi negada, a recuperação deve levar o usuário à autorização correta ou propor uma tarefa alternativa.

Ambiguidade merece tratamento próprio. Se há dois contatos chamados Paula, duas contas de e-mail ou dois apps que podem cumprir a tarefa, o roteador não deve escolher pelo primeiro resultado. A rota correta é Suggest: mostrar opções relevantes, pedir decisão e continuar com o alvo escolhido. Isso reduz erro silencioso, que é pior que uma pausa breve.

Falhas também podem vir de estado do dispositivo. O app de destino pode estar deslogado, uma tela pode ter mudado, o telefone pode estar sem rede ou uma configuração do sistema pode bloquear a ação. Nesses casos, recuperação de permissão e continuidade de tarefa são coisas diferentes de reprocessar a frase. A FoneClaw precisa manter a tarefa viva, explicar o bloqueio e retomar quando o usuário resolver o estado necessário.

Esse desenho se conecta diretamente à confiança. A aprovação não deve aparecer só no final; ela precisa ser parte da jornada quando a confiança cai. Para aprofundar esse ponto, o guia UX de aprovação de agentes de IA no celular: confiança, contexto e recuperação mostra como confirmação visível melhora o uso de agentes no telefone.

Como aplicamos roteamento governado na FoneClaw

Na FoneClaw, construímos o roteamento de capacidades para separar seleção, ativação, aprovação e execução. O usuário faz um pedido em linguagem natural. O agente considera contexto disponível, capacidades integradas, Skills, Workflows e Plugins revisados. A FoneClaw fornece 100+ ferramentas integradas para ações Android suportadas, mas o roteador não assume que toda intenção deve virar execução imediata.

AutoAttach nos ajuda quando a relação entre contexto e tarefa é clara. No assistente flutuante, por exemplo, o usuário pode anexar a tela atual para que o agente entenda de onde vem o pedido. Isso melhora o plano, mas não envia mensagens, altera configurações ou aciona ferramentas sensíveis sozinho. Suggest aparece quando precisamos mostrar uma opção: contato, app, Skill, Workflow, Plugin ou caminho de ação. Fallback aparece quando a rota não é confiável o bastante ou não está disponível.

Plugins passam por revisão de ativação. Skills aprendidas passam por prévia e confirmação antes de serem salvas como rascunho desativado. Esse detalhe importa: uma sugestão de capacidade não equivale a instalação silenciosa, e um rascunho salvo não equivale a execução autorizada. O ciclo de vida visível protege o usuário e dá ao agente um catálogo mais estável para decisões futuras.

No pedido da Paula, o fluxo governado fica assim: a tela atual pode ser anexada, o roteador classifica candidatos, o agente sugere o contato se houver ambiguidade, prepara o texto, mostra o conteúdo, pede aprovação antes de qualquer envio e verifica o resultado. Se falta permissão ou capacidade, a FoneClaw recupera: orienta o ajuste, oferece alternativa ou prepara o conteúdo para ação manual. Para riscos específicos de Skills e permissões, recomendamos continuar em Segurança de habilidades de agentes de IA no celular.

Esse é o comportamento que queremos tornar previsível: capacidade certa no momento certo, sem misturar descoberta com autorização e sem tratar fallback como atalho para contornar controles.

Sete testes para um roteador de capacidades

Um roteador de capacidades deve ser testado por estados, não só por acerto semântico. A pergunta não é apenas “ele encontrou algo parecido?”. A pergunta é se ele encontrou a capacidade certa, no estado certo, com confiança adequada, e se preservou aprovação e recuperação.

1. Candidato correto: o roteador lista capacidades relevantes para o pedido e remove opções irrelevantes?
2. Falso positivo: ele evita anexar ou sugerir uma capacidade só porque palavras parecidas aparecem?
3. No-match: quando não existe rota segura, ele cai para Fallback sem inventar execução?
4. Dependência: ele detecta Plugin, Skill, permissão ou app ausente antes da ação?
5. Ativação: descoberta, instalação e ativação permanecem visíveis e separadas?
6. Aprovação: ações com consequência voltam ao usuário antes da execução?
7. Recuperação: falhas de permissão, estado, alvo ou ferramenta geram próximo passo claro?

O melhor teste combina um caso com correspondência clara e um caso sem correspondência. Peça uma tarefa simples que a FoneClaw suporta, depois peça uma variação ambígua ou indisponível. Um bom roteador deve ser útil nos dois cenários: agir com confiança quando há base e parar com elegância quando falta uma peça. Para a camada de descoberta confiável em catálogos, veja Agentic Resource Discovery: catálogo confiável sem confundir descoberta com autorização.