Handoff seguro de agentes de IA entre dispositivos: estado, aprovação e recuperação
Entenda como criar um handoff seguro de agentes de IA entre dispositivos com estado verificável, execução identificada, aprovação vinculada e recuperação após desconexões.
- Controle remoto, migração de tarefa, continuação por notificação e troca de interface no mesmo aparelho são padrões diferentes e exigem contratos próprios.
- Uma passagem segura preserva identidade, intenção, entradas, etapa atual, resultados, responsável pela execução e validade do estado.
- Permissões e aprovações continuam ligadas à tarefa, à ação proposta e ao dispositivo que efetivamente executará a mudança.
- O GitHub Copilot CLI demonstra controle remoto de uma sessão mantida no ambiente de origem; a base atual da FoneClaw oferece continuidade entre Home e assistente flutuante no mesmo telefone Android.
Quatro formas diferentes de continuar uma tarefa
Um handoff seguro de agentes de IA entre dispositivos começa pela identificação do padrão usado. Controle remoto significa acompanhar e orientar uma sessão que continua rodando no aparelho de origem. Migração transfere a execução para outro ambiente. Continuação por notificação permite responder ou retomar uma etapa pendente. Já a troca de interface no mesmo dispositivo mantém a tarefa no mesmo telefone, mas muda o ponto de interação.
Essas diferenças aparecem em um exemplo simples. Um agente inicia uma análise no computador e o usuário acompanha o progresso pelo celular. Se o processo continua no computador, o telefone é um controle remoto. Se arquivos, ferramentas e estado passam a ser processados no celular, houve migração. Se o celular apenas recebe “aprovação necessária”, trata-se de uma continuação por notificação.
A quarta situação ocorre quando a pessoa começa uma tarefa na tela Home do Android e continua por um painel flutuante sobre outro aplicativo. Não há troca de aparelho nem transferência da execução. A mesma sessão apenas permanece acessível em outra parte da interface. Essa distinção evita prometer sincronização entre dispositivos quando o produto está preservando continuidade dentro de um único telefone.
Para o usuário, a interface precisa responder três perguntas: onde a tarefa está rodando, qual dispositivo está apenas mostrando ou orientando a sessão e onde uma ação produzirá efeito. O artigo Controle de agente de IA no celular: o telefone como central de comando aprofunda como reunir sessões, avisos e decisões sem confundir acompanhamento remoto com execução local.
O estado mínimo que precisa acompanhar a tarefa
Uma conversa sincronizada não basta para continuar uma tarefa. O histórico pode mostrar o que foi dito, mas não necessariamente informa qual ferramenta está ativa, que arquivo foi alterado, qual etapa terminou ou quem continua responsável pela execução. A passagem segura precisa de um conjunto mínimo de dados verificáveis.
| Elemento | O que precisa permanecer claro |
|---|---|
| Identidade | Usuário, agente, sessão e dispositivos participantes |
| Intenção | Resultado solicitado e restrições informadas |
| Entradas | Arquivos, mensagens, tela, links ou dados usados |
| Etapa atual | O que terminou, o que está rodando e o que está aguardando |
| Resultados | Saídas provisórias, mudanças concluídas e erros encontrados |
| Responsável | Ambiente que executa e dispositivo que apenas acompanha |
| Validade | Horário da última atualização e condições para renovar o estado |
Imagine uma sessão que prepara uma alteração em um arquivo no computador. Ao abrir o controle no telefone, o usuário precisa ver o repositório ou pasta, a etapa atual, o resumo das mudanças e o fato de que o processo continua no computador. Se o arquivo mudou desde a última atualização, a prévia antiga deixa de servir como base para aprovação.
Contexto pessoal também precisa ser selecionado por tarefa. Preferências, contas, contatos e histórico podem ajudar o agente, mas apenas os dados necessários devem seguir para a sessão que continuará. O guia Agente de IA com contexto pessoal no telefone explica como memória, identidade e dados do usuário podem apoiar uma tarefa sem transformar todo o histórico pessoal em contexto automático.
O contrato de estado também define a retomada. Ao reconectar, o sistema compara a última etapa conhecida com o estado atual do ambiente responsável. Se houver divergência, ele mostra a mudança e solicita uma nova decisão. A continuidade segura preserva o trabalho válido, mas não trata uma cópia antiga como verdade atual.
Como vincular permissões e aprovações
Permissões pertencem ao ambiente que realizará a ação. Um telefone usado para orientar uma sessão pode apresentar o pedido e registrar a resposta, mas a capacidade efetiva continua no computador, servidor ou aparelho de origem. Da mesma forma, uma permissão concedida no Android não cria acesso equivalente em outro dispositivo.
A aprovação precisa carregar a identificação da tarefa, a ação exata, o destino, o ambiente executor e um prazo de validade. “Permitir alteração” é pouco informativo. “Autorizar a sessão X no computador Escritório a editar o arquivo Y com estas mudanças” permite conferir o que será feito e onde o efeito aparecerá.
Esse vínculo impede que uma decisão antiga seja reutilizada depois que o contexto mudou. Se a tarefa troca de arquivo, ferramenta, destinatário ou aparelho responsável, a proposta precisa ser atualizada. O mesmo vale quando a sessão é retomada após muito tempo: a aprovação expirada não acompanha automaticamente o novo estado.
O usuário também precisa distinguir três comandos. Aprovar permite apenas a ação mostrada. Orientar muda o plano ou acrescenta informação. Parar solicita a interrupção da sessão responsável. Quando esses comandos ficam separados, uma mensagem enviada para corrigir o agente não é confundida com autorização para executar.
Em UX de aprovação de agentes de IA no celular: confiança, contexto e recuperação, detalhamos como mostrar motivo, alvo, consequência e evidência em uma tela compacta. No handoff entre dispositivos, esses elementos ganham mais um campo obrigatório: o local onde a ação será executada.
O que fazer quando a continuidade quebra
Uma passagem robusta assume que a conexão pode cair. O computador pode entrar em suspensão, o telefone pode perder rede, o aplicativo pode mudar de estado e a credencial temporária usada para conectar as interfaces pode expirar. Cada evento precisa produzir um estado explícito, não uma tentativa silenciosa de continuar com informações incompletas.
Se o ambiente de origem dorme, a tarefa passa para “origem indisponível” ou outro estado equivalente. O controle remoto ainda pode mostrar o último progresso confirmado, mas não apresenta a sessão como ativa. Quando a origem volta, ela publica um estado novo e informa se o processo permaneceu pausado, terminou ou encontrou uma falha.
Durante uma queda de rede, comandos enviados pelo telefone precisam ser identificados como pendentes até receberem confirmação. Isso evita que o usuário toque várias vezes em “parar” ou “aprovar” e crie solicitações duplicadas. Ao reconectar, a interface mostra quais comandos foram aceitos, quais expiraram e quais precisam ser enviados novamente.
Mudanças no aplicativo ou nos arquivos exigem nova validação. Se uma prévia foi criada antes de outra pessoa editar o documento, a aprovação deve ser suspensa até que o agente recalcule a proposta. Quando o token de conexão expira, o usuário autentica novamente e a sessão confirma sua identidade antes de liberar controles.
A recuperação termina com uma escolha compreensível: retomar no ambiente original, reiniciar a etapa com dados atualizados, transferir a tarefa por um mecanismo explicitamente compatível ou encerrar e apagar a conexão remota. A interface deve preservar registros suficientes para explicar a falha sem manter indefinidamente credenciais ou dados temporários.
O padrão atual do GitHub Copilot CLI
O controle remoto do GitHub Copilot CLI é um exemplo atual de sessão mantida na origem e orientada por outras interfaces. Conforme o anúncio de disponibilidade geral do controle remoto do Copilot CLI, uma sessão em execução pode ser acompanhada pelo GitHub Mobile, pelo site do GitHub e por interfaces compatíveis em IDEs, incluindo VS Code e JetBrains.
A sessão do CLI continua no ambiente em que foi iniciada. O celular não passa a executar localmente o terminal, os arquivos ou as ferramentas daquela sessão. As interfaces remotas transmitem o progresso, permitem orientar o agente, colocar novas instruções na fila, responder perguntas, aprovar ou negar solicitações de permissão e interromper o processo.
A documentação do GitHub sobre controle remoto do Copilot CLI torna visível a divisão de responsabilidades: o ambiente de origem conserva a execução, enquanto a interface conectada oferece acompanhamento e controle. Esse padrão reduz a quantidade de estado que precisa migrar e mantém arquivos e ferramentas ligados ao local onde já estavam disponíveis.
Em julho de 2026, o GitHub também adicionou notificações em tempo real para sessões remotas no GitHub Mobile em iOS e Android. Elas ajudam o usuário a perceber perguntas, pedidos de permissão e mudanças de estado sem manter o aplicativo aberto durante toda a execução.
A lição aplicável a outros agentes é arquitetural: diga onde a sessão permanece, quais comandos a interface remota aceita e como o usuário revoga o acesso. O desenho do Copilot CLI atende um agente de programação específico; outros assistentes precisam definir seus próprios dados, ferramentas e efeitos.
Continuidade no mesmo telefone com FoneClaw
A base atual da FoneClaw introduz continuidade entre a tela Home e um assistente flutuante no mesmo telefone Android. É um padrão de várias interfaces para uma única execução móvel: a tarefa permanece no ambiente da FoneClaw enquanto o usuário alterna o ponto de interação.
O assistente flutuante pode ser movido e aberto como painel compacto sobre o aplicativo atual. Um botão anexa a tela visível ao contexto, excluindo os elementos sobrepostos pela própria FoneClaw. Assim, o modelo recebe a parte relevante da tela sem incorporar o painel usado para comandar a tarefa.
A continuidade cobre execução, aprovações, parada e recuperação de permissões. Por exemplo, o usuário inicia na Home o pedido para interpretar uma tela, abre o aplicativo de destino e continua pelo painel flutuante. Se uma ferramenta Android suportada precisar de permissão ou aprovação, a decisão aparece na mesma tarefa. O usuário pode interromper e voltar à Home sem criar uma segunda sessão.
A base atual da FoneClaw estabelece estados independentes, aprovações vinculadas à sessão e isolamento entre tarefas. Esses fundamentos acompanham a mudança entre Home e painel flutuante. Um modelo configurado continua responsável por compreensão e planejamento; as ferramentas controladas da FoneClaw realizam as ações Android compatíveis.
Essa continuidade dentro de um telefone oferece um teste útil para os mesmos princípios exigidos em sistemas entre dispositivos: identidade estável, estado atual, aprovação ligada à tarefa e retomada após interrupção. A diferença operacional é que modelo, ferramentas e efeitos permanecem no mesmo aparelho. A versão atual da FoneClaw permite avaliar esse fluxo diretamente no Android.
Como testar uma passagem segura de tarefa
Um teste de handoff seguro precisa verificar comportamento, não apenas a aparência da sincronização. Escolha uma tarefa reversível, como analisar um arquivo de teste ou preparar uma alteração sem publicá-la. Depois execute sete etapas:
- Inicie: crie a sessão no ambiente de origem e registre tarefa, entradas e resultado esperado.
- Oriente: conecte outra interface, confirme onde a execução permanece e envie uma correção simples.
- Aprove: provoque uma ação controlada e verifique se alvo, consequência, ambiente executor e validade aparecem juntos.
- Pare: interrompa pela interface remota e confirme a parada no ambiente de origem.
- Reconecte: desligue a rede ou suspenda a origem, volte e compare o último estado confirmado com o estado atual.
- Revise: confira o registro de comandos, perguntas, aprovações, falhas e resultados.
- Exclua: encerre a conexão, revogue o acesso remoto e remova dados temporários conforme os controles oferecidos.
Durante o teste, altere um arquivo ou parâmetro antes de aprovar uma proposta antiga. O sistema precisa detectar que o contexto ficou desatualizado. Em seguida, deixe uma autorização expirar e confirme que ela não libera a nova etapa. Esses dois casos revelam se a continuidade preserva apenas aparência ou realmente verifica o estado.
Também confira como o produto encontra recursos e ferramentas. Descobrir um serviço disponível não concede autorização para usá-lo. O artigo Agentic Resource Discovery: catálogo confiável sem confundir descoberta com autorização aprofunda essa diferença quando agentes localizam novas capacidades durante uma tarefa.
O teste passa quando o usuário consegue apontar, em qualquer momento, onde o trabalho está rodando, qual comando está pendente, quem aprovou a próxima ação e como parar ou recuperar. Essa clareza é o fundamento de um handoff seguro de agentes de IA entre dispositivos.