Enrutamiento de capacidades de agentes de IA: AutoAttach, Suggest y Fallback en Android

De una petición Android a candidatos de capacidad

El enrutamiento de capacidades de agentes de IA empieza cuando una petición natural necesita convertirse en una acción Android posible. Imagina que el usuario dice: “lee esta pantalla, prepara un mensaje para Laura y déjamelo revisar antes de enviarlo”. El agente no debería cargar todas las herramientas, Skills, Workflows y Plugins en el contexto ni decidir una acción por intuición. Debe convertir la petición en candidatos: lectura de pantalla, identificación de contacto, redacción de mensaje, posible envío, aprobación y recuperación si el contacto o el permiso no encajan.

La primera capa es el contexto. La pantalla actual puede indicar que el usuario responde a una conversación; el nombre “Laura” puede necesitar desambiguación; la frase “déjamelo revisar” marca una frontera de aprobación. Con esos datos, el router reduce el espacio de búsqueda. En vez de preguntar al modelo por todo el catálogo, ordena capacidades relevantes por intención, estado del dispositivo, permisos disponibles, confianza del candidato y riesgo de la acción.

La segunda capa es el resultado esperado. Preparar un mensaje no es lo mismo que enviarlo. Leer una pantalla no es lo mismo que guardar su contenido. Descubrir una capacidad no significa activarla, y seleccionar un candidato no significa ejecutarlo. Esta separación evita el error más peligroso del enrutamiento contextual: confundir coincidencia semántica con autorización.

En FoneClaw usamos esta lectura porque un agente Android útil debe ser eficiente sin volverse opaco. Si el lector necesita una descripción amplia de las capas, nuestra guía Herramientas, Plugins, Skills y Workflows de FoneClaw: guía de capas cubre el glosario general; aquí nos centramos en la mecánica concreta que decide qué candidato entra en el flujo.

Cuándo usar AutoAttach, Suggest o Fallback

AutoAttach, Suggest y Fallback resuelven tres momentos distintos del mismo problema. AutoAttach sirve cuando el router tiene confianza suficiente para añadir contexto local o metadatos de capacidad al flujo sin ejecutar una herramienta. Por ejemplo, si el usuario pide “resume esta pantalla” desde el asistente flotante y la pantalla actual está disponible por una acción explícita del usuario, AutoAttach puede adjuntar ese contexto para que el modelo razone mejor. El punto crítico es que adjuntar contexto no completa ninguna acción sensible.

Suggest aparece cuando hay una ruta probable, pero conviene mostrarla como elección revisable. Si el usuario pide “crea un recordatorio para llamar a Laura” y existen varias Lauras, o si hay dos formas razonables de guardar la tarea, Suggest puede presentar la opción: elegir contacto, crear tarea, abrir calendario o preparar texto. El usuario ve la dirección antes de que el sistema avance. Suggest es especialmente útil cuando una selección automática sería demasiado agresiva.

Fallback entra cuando el router no encuentra una ruta clara, una dependencia falta, una capacidad está desactivada, la confianza cae o una política impide continuar. Fallback no bypassa permisos ni transforma una ruta insegura en segura. Su trabajo es mantener utilidad: pedir aclaración, preparar contenido sin ejecutarlo, abrir una pantalla de configuración, explicar qué falta o dejar la tarea en un punto manual.

Estas tres rutas evitan dos extremos. Un extremo carga demasiado contexto y confunde al modelo. El otro fuerza confirmaciones en cada paso y vuelve lenta la experiencia. El router decide con granularidad: cuándo adjuntar, cuándo sugerir y cuándo detenerse con una alternativa.

La diferencia entre AutoAttach y Suggest se resume así: AutoAttach mejora el contexto de la tarea cuando el sistema ya tiene una señal fuerte; Suggest convierte una selección posible en una decisión visible. Fallback protege el flujo cuando ninguna de las dos rutas alcanza el umbral necesario.

Descubrimiento, adjunto, activación, aprobación y ejecución

Un router de capacidades debe comportarse como una máquina de estados, no como un salto directo desde “encontré algo” hasta “lo hice”. El primer estado es descubrimiento: el sistema identifica herramientas, Skills, Workflows o Plugins que podrían ayudar. La especificación de Agent Plugins descrita por Google Developers muestra una dirección de ecosistema útil: empaquetar Skills y servidores MCP con metadatos compartidos. Ese empaquetado mejora descubrimiento, pero no crea confianza automática ni ejecución autorizada.

El segundo estado es adjunto. Aquí el router puede añadir contexto, metadatos o una referencia de capacidad al razonamiento. Adjuntar no instala, no habilita y no ejecuta. Es una forma de dar al modelo información suficiente para proponer un plan más preciso.

El tercer estado es activación. Una capacidad desactivada, un Plugin pendiente o una Skill aprendida pero no confirmada no deben tratarse como listas para actuar. La activación necesita revisión, dependencia resuelta y estado coherente. En un sistema serio, los snapshots de capacidades deben ser atómicos: si una actualización falla, el usuario no queda con media capacidad activa y media rota.

El cuarto estado es aprobación. Una capacidad habilitada no significa que todas sus acciones estén aprobadas. Enviar, llamar, modificar datos, instalar, compartir o cambiar ajustes sigue necesitando la aprobación correspondiente. Para profundizar en esta frontera, la guía UX de aprobación de agentes de IA: decisiones claras en el teléfono explica cómo mostrar confianza, motivo y consecuencia sin convertir la aprobación en un obstáculo confuso.

El quinto estado es ejecución y verificación. La herramienta corre, Android muestra resultados o exige permisos, y el agente comprueba qué pasó. Si el resultado no coincide con el plan, el flujo entra en recuperación. Esta máquina de estados protege al usuario y también mejora el producto: cada fallo queda ligado a un punto concreto del ciclo, no a una respuesta genérica del modelo.

Manifiestos, dependencias, contexto y confianza

La selección contextual de capacidades necesita entradas limpias. El manifiesto da identidad: nombre, propósito, capacidades declaradas, entradas esperadas, salidas, permisos y límites. Sin identidad clara, el router puede elegir una capacidad parecida pero incorrecta. El nombre visible ayuda al usuario, pero el router necesita señales estructuradas para evitar falsos positivos.

Las dependencias son la segunda entrada. Una Skill puede necesitar una herramienta concreta; un Plugin puede depender de un servicio; una acción Android puede requerir permiso o app instalada. Si una dependencia no está resuelta, la capacidad no debería presentarse como lista para ejecución. El router puede sugerir activación, pedir permiso, mostrar un Fallback o dejar el resultado preparado, pero no debe fingir que la ruta está completa.

La tercera entrada es metadato de contexto: pantalla actual, app activa, tipo de contenido, idioma, entidad detectada, hora, ubicación aproximada cuando procede, historial de tarea y restricciones de usuario. Estos datos no deben inflar el contexto sin motivo. Deben ayudar a ordenar candidatos y reducir ambigüedad. Si el usuario pide “guarda esto”, la pantalla actual puede ser decisiva; si pide “enciende la linterna”, adjuntar una pantalla entera solo añade ruido.

La cuarta entrada es confianza. La confianza no es una etiqueta única; combina coincidencia de intención, disponibilidad, permisos, dependencia, claridad del objetivo y riesgo. Cuando la confianza es alta y el paso no ejecuta una acción sensible, AutoAttach puede encajar. Cuando hay una opción probable pero revisable, Suggest es mejor. Cuando falta una pieza, Fallback conserva control.

El descubrimiento externo merece una página propia porque introduce catálogos, registros y gobierno de confianza. Para ese nivel, enlazamos Agentic Resource Discovery: catálogos fiables sin confundir descubrimiento y autorización. En esta guía, la regla operativa es directa: los metadatos ayudan a enrutar, pero nunca sustituyen activación, permiso ni aprobación.

Recuperación ante rutas faltantes, antiguas o ambiguas

El enrutamiento de herramientas Android falla de formas previsibles. La primera es la capacidad ausente: el usuario pide una acción que no existe en las herramientas disponibles. El agente debe decirlo y ofrecer una alternativa concreta, como preparar el texto, abrir la app manualmente o guardar una nota de seguimiento. Reintentar con otro modelo rara vez arregla una capacidad que no existe.

La segunda es una dependencia antigua o rota. Un Plugin puede haber cambiado, una Skill puede depender de una herramienta deshabilitada o una app Android puede mostrar una pantalla distinta. En esos casos, el router debe invalidar el candidato, volver al snapshot estable o proponer revisión. La continuidad de tarea consiste en no perder el objetivo del usuario mientras se resuelve el estado técnico.

La tercera es permiso denegado. Si falta permiso de contactos, calendario, ubicación, notificaciones o sistema, la recuperación no consiste en rodearlo. Consiste en explicar qué permiso falta, por qué se necesita y qué parte de la tarea puede continuar sin él. Para el tratamiento de permisos en capacidades aprendidas o importadas, la guía Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real desarrolla el riesgo con más detalle.

La cuarta es ambigüedad. Dos contactos, dos apps, dos calendarios o dos rutas posibles pueden parecer pequeños detalles, pero en el móvil cambian el resultado. El router debe preferir Suggest o una pregunta breve antes de ejecutar. La quinta es falso positivo: una capacidad parece relevante por texto, pero no soporta la acción real. Un buen banco de pruebas incluye falsos positivos y casos sin coincidencia, no solo ejemplos fáciles.

La recuperación visible protege la confianza. El usuario no necesita ver todo el árbol interno, pero sí entender qué falta, qué se puede hacer ahora y qué requiere aprobación o intervención.

Enrutamiento gobernado de capacidades en FoneClaw

En FoneClaw construimos el enrutamiento de capacidades alrededor de una frontera clara: encontrar una ruta no es ejecutarla. FoneClaw ofrece 100+ built-in tools para acciones Android soportadas y añade rutas gobernadas mediante Skills, Workflows y Plugins revisados. El modelo ayuda a interpretar la petición; FoneClaw decide qué capacidad puede entrar en el flujo, qué contexto se adjunta, qué se sugiere, qué queda como Fallback y qué necesita aprobación visible.

Volvamos a la petición inicial: “lee esta pantalla, prepara un mensaje para Laura y déjamelo revisar antes de enviarlo”. Si el usuario adjuntó la pantalla actual, AutoAttach puede aportar ese contexto al razonamiento. Si hay varias Lauras, Suggest presenta una elección. Si no hay permiso de contactos, Fallback puede preparar el mensaje sin destinatario final o guiar al usuario al permiso necesario. Si el usuario confirma destinatario y texto, entonces la ejecución entra en la ruta Android compatible con resultado visible.

La activación de Plugins mantiene revisión. Un Plugin descubierto o recomendado no se instala ni se activa en silencio. La activación se revisa, y los snapshots atómicos evitan que una actualización fallida deje capacidades a medias. Las Skills aprendidas también pasan por vista previa y confirmación antes de guardarse como borrador deshabilitado. Esta conducta puede parecer conservadora, pero en un teléfono es práctica: contactos, mensajes, calendario, archivos, apps y ajustes requieren límites que el usuario pueda entender.

AutoAttach, Suggest y Fallback tampoco sustituyen la aprobación. AutoAttach no ejecuta herramientas. Suggest no instala Plugins. Fallback no bypassa permisos. Esas tres rutas mejoran la selección, no eliminan el contrato de acción. Cuando una acción afecta el dispositivo, FoneClaw muestra lo que va a ocurrir, pide confirmación donde corresponde, ejecuta dentro de capacidades soportadas y verifica el resultado.

Ese patrón nos permite avanzar hacia agentes Android más útiles sin vender control universal de todas las apps. Preferimos una ruta clara, recuperable y aprobada a una promesa amplia que falle cuando aparece una pantalla inesperada. La mecánica de enrutamiento es lo que convierte una intención natural en un flujo que el usuario puede seguir.

Siete comprobaciones para diseñar y probar el router

Un router de capacidades se prueba por decisiones, no solo por precisión semántica. Primera comprobación: ¿el sistema genera candidatos razonables para una petición real de Android? Segunda: ¿ordena esos candidatos usando contexto, permisos, dependencias y riesgo, no solo palabras parecidas? Tercera: ¿detecta falsos positivos cuando una capacidad parece adecuada pero no soporta la acción?

Cuarta: ¿maneja casos sin coincidencia con Fallback útil? Quinta: ¿separa descubrimiento, adjunto, activación, aprobación y ejecución en estados observables? Sexta: ¿evita estados parciales cuando una dependencia o Plugin falla? Séptima: ¿comprueba el resultado y ofrece recuperación cuando Android no coincide con el plan?

La prueba mínima debe incluir una ruta clara, una ruta ambigua, una ruta sin capacidad, una dependencia ausente y una acción sensible que requiera aprobación. También conviene probar cancelación voluntaria: un agente que no sabe detenerse no está gobernado. El objetivo no es que AutoAttach, Suggest o Fallback aparezcan en todos los flujos; el objetivo es que aparezcan cuando reducen ambigüedad, mantienen control y ayudan a terminar la tarea de forma visible.

Cuando el router cumple esas comprobaciones, el usuario percibe una diferencia concreta: pide algo en lenguaje natural, el agente elige una ruta razonable, muestra las decisiones importantes y se recupera sin inventar éxito. Esa es la base práctica del enrutamiento de capacidades en un agente Android.