Agentic Resource Discovery: catálogos fiables sin confundir descubrimiento y autorización

Qué resuelve Agentic Resource Discovery

Agentic Resource Discovery, o ARD, responde a una pregunta muy concreta: ¿cómo puede un agente encontrar herramientas, skills y otros agentes publicados en la web sin depender de listas privadas, integraciones manuales o nombres ambiguos? La presentación de Agentic Resource Discovery publicada por Google Developers el 17 de junio de 2026 describe ARD como una especificación abierta para publicar, descubrir y verificar recursos agentivos en distintos dominios.

El punto práctico es el archivo ai-catalog.json. Una organización puede alojar un catálogo bajo su propio dominio y declarar allí qué capacidades ofrece: herramientas, agentes, servidores MCP, agentes A2A, herramientas OpenAPI o incluso catálogos anidados. Ese catálogo no convierte la capacidad en segura ni ejecutable por sí sola; la hace localizable y describible de una forma que un cliente o registro puede procesar.

Sin ARD, cada proveedor tiende a crear su propio directorio, su propio formato de metadatos y su propio flujo de conexión. Eso complica la vida a equipos que quieren que sus agentes descubran capacidades por intención, verifiquen quién las publica y conecten con la interfaz correcta. ARD intenta ordenar esa fase inicial: encontrar el recurso adecuado, leer sus metadatos, comprobar su origen y pasar al protocolo nativo que corresponda.

Para un agente de teléfono, esta separación es esencial desde el primer paso. Descubrir que existe una herramienta de calendario, mensajería o ubicación no significa que el usuario haya permitido usarla, que Android haya concedido permisos, ni que la acción concreta sea apropiada. ARD mejora el mapa de recursos; la autoridad para actuar pertenece a otra fase.

Cómo publican y encuentran capacidades los catálogos y registros

El flujo de ARD se entiende mejor como cuatro fases separadas: publicar, descubrir o resolver, verificar y conectar. En la publicación, el proveedor aloja un catálogo de capacidades en su dominio. En el descubrimiento, un cliente puede consultar un registro por intención o recuperar directamente el catálogo de un socio conocido. En la verificación, el cliente revisa metadatos del publicador. En la conexión, el agente usa el protocolo nativo anunciado por el recurso.

La diferencia entre catálogo y registro evita mucha confusión. El catálogo es la fuente publicada por el proveedor: describe capacidades, endpoints, protocolos, versiones y metadatos. El registro indexa catálogos para que un cliente pueda buscar por una necesidad en lenguaje natural o por criterios técnicos. Según el anuncio de ARD, los registros pueden rastrear e indexar catálogos alojados por organizaciones y devolver capacidades coincidentes junto con información de verificación.

La especificación pública de ARD y su repositorio hacen visible el trabajo de esquemas, arquitectura de confianza y referencias. Como la especificación evoluciona en público, conviene tratar sus ejemplos como material técnico para implementación, no como prueba de adopción universal por todos los proveedores o registros.

Qué demuestra la verificación del publicador y qué queda pendiente

La verificación del publicador resuelve una parte importante del riesgo: ayuda a confirmar que el catálogo procede del dominio o entidad que dice publicarlo y que los metadatos no han sido sustituidos sin control. En un ecosistema de agentes, esto importa porque una capacidad mal atribuida puede llevar al agente a conectar con un recurso equivocado, caducado o imitado.

Aun así, identidad no equivale a permiso. Un catálogo publicado por el dominio correcto puede describir una herramienta real, pero el cliente todavía debe comprobar si el endpoint es compatible, si el alcance solicitado encaja con la tarea, si la acción está habilitada localmente y si el usuario tiene autoridad para pedirla. La confianza en el origen reduce incertidumbre sobre quién habla; no demuestra que todo comportamiento posterior sea adecuado.

En términos de producto, la verificación responde a “¿este recurso viene de quien dice venir?”. La autorización responde a “¿puede este agente usarlo ahora, para esta persona, en esta acción, con este destino?”. Mezclar esas preguntas crea sistemas que parecen fiables porque muestran un publicador verificado, pero terminan ejecutando pasos que el usuario no ha aprobado o que el teléfono no debería permitir.

También hay riesgos de frescura. Un catálogo puede quedar desactualizado, anunciar una interfaz que cambió, omitir límites de plan o describir una capacidad que requiere credenciales aparte. Por eso la verificación debe combinarse con pruebas de endpoint, manejo de errores, controles de versión y una forma clara de desactivar el recurso si deja de comportarse como se esperaba.

Cómo ARD entrega la conexión a MCP, A2A, OpenAPI y contratos de apps

ARD no reemplaza MCP, A2A, OpenAPI ni los contratos propios de una aplicación. Los anuncia y ayuda a encontrarlos. Una entrada de catálogo puede decir que una capacidad está disponible como servidor MCP, como agente A2A, como herramienta OpenAPI o mediante otra interfaz. Después de resolver y verificar el recurso, la conexión real pasa por esa interfaz nativa.

Esta decisión de diseño es sana: el descubrimiento no necesita absorber todos los protocolos. MCP puede seguir definiendo cómo se exponen herramientas a un modelo o cliente; A2A puede seguir coordinando agentes; OpenAPI puede describir endpoints HTTP; una app móvil puede ofrecer contratos invocables propios. ARD funciona como la guía de acceso: dónde está la capacidad, quién la publica y cómo se debe iniciar la conexión.

En móviles, el paso desde “encontré una capacidad” hasta “puedo invocarla” es especialmente delicado. Muchas apps no exponen acciones invocables por máquinas, otras dependen de intents, permisos, sesiones o pantallas intermedias, y algunas acciones solo son seguras después de una revisión del usuario. Si quieres profundizar en esa fase posterior al descubrimiento, App Intents y apps invocables por máquinas: qué cambia para los agentes de IA explica cómo una app puede ofrecer contratos accionables sin convertir cada pantalla en una superficie libre para automatización.

La implicación para ARD es clara: encontrar un recurso mejora la integración inicial, pero la llamada debe validar el protocolo anunciado, los tipos de entrada, la autenticación, los errores esperados y los límites de la app. Un agente bien diseñado no improvisa una acción del teléfono porque un catálogo mencionó una capacidad parecida.

Por qué descubrir una herramienta no autoriza una acción en el móvil

En un teléfono, el descubrimiento y la autorización resuelven problemas distintos. ARD puede ayudar a saber que una capacidad existe, quién la publica y cómo conectarse. Android y el runtime del agente deben decidir si la acción está habilitada, si el usuario concedió permisos, si el destino es correcto y si el riesgo exige confirmación.

La guía de Android sobre solicitud de permisos en contexto mantiene esa responsabilidad en la aplicación: pedir permisos cuando una función los necesita y manejar correctamente una denegación. Ese mecanismo no verifica a un proveedor remoto ni aprueba una consecuencia de negocio; solo controla el acceso de la app a recursos del dispositivo.

Un ejemplo lo muestra rápido. Un catálogo puede anunciar una herramienta para enviar mensajes. La verificación puede confirmar que el publicador es correcto. Pero enviar un mensaje desde un Android exige acceso a la app o canal compatible, destinatario correcto, contenido visible, permiso o intent apropiado y, para un paso con efecto externo, una aprobación que el usuario entienda. Si cualquiera de esas piezas falla, el agente debe detenerse, pedir información o proponer una alternativa visible.

Para equipos que diseñan skills móviles, la lectura complementaria es Seguridad de habilidades de agentes de IA: por qué el móvil necesita permisos en tiempo real, porque ahí la pregunta se desplaza desde el catálogo hacia la habilidad concreta y sus permisos durante la ejecución.

Checklist antes de conectar y ejecutar un recurso descubierto

Un catálogo fiable de herramientas de agentes sirve de punto de partida, no de vía libre. Antes de conectar un recurso descubierto a un phone agent, conviene pasar por una secuencia breve y observable. El objetivo no es crear burocracia; es evitar que una coincidencia prometedora se convierta en una acción opaca en el dispositivo.

1. Confirma el publicador. Revisa dominio, metadatos verificables y coherencia entre marca, endpoint y catálogo.
2. Comprueba la frescura. Mira versión, fecha, cambios de esquema y señales de catálogo obsoleto.
3. Valida la interfaz. Prueba si el recurso habla el protocolo anunciado, ya sea MCP, A2A, OpenAPI u otro contrato.
4. Reduce el alcance. Activa solo la capacidad necesaria para la tarea y evita permisos generales cuando basta un paso acotado.
5. Empieza con una prueba de bajo riesgo. Usa una lectura, una simulación o una acción reversible antes de tocar comunicación, datos sensibles o controles del dispositivo.
6. Revisa destino y contenido. Antes de una acción externa, muestra a quién afecta, qué se enviará, qué cambiará y qué coste puede tener.
7. Registra resultado y fallo. El usuario debe poder ver si la acción se completó, quedó parcial, fue denegada o necesita intervención.
8. Ofrece parada y revocación. Desactivar una herramienta, retirar permisos o cambiar de endpoint debe ser una operación comprensible.

Esta lista se une a la gobernanza de identidad y actividad. Para el marco completo de quién actúa, con qué permiso y qué queda registrado, Identidad, permisos y auditoría de agentes IA: la capa de seguridad que necesita un teléfono desarrolla la parte de autoridad que ARD no pretende resolver.

Cómo FoneClaw separa visibilidad del catálogo y autoridad del teléfono

En FoneClaw usamos la idea de catálogo de forma práctica dentro de nuestro propio runtime Android: una capacidad puede estar visible, documentada y clasificada sin quedar automáticamente habilitada para cualquier acción. El modelo configurado ayuda a entender la petición y planificar pasos; FoneClaw invoca herramientas Android compatibles bajo controles de política, permisos, aprobación y recuperación.

La información pública de versiones de FoneClaw muestra que la versión 0.1.0 añadió gestión por herramienta, controles de aprobación, recuperación de permisos y continuidad de plugins confiables. Ese flujo mantiene separadas las herramientas integradas y los paquetes de plugin firmados: una propuesta visible puede iniciar una instalación o continuación, pero no hay instalación silenciosa por simple descubrimiento.

La instantánea pública del catálogo de herramientas de FoneClaw, fechada el 1 de agosto de 2026, contiene 118 herramientas integradas en 11 categorías con etiquetas de riesgo y aprobación. Para texto duradero preferimos decir que FoneClaw expone más de 100 herramientas integradas, porque el conteo puede evolucionar. Lo estable es el patrón: leer pantalla, abrir apps, manejar controles del sistema, comunicación, ubicación, correo, workflows, skills y plugins pasan por contratos gobernados.

Este enfoque no afirma implementación de ARD. Lo usamos aquí como comparación productiva: ARD enseña cómo descubrir recursos en la web; FoneClaw muestra cómo un runtime de teléfono debe convertir capacidades disponibles en acciones Android visibles, compatibles y controladas. Para el modelo completo de intención a acción en Android, Control del teléfono con agente de IA: qué puede hacer de verdad un phone AI agent es el siguiente paso natural.

Qué debe probar un equipo antes de adoptar un registro de recursos

La adopción de un registro de recursos para agentes debe medirse por calidad de decisión, no por número de entradas. Un buen piloto debería preguntar cuántas coincidencias son realmente útiles, cuántos catálogos están desactualizados, qué ocurre cuando falla la verificación, cómo se deniega una capacidad por política y si el usuario puede entender por qué un recurso fue rechazado.

Para equipos móviles, añadimos pruebas específicas: una coincidencia falsa no debe activar una herramienta parecida; un endpoint caído no debe provocar un fallback silencioso a otro proveedor; una capacidad nueva no debe ampliar permisos existentes sin revisión; una acción con efecto externo debe mostrar destino y resultado. Separar esas métricas permite saber si el problema está en el registro, el catálogo, el protocolo, la política local o la ejecución del teléfono.

ARD apunta a una web donde los agentes puedan encontrar capacidades con menos fricción. Para un teléfono, el diseño correcto añade una regla más: descubrir primero, autorizar después y registrar lo que ocurrió. Esa separación mantiene útil el descubrimiento sin convertirlo en autoridad implícita sobre el dispositivo.