UX de aprovação de agentes de IA no celular: confiança, contexto e recuperação

Encontre o momento exato da decisão

A UX de aprovação de agentes de IA começa por uma pergunta concreta: em qual etapa a assistência passa a produzir uma mudança real? Ler uma mensagem, organizar informações e preparar um rascunho podem acontecer sem alterar a conta do usuário. Enviar o texto, trocar uma configuração, excluir um arquivo ou compartilhar uma localização já cria um efeito que precisa ser entendido antes de continuar.

O pedido falado “avise a Paula que chegarei às 18h” mostra bem essa transição. O agente pode identificar o contato e preparar a mensagem. O momento de decisão aparece quando destinatário, aplicativo e conteúdo estão definidos e o envio está prestes a acontecer. A tela de aprovação deve surgir ali, com esses elementos visíveis, e não no início genérico da conversa nem depois que a mensagem já saiu.

Também importa distinguir uma ação reversível de uma consequência difícil de corrigir. Abrir um aplicativo ou mostrar uma rota pode seguir imediatamente quando o alvo está claro. Alterar dados de uma conta, publicar conteúdo, apagar um item ou enviar uma comunicação pede uma pausa proporcional ao impacto. Essa pausa deve preservar o contexto, para que o usuário saiba exatamente o que está autorizando.

Na FoneClaw, tratamos a aprovação como parte do andamento da tarefa. Quando uma etapa aguarda decisão, ela permanece identificável e separada de outras atividades. O usuário pode aprovar, recusar ou pedir uma alteração sem perder o que já foi preparado. Esse desenho torna o controle humano uma ação útil dentro do fluxo, em vez de uma janela genérica que interrompe sem explicar.

Separe sugestão, prévia e aplicação

Sugerir, mostrar uma prévia e aplicar são três estados diferentes. Uma sugestão apresenta uma mudança possível sem assumir que ela será realizada. A prévia organiza os detalhes finais e permite inspeção. A aplicação efetiva altera o destino escolhido. Se a interface usa o mesmo botão ou a mesma linguagem para os três casos, o usuário precisa adivinhar se está aceitando uma ideia ou executando uma ação.

O anúncio do GitHub sobre controles de automação em Issues, publicado em 23 de julho de 2026 como prévia pública, oferece uma referência útil. Em ações compatíveis do GitHub Issues, a automação pode sugerir mudanças para revisão, aplicar automaticamente casos de alta confiança e manter casos de confiança média ou baixa aguardando decisão. O próprio GitHub esclarece que essa aprovação facilita o fluxo de trabalho, mas não substitui os controles de segurança do servidor.

No celular, os rótulos precisam indicar o resultado: “Preparar mensagem”, “Revisar envio” e “Enviar agora” são mais claros do que uma sequência de botões iguais com o texto “Continuar”. Depois da ação, a interface deve mudar para “Enviado”, “Alteração concluída” ou outro resultado verificável. Se algo falhar, o estado volta a ser editável, preservando os dados que ainda são válidos.

Use confiança para direcionar a revisão

O nível de confiança ajuda a decidir onde concentrar atenção, mas não é uma promessa de acerto. Ele pode refletir a clareza do alvo, a qualidade dos dados, a correspondência entre o pedido e a ferramenta ou a ausência de ambiguidades. Ainda assim, uma ação de alta confiança pode ter grande impacto, enquanto uma proposta incerta pode ser inofensiva e fácil de desfazer.

Por isso, a rota de revisão deve combinar confiança e consequência. Abrir o aplicativo de calendário identificado pelo usuário pode seguir sem uma pausa extensa. Criar um compromisso com convidados requer uma prévia, mesmo quando data e participantes foram extraídos com segurança. Excluir um arquivo importante ou alterar uma configuração sensível merece confirmação explícita independentemente da confiança calculada.

Uma matriz simples funciona melhor do que um número isolado. Alta confiança e baixo impacto podem permitir aplicação direta com resultado visível. Alta confiança e alto impacto levam à confirmação. Confiança média pede destaque para o campo incerto. Baixa confiança interrompe a ação e solicita a informação que falta. Em todos os casos, o usuário precisa entender por que a tarefa avançou ou parou.

A interface também deve evitar transformar uma estimativa técnica em linguagem absoluta. Em vez de “correto com 97% de certeza”, é mais útil dizer “Contato identificado pelo número salvo” ou “Existem dois calendários possíveis”. Essa formulação mostra o ponto que sustenta a decisão e permite uma correção objetiva. A revisão fica mais rápida porque a pessoa sabe onde olhar.

Mostre motivo, alvo, consequência e evidência

Uma solicitação de aprovação precisa responder a quatro perguntas sem exigir a leitura de um relatório: por que esta ação foi proposta, onde ela acontecerá, o que mudará e quais dados sustentam a escolha. Esses elementos cabem em um painel compacto quando a informação principal vem primeiro e os detalhes ficam disponíveis sob demanda.

Considere um agente que propõe mudar o Wi-Fi. Um aviso vago como “Permitir alteração?” não informa o suficiente. A apresentação útil seria: “Conectar à rede Escritório”, seguida pelo motivo “Você pediu para usar a rede salva deste local” e pela consequência “A conexão móvel poderá deixar de ser usada enquanto o Wi-Fi estiver ativo”. O nome da rede, o estado atual e o botão de confirmação ficam visíveis juntos.

Para mensagens, a evidência pode ser o contato selecionado e a conversa de origem. Em calendário, pode ser o trecho do e-mail que contém data e horário. Em arquivos, deve incluir nome, pasta e tipo de operação. Quando a fonte está incompleta, a interface destaca a lacuna em vez de preencher silenciosamente um dado decisivo.

Esse registro também ajuda depois da conclusão. O usuário consegue verificar o que foi solicitado, qual ferramenta atuou e qual resultado voltou. O guia Identidade de agentes de IA: permissões, aprovação por ferramenta e auditoria no Android aprofunda como identidade, autorização e histórico se combinam quando várias ferramentas participam de uma tarefa. Na tela de aprovação, porém, a prioridade continua sendo uma decisão rápida e informada.

Vincule cada aprovação à tarefa correta

Celulares acumulam conversas, notificações e solicitações ao mesmo tempo. Se uma aprovação aparece sem indicar de qual tarefa veio, o usuário pode confirmar a ação certa no contexto errado. A interface precisa manter juntos o pedido original, a proposta atual, a sessão que a gerou e o estado de espera.

A base atual da FoneClaw trouxe estados independentes para tarefas em andamento e aguardando, aprovações vinculadas à sessão e maior isolamento entre atividades. Na prática, uma mensagem esperando confirmação não herda a decisão tomada em outra conversa, e uma tarefa em execução pode continuar identificada enquanto outra aguarda uma resposta do usuário.

Imagine duas solicitações simultâneas: preparar um e-mail de trabalho e ajustar um lembrete pessoal. Cada painel precisa mostrar seu próprio título, destino, conteúdo e decisão pendente. Aprovar o lembrete não deve liberar o envio do e-mail. Se o usuário volta horas depois, a tarefa aguardando precisa reaparecer com contexto suficiente para ser revisada sem depender da memória da conversa anterior.

Uma fila bem desenhada mostra “Em andamento”, “Aguardando você”, “Concluída” e “Precisa de correção” como estados acionáveis. O artigo Controle de agente de IA no celular: o telefone como central de comando detalha como reunir essas tarefas sem transformar cada notificação em uma interrupção. O ponto central é preservar a relação entre decisão e trabalho correspondente até o resultado final.

Aplique o padrão às ações do celular

O mesmo princípio de aprovação assume formas diferentes conforme a ação. Em mensagens, a tela mostra destinatário, aplicativo, texto e anexos antes do envio. Em configurações, compara o valor atual com o proposto. Em arquivos, identifica item, pasta e operação. Na navegação, apresenta destino e rota, mas iniciar a orientação pode ser uma etapa de baixo impacto quando o local está inequívoco.

Para uma mensagem, um fluxo útil seria: preparar o texto, destacar o contato escolhido, permitir edição e só então oferecer “Enviar”. Se o nome corresponder a mais de uma pessoa, a tarefa passa para “Aguardando contato”. Depois do envio, o resultado informa o canal usado e o horário. Caso o aplicativo não esteja disponível, o texto permanece pronto para ser retomado em outra opção.

Em ajustes do telefone, a aprovação deve ficar próxima da mudança. “Ativar Bluetooth” pode mostrar o estado atual e a alteração proposta. Uma ação que afete conectividade, privacidade ou consumo de energia pode incluir uma explicação curta sobre o efeito esperado. O usuário confirma o novo estado, e o agente verifica se o Android realmente aplicou a mudança.

Arquivos e dados pessoais exigem atenção ao alcance da permissão. Uma autorização de acesso não equivale a aprovação para qualquer operação futura. O conteúdo em Sandbox de agentes de IA e permissões do telefone: por que limites ainda importam explica como ambiente restrito, permissões do Android e decisão por ação cumprem funções diferentes. Na FoneClaw, conectamos pedidos a ações Android suportadas e mantemos as etapas relevantes disponíveis para revisão.

Permita recusar, corrigir e recuperar

A aprovação não pode ser uma escolha entre aceitar tudo e abandonar a tarefa. Uma experiência completa oferece “Recusar”, “Editar”, “Trocar alvo”, “Tentar novamente” e, quando possível, “Desfazer”. Cada opção precisa produzir um estado claro. Recusar encerra aquela proposta; editar devolve os campos ao usuário; trocar o alvo preserva o conteúdo; tentar novamente usa apenas os dados confirmados.

Se uma permissão estiver ausente, o agente deve explicar qual recurso é necessário e para qual etapa. Depois que o usuário concede o acesso nas configurações do Android, a tarefa pode retomar no ponto apropriado. A base atual da FoneClaw melhora essa recuperação de permissões, reduzindo a necessidade de reconstruir o pedido inteiro após uma interrupção previsível.

Falhas de execução também precisam de uma saída prática. Se o aplicativo mudou de tela, a conexão caiu ou a ação não retornou um resultado confiável, o estado passa para “Precisa de atenção”. A interface mostra a última etapa confirmada e oferece retomada ou controle por toque. As melhorias atuais de recuperação da tela Home e da execução ajudam a restabelecer um ponto compreensível para continuar.

Desfazer merece tratamento próprio. Algumas mudanças possuem reversão direta; outras exigem uma nova ação, e certas consequências não podem ser recolhidas depois de concluídas. A interface deve dizer qual caso se aplica antes da confirmação. Para testar a base atual da FoneClaw, comece com uma ação reversível: prepare uma nota, altere um campo, recuse a primeira proposta, corrija o conteúdo e observe se a tarefa mantém contexto, decisão e resultado visíveis até o fim.