UX de aprobación de agentes de IA: decisiones claras en el teléfono

Detectar el momento exacto de la decisión

Una buena UX de aprobación de agentes de IA empieza por identificar el instante en que una propuesta se convierte en un cambio real. Leer un mensaje, resumir una pantalla o preparar un borrador no produce el mismo efecto que enviar, borrar, compartir, modificar un ajuste o iniciar una ruta. La confirmación debe aparecer cuando todavía es posible revisar la acción, pero después de que el agente haya reunido suficiente contexto para explicar qué pretende hacer.

Imaginemos una orden hablada: “Avisa a Lucía de que llegaré veinte minutos tarde”. El agente puede redactar el texto sin interrumpir al usuario. Antes del envío, la pantalla debe mostrar el contacto seleccionado, la aplicación, la cuenta remitente y el mensaje final. Los botones también necesitan verbos precisos: “Enviar mensaje”, “Editar” y “Cancelar” expresan mejor la consecuencia que un “Aceptar” genérico.

El momento cambia según la acción. Abrir la pantalla de Wi-Fi puede ser una navegación preparatoria; desactivar la conexión altera el estado del teléfono. Calcular una ruta es una consulta; compartir la ubicación con otra persona produce un efecto externo. El diseño debe colocar el control en esa transición, no llenar de confirmaciones todos los pasos anteriores.

En FoneClaw mantenemos la preparación y la acción como estados visibles. La base actual vincula las aprobaciones a la sesión donde nacieron y aísla las tareas para que una confirmación no termine asociada a otra conversación. Esto permite que el usuario vea qué está pendiente, revise el objetivo y continúe únicamente con la acción que reconoce.

Para profundizar en la relación entre identidad, permiso y registro de actividad, Identidad de agentes de IA: permisos, aprobación por herramienta y auditoría en Android explica cómo comprobar quién solicita una acción y qué evidencia debería quedar después.

Distinguir propuestas, vistas previas y aplicación

La interfaz debe nombrar con claridad tres estados: sugerencia, vista previa y resultado aplicado. Una sugerencia presenta una posible acción sin preparar todavía todos sus datos. La vista previa reúne el objetivo, el contenido y la consecuencia para que el usuario decida. El resultado aplicado confirma que el cambio ya se realizó y muestra dónde comprobarlo.

Esta separación evita un problema habitual: confundir texto generado con una acción completada. Un correo redactado no está enviado; una dirección reconocida no ha iniciado la navegación; un nombre de archivo propuesto no significa que el archivo se haya movido. Cada pantalla necesita un estado dominante y una acción principal coherente con ese estado.

GitHub mostró un patrón relacionado en la actualización de GitHub Changelog del 23 de julio de 2026. En esa versión preliminar pública, determinadas modificaciones de GitHub Issues pueden proponerse para revisión. Las acciones con confianza alta pueden aplicarse automáticamente, mientras las de confianza media o baja esperan una decisión. GitHub también registra un motivo que explica la propuesta.

La lección útil para el móvil es la estructura de la interacción: proponer, explicar, esperar o aplicar y mostrar el resultado. En GitHub, el alcance corresponde a acciones compatibles sobre incidencias; en Android, cada producto necesita definir sus propios objetivos y controles. Las aprobaciones facilitan el trabajo del usuario, mientras los permisos de Android y los controles del servicio siguen determinando qué acceso existe realmente.

En FoneClaw usamos estados comprensibles para que una tarea pueda estar ejecutándose, esperando una decisión, completada o interrumpida. Cuando la acción requiere confirmación, el usuario debe poder distinguir una propuesta editable de un cambio ya realizado. Después de aplicar, la interfaz debe devolver un resultado concreto: mensaje enviado, ajuste actualizado, nota creada o motivo por el que el paso no terminó.

Usar la confianza para distribuir la revisión

La confianza puede ayudar a decidir cuánto esfuerzo de revisión necesita una propuesta, pero no representa una garantía. Un agente puede reconocer con mucha seguridad un contacto equivocado porque existen dos personas con nombres parecidos. También puede tener confianza baja ante una acción sencilla debido a una pantalla incompleta. Por eso la puntuación debe combinarse con el impacto y la posibilidad de corregir el resultado.

Una clasificación práctica considera al menos cuatro variables: claridad del objetivo, calidad del contexto, consecuencia de la acción y facilidad para deshacerla. Renombrar una nota recién creada puede tolerar una ruta más ágil si el título y el contenido están claros. Enviar un mensaje profesional, cambiar un ajuste importante o eliminar un archivo exige una revisión más cuidadosa aunque la interpretación parezca sólida.

La interfaz tampoco necesita mostrar un porcentaje técnico sin explicación. Para el usuario resulta más útil leer “Contacto ambiguo: hay dos coincidencias” o “Hora inferida del mensaje anterior” que ver un 72 %. La incertidumbre debe traducirse en una pregunta concreta: elegir destinatario, confirmar cuenta, completar fecha o revisar el contenido.

En un teléfono, la atención es limitada. Una buena distribución de la revisión reserva las interrupciones más visibles para decisiones que realmente lo requieren. Las acciones preparatorias pueden avanzar; las de consecuencia baja pueden ofrecer una confirmación compacta; las sensibles deben mostrar todos los datos relevantes. Si falta información esencial, la tarea pasa a espera en vez de inventar el dato.

La base actual de FoneClaw mantiene estados independientes para tareas en curso y en espera. Así, una solicitud ambigua puede detenerse mientras otra tarea compatible continúa. Cuando el usuario vuelve, encuentra la pregunta pendiente dentro de su contexto original y puede responder sin reconstruir toda la conversación.

Mostrar motivo, objetivo, consecuencia y evidencia

Antes de pedir una aprobación, el agente debe explicar cuatro elementos en poco espacio: por qué propone la acción, cuál es el objetivo exacto, qué efecto tendrá y qué información utilizó. Esta explicación no necesita reproducir todo el razonamiento interno. Debe aportar los datos que permiten detectar un error antes de actuar.

Una tarjeta de confirmación para un mensaje podría indicar: “Avisar a Lucía porque la ruta muestra una demora de veinte minutos”. Debajo aparecerían el contacto, la aplicación elegida y el texto. Para un cambio de ajuste: “Activar Bluetooth para conectar los auriculares seleccionados”, seguido del dispositivo y del estado actual. En ambos casos, el motivo conecta la intención del usuario con la consecuencia visible.

La evidencia debe ser verificable y proporcional. Si el agente propone una cita a partir de un correo, puede mostrar la fecha y la frase relevante, además del calendario de destino. Si prepara una navegación, debe enseñar la dirección resuelta y permitir corregirla. No hace falta inundar la pantalla con registros técnicos; basta con presentar aquello que podría cambiar la decisión.

También conviene indicar qué ocurrirá después. “Se enviará ahora”, “se abrirá una vista previa”, “el archivo se moverá a esta carpeta” o “el ajuste permanecerá activo hasta que lo cambies” son consecuencias distintas. Cuando existe una ruta de deshacer, la interfaz puede anticiparla. Si el cambio no ofrece recuperación inmediata, la confirmación debe ser más explícita.

La explicación mejora la decisión, pero no sustituye a los controles de acceso. Para entender cómo se complementan el entorno aislado del agente, los permisos Android y la autorización del usuario, consulta Sandbox de agentes de IA y permisos del teléfono: por qué aún hacen falta límites. En FoneClaw usamos la aprobación para mantener la intención y el efecto unidos dentro de una tarea gobernada.

Vincular cada aprobación con su tarea

Un teléfono puede manejar varias solicitudes a la vez: una ruta en curso, un borrador pendiente y una comprobación de ajustes. Si las confirmaciones aparecen sin contexto, el usuario puede aprobar la acción correcta en la conversación equivocada. Por eso cada aprobación debe conservar su relación con la tarea, la sesión, el objetivo y el momento en que se generó.

La tarjeta pendiente debería incluir un título reconocible, el estado actual y la acción que espera respuesta. “Mensaje para Lucía: esperando revisión” es más seguro que “Se necesita aprobación”. Si el usuario abre otra conversación, esa tarjeta no debe transformarse ni heredar información del nuevo contexto. Al regresar, la propuesta original debe seguir mostrando los datos con los que fue preparada.

La base actual de FoneClaw refuerza este modelo mediante aprobaciones vinculadas a la sesión, aislamiento de tareas y estados separados de ejecución y espera. Una tarea que necesita permiso puede quedar pausada mientras otra avanza de forma independiente. La decisión posterior se aplica a la solicitud correspondiente, sin mezclar destinatarios, cuentas ni resultados.

El tiempo también importa. Si el contexto puede haber cambiado, la aprobación debe actualizarse o caducar. Una ruta calculada hace una hora, un archivo que ya fue movido o un contacto modificado requieren una nueva comprobación antes de continuar. No basta con conservar un botón antiguo; hay que validar que el objetivo sigue existiendo y que la consecuencia sigue siendo la misma.

Para usuarios que supervisan varias tareas, Control de agentes de IA móvil: el teléfono como centro de mando desarrolla cómo reunir estados, decisiones pendientes y resultados sin convertir cada conversación en una cola difícil de entender.

Aplicar el patrón a acciones del teléfono

La misma estructura de aprobación puede adaptarse a distintas acciones Android, pero la información visible cambia según el caso. En mensajería importan destinatario, cuenta, aplicación, texto y archivos. En ajustes del dispositivo interesa mostrar el valor actual, el nuevo estado y su efecto. Para archivos hacen falta nombre, ubicación de origen, destino y tipo de operación. En navegación, la dirección resuelta y el medio de transporte son esenciales.

Un mensaje puede seguir esta secuencia: el agente propone el texto, el usuario revisa el destinatario y finalmente aprueba el envío. Para un ajuste, FoneClaw puede presentar el cambio compatible y solicitar el permiso requerido por Android antes de realizarlo. Si se trata de una nota o tarea, la vista previa puede mostrar título, contenido y ubicación. Cada recorrido conserva un punto claro entre preparación y efecto.

Las acciones también se diferencian por su capacidad de recuperación. Abrir una aplicación o consultar el estado del dispositivo no requiere el mismo control que eliminar un archivo. Crear una nota suele permitir una corrección posterior; enviar información a otra persona puede ser irreversible. La interfaz debe ajustar la prominencia de la confirmación a esa diferencia, sin obligar al usuario a leer el mismo aviso para todas las operaciones.

En FoneClaw centramos la experiencia en acciones Android soportadas con resultados visibles. El agente puede preparar el siguiente paso, solicitar el permiso necesario y mostrar una confirmación cuando la consecuencia lo requiere. Si la aplicación, el estado del teléfono o el permiso disponible impiden continuar, la tarea queda explicada y ofrece una salida concreta.

Una prueba útil consiste en empezar con una acción reversible: crear una nota de prueba, cambiar su título y eliminarla después de revisar cada estado. A continuación, prueba una acción que requiera permiso y recházalo la primera vez. La experiencia es correcta si muestra qué quedó pendiente, permite retomar la tarea y no obliga a repetir toda la solicitud.

Rechazar, corregir y recuperar el control

Aprobar no puede ser la única salida. Una interfaz completa ofrece rechazar, editar, volver a preparar, deshacer cuando sea posible y continuar manualmente. Cada opción responde a una situación diferente: el usuario puede estar en desacuerdo con la acción, detectar un dato incorrecto, preferir otra aplicación o necesitar terminar el paso mediante la pantalla táctil.

“Rechazar” debe cerrar la propuesta sin ejecutar el cambio y explicar qué ocurrió con la tarea. “Editar” conserva el contexto y permite corregir un campo concreto. “Volver a preparar” resulta útil cuando ha cambiado la información de origen. “Tomar el control” abre el punto adecuado del teléfono para que el usuario continúe directamente. Estos resultados deben evitar que una acción cancelada reaparezca como si siguiera autorizada.

La recuperación de permisos merece su propio recorrido. Si Android bloquea una función porque falta acceso, FoneClaw puede indicar qué permiso necesita la acción compatible y llevar al usuario al punto correspondiente. Tras concederlo, las capacidades actuales facilitan retomar el trabajo interrumpido. Si el usuario mantiene la denegación, la tarea debe ofrecer una alternativa manual o finalizar con un estado claro.

También puede fallar la continuidad al volver desde la pantalla de inicio. La base actual de FoneClaw mejora la recuperación de esa ejecución para conservar el objetivo y explicar qué paso quedó pendiente. La interfaz debe volver a verificar el estado antes de repetir una acción: reenviar un mensaje o aplicar dos veces un cambio porque la primera respuesta fue incierta puede causar un problema mayor que el fallo original.

Cuando exista una función de deshacer, debe estar cerca del resultado y durar el tiempo suficiente para que el usuario detecte el error. Si la reversión no está disponible, el sistema puede ofrecer una acción compensatoria, como restaurar un valor anterior o abrir el elemento afectado para corregirlo. El historial debe distinguir el intento, la aprobación, el resultado y cualquier reparación posterior.

La mejor UX de aprobación de agentes de IA no añade fricción por defecto. Convierte decisiones importantes en momentos comprensibles: muestra el objetivo, explica la consecuencia, conserva el contexto correcto y devuelve el control cuando algo cambia. En FoneClaw usamos esos principios para que las tareas Android compatibles puedan avanzar con rapidez sin perder de vista quién decide y qué resultado queda en el teléfono.