Handoff seguro de agentes IA entre dispositivos: estado, permisos y recuperación
Guía para transferir o dirigir tareas de agentes IA entre dispositivos con estado verificable, permisos vinculados, recuperación y control del entorno que ejecuta.
- Dirigir una sesión a distancia, migrar una tarea, continuar desde una notificación y cambiar de interfaz en el mismo teléfono son patrones distintos.
- Un handoff seguro conserva identidad, intención, entradas, paso actual, resultados, entorno de ejecución y vigencia del contexto.
- Las aprobaciones deben seguir vinculadas a una tarea y acción concretas; los permisos efectivos permanecen en el dispositivo o servicio que ejecutará el paso.
- GitHub Copilot CLI ofrece un ejemplo actual de control remoto entre dispositivos, mientras la base actual de FoneClaw aplica continuidad entre Home y el asistente flotante dentro de un solo teléfono Android.
Cuatro formas distintas de continuar una tarea
Un handoff seguro de agentes IA entre dispositivos comienza por nombrar correctamente el patrón. Ver una conversación en dos pantallas no demuestra que la tarea se haya transferido. Para saber qué controla el usuario, hay que distinguir dirección remota, migración, continuación mediante notificaciones y cambio de interfaz dentro del mismo dispositivo.
En la dirección remota, la sesión sigue ejecutándose en el entorno original. El teléfono o el navegador muestran su progreso, permiten responder preguntas y envían instrucciones, pero no asumen el proceso. Este es el modelo de GitHub Copilot CLI: el terminal de origen conserva la sesión y otras interfaces ayudan a supervisarla.
La migración es más exigente. El trabajo, o una parte ejecutable de él, pasa a otro dispositivo. El receptor necesita las entradas, el paso actual, los resultados parciales y la autoridad necesaria para continuar. Si una tarea abandona un ordenador y pasa realmente al teléfono, debe quedar claro qué proceso se cerró, cuál comenzó y quién conserva los archivos o credenciales.
Una notificación ofrece un tercer patrón. El móvil avisa de que una tarea requiere atención y abre el contexto adecuado, pero el proceso puede permanecer en otro lugar. Por último, la continuidad dentro de un mismo dispositivo permite cambiar entre una pantalla completa, Home, una ventana flotante o una notificación sin trasladar la ejecución a otro aparato.
La interfaz debe mostrar siempre dónde se ejecuta el trabajo, desde dónde se está dirigiendo y qué acción espera respuesta. La guía Control de agentes de IA móvil: el teléfono como centro de mando desarrolla cómo reunir sesiones activas, tareas pendientes y controles de detención en una vista comprensible.
El contrato mínimo de estado de la tarea
Una transferencia fiable necesita algo más preciso que el historial del chat. El texto de la conversación puede explicar la intención general, pero no confirma qué comando está activo, qué resultado ya existe ni si la información sigue vigente. El sistema necesita un contrato mínimo de estado que ambas interfaces puedan interpretar.
| Dato | Pregunta que debe responder |
|---|---|
| Identidad | ¿Qué usuario, agente y sesión participan? |
| Intención | ¿Qué resultado autorizó o solicitó el usuario? |
| Entradas | ¿Qué archivos, mensajes, parámetros o referencias se están usando? |
| Paso actual | ¿La tarea está preparando, ejecutando, esperando o verificando? |
| Resultados | ¿Qué produjo ya la sesión y dónde puede comprobarse? |
| Responsable de ejecución | ¿Qué dispositivo o servicio realizará el siguiente paso? |
| Vigencia | ¿Cuándo se verificó el contexto y cuándo debe actualizarse? |
Consideremos una tarea que revisa un calendario en el ordenador y pide confirmar una reunión desde el móvil. El teléfono necesita conocer el evento exacto, el calendario seleccionado, la zona horaria, los participantes y el estado actual. Si solo recibe “confirma la reunión”, puede operar con información incompleta o antigua.
La vigencia evita que una instrucción correcta en el pasado se aplique a un estado nuevo. Un archivo puede haber cambiado, una cita puede haberse cancelado o el usuario puede haber respondido desde otra aplicación. Antes de continuar, el entorno que ejecutará el paso debe comprobar que el objetivo sigue coincidiendo con la vista previa.
El contexto personal también debe viajar de forma selectiva. Un teléfono no necesita recibir todo el historial para resolver una decisión concreta. Agente de IA con contexto personal en el teléfono explica cómo aportar datos útiles sin convertir cada tarea en una copia indiscriminada de cuentas, memoria y conversaciones.
Permisos y aprobaciones ligados al punto de ejecución
Una aprobación solo es válida cuando identifica la tarea, la acción y el entorno que la realizará. Confirmar desde el teléfono puede autorizar una petición concreta, pero los permisos efectivos siguen aplicándose donde se ejecuta el trabajo. Si una sesión permanece en un ordenador, ese entorno conserva sus restricciones sobre archivos, comandos y credenciales.
La pantalla de confirmación debe mostrar el origen de la sesión, el objetivo, la acción solicitada y su consecuencia. “Permitir” resulta insuficiente si no explica qué comando, archivo o servicio quedará afectado. Una aprobación útil podría decir: “Autorizar en el equipo Oficina la modificación del archivo configuración.yml dentro de esta sesión”.
Cuando la tarea migra de verdad, el dispositivo receptor vuelve a evaluar su acceso. Un permiso concedido para leer un archivo en el ordenador no concede acceso automático al almacenamiento Android. Del mismo modo, autorizar una acción en una aplicación móvil no entrega esa autorización a otra sesión o dispositivo. Cada punto de ejecución aplica sus controles y conserva evidencia de la decisión.
Las aprobaciones también necesitan caducidad. Si cambia el comando, el objetivo o el contenido desde que se mostró la vista previa, la decisión anterior deja de describir la acción actual. El sistema debe pedir una nueva confirmación en vez de ampliar silenciosamente el consentimiento.
Para diseñar estos momentos con información suficiente y controles concretos, consulta UX de aprobación de agentes de IA: decisiones claras en el teléfono. En FoneClaw vinculamos las aprobaciones a su sesión y mantenemos aisladas las tareas para que una respuesta afecte únicamente al trabajo que la originó.
Qué ocurre ante desconexiones y contexto obsoleto
Un handoff queda realmente definido cuando explica qué pasa al fallar. La fuente puede entrar en suspensión, el teléfono perder la red, la aplicación cambiar de estado o el token que enlaza las interfaces caducar. El usuario necesita distinguir una sesión pausada de una finalizada y una conexión interrumpida de una tarea que sigue ejecutándose.
Si la interfaz remota se desconecta mientras la fuente continúa, al volver debe recuperar el estado desde el entorno de ejecución. No puede reconstruirlo únicamente con los últimos mensajes almacenados en el móvil. La vista renovada debe indicar qué pasos ocurrieron durante la ausencia, si existe una pregunta pendiente y si algún resultado requiere revisión.
Cuando la fuente se suspende, la política puede pausar la tarea o permitir que continúe en un servicio preparado para ello. Esa decisión debe ser explícita. Mostrar “sin conexión” mientras el proceso sigue modificando archivos crea una expectativa incorrecta; mostrar “sesión en curso en el equipo de origen” permite entender la consecuencia.
Un token caducado exige volver a autenticar la interfaz remota y verificar que la sesión continúa disponible. La reconexión no debe reutilizar aprobaciones antiguas para nuevas acciones. Si el contenido cambió durante la desconexión, el sistema vuelve a presentar la solicitud con sus datos actuales.
También importa la detención. La orden enviada desde el móvil puede tardar en alcanzar la fuente. Hasta recibir confirmación, la interfaz debe mostrar “detención solicitada”, no “detenida”. Después, el registro diferencia los pasos completados, el punto de interrupción y cualquier resultado parcial que necesite limpieza o revisión.
GitHub Copilot CLI como patrón de control remoto
GitHub Copilot CLI ofrece un ejemplo actual y verificable de dirección remota. Según el anuncio de disponibilidad general del control remoto de Copilot CLI, una sesión en ejecución puede supervisarse y dirigirse desde GitHub Mobile, github.com, VS Code y las interfaces compatibles de JetBrains.
El proceso permanece en el entorno donde se inició la CLI. Las interfaces remotas reciben el progreso y permiten orientar el trabajo, poner instrucciones en cola, responder preguntas, aprobar o rechazar solicitudes de permiso y detener la sesión. GitHub Mobile no transforma esa sesión en un proceso local del teléfono; actúa como punto remoto de observación y control.
Supongamos que una tarea de programación está ejecutándose en un ordenador y necesita permiso para modificar un archivo. El móvil puede recibir el estado, mostrar la petición y enviar la decisión. El archivo, el repositorio y el comando permanecen en el equipo de origen. Si el usuario detiene la sesión desde el teléfono, la orden vuelve a ese mismo entorno para interrumpir el proceso.
La documentación de GitHub sobre el control remoto de Copilot CLI permite comprobar esta relación entre sesión de origen e interfaces remotas. En julio de 2026, GitHub añadió además notificaciones en directo para sesiones remotas de Copilot CLI en GitHub Mobile para iOS y Android.
Este patrón resulta útil porque mantiene visible quién ejecuta. También muestra que una notificación, una conversación móvil y una sesión compartida no significan migración. Otros agentes pueden adoptar arquitecturas distintas; la pregunta constante es dónde sigue activo el proceso y qué autoridad conserva cada interfaz.
Continuidad de FoneClaw dentro del mismo teléfono
La base actual de FoneClaw ofrece continuidad entre Home y un asistente flotante móvil dentro de un único teléfono Android. El usuario puede cambiar de la pantalla de inicio a una aplicación y mantener accesibles la ejecución, las confirmaciones, la detención y la recuperación de permisos desde el panel compacto.
Este diseño resuelve un problema cercano al handoff sin mover la tarea entre dispositivos. El entorno de ejecución, los permisos Android y el estado permanecen en el mismo teléfono. Lo que cambia es el punto desde el que el usuario observa o dirige la solicitud. Así se evita reconstruir la tarea cada vez que Android abre Ajustes, vuelve a Home o muestra otra aplicación.
La versión también incorpora la posibilidad de adjuntar con un toque la pantalla actual. FoneClaw excluye sus propias superposiciones de la captura, de modo que el modelo recibe el contenido de la aplicación y no el panel flotante. Un modelo configurado interpreta ese contexto; las herramientas gobernadas realizan las acciones Android compatibles.
Imaginemos que FoneClaw prepara una ruta a partir de una dirección visible. El usuario adjunta la pantalla, revisa el destino y abre la aplicación de mapas compatible. Si falta ubicación, el flujo conduce al permiso correspondiente. Al volver desde Ajustes o Home, el panel conserva el estado y permite continuar, detener o corregir la tarea.
Las capacidades actuales de FoneClaw reúnen estados independientes, aprobaciones ligadas a la sesión y aislamiento entre tareas. La base actual lleva esos controles al asistente flotante y añade acciones rápidas iniciales. Puedes revisar la información más reciente disponible en la página de descarga de FoneClaw y consultar las áreas de ejecución en la página de funciones de FoneClaw.
Cómo probar un handoff de forma segura
Una evaluación fiable necesita una tarea reversible y dos dispositivos o interfaces claramente identificados. Evita empezar con envíos, borrados o cambios de producción. Una buena prueba consiste en generar un archivo temporal o una nota de prueba, solicitar una revisión remota y comprobar todo el ciclo.
- Iniciar: crea la tarea en el entorno de origen y registra su nombre, identidad de sesión, entradas y resultado esperado.
- Dirigir: abre la interfaz remota y confirma que muestra el mismo paso actual, el entorno que ejecuta y la hora de la última actualización.
- Aprobar: provoca una acción que necesite permiso. Verifica que la tarjeta identifica el comando, el objetivo y el dispositivo de ejecución.
- Detener: solicita la interrupción desde la interfaz remota. Comprueba primero el estado “solicitada” y después la confirmación del entorno de origen.
- Reconectar: corta la red del dispositivo remoto, deja que la fuente cambie de estado y vuelve a conectar. La interfaz debe recuperar el estado real, no repetir el último mensaje almacenado.
- Revisar: comprueba el historial de instrucciones, aprobaciones, resultados, desconexiones y pasos incompletos.
- Eliminar: cierra la sesión, revoca el acceso remoto y verifica qué datos locales o temporales deben borrarse en cada dispositivo.
Durante la prueba, cambia deliberadamente el archivo o la entrada después de mostrar una aprobación. El sistema debe invalidar la vista previa anterior y pedir una nueva decisión. También conviene dejar caducar el enlace o token remoto para comprobar que la reautenticación no reactiva permisos pendientes.
Si la tarea descubre herramientas o recursos durante el recorrido, el descubrimiento tampoco equivale a autorización. Agentic Resource Discovery: catálogos fiables sin confundir descubrimiento y autorización explica cómo comprobar procedencia y alcance antes de permitir que un agente utilice una capacidad encontrada.
El criterio final es sencillo: el usuario debe poder responder en cualquier momento qué tarea está activa, dónde se ejecuta, qué entrada usa, qué permiso espera y cómo detenerla. Un handoff seguro no oculta esos datos tras una continuidad visual; los conserva como parte verificable del trabajo.