Google y Hugging Face empujan ARD: el discovery que faltaba para tools, skills y agentes
Google anunció el 17 de junio de 2026 la especificación Agentic Resource Discovery, y Hugging Face publicó una implementación de referencia. Para builders, la noticia no es otro catálogo: es mover el descubrimiento de capacidades fuera del prompt y volverlo verificable.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Google publicó el 17 de junio de 2026 la especificación Agentic Resource Discovery, o ARD, con una idea que apunta directo a un problema real de los agentes: si cada tool, skill, MCP server o agente se instala a mano, el contexto se llena, el inventario envejece y nadie sabe qué capacidad es confiable para una tarea concreta.
La propuesta no intenta reemplazar MCP ni A2A. Intenta resolver la capa anterior: cómo descubre un agente qué capacidad existe, quién la publicó, qué permisos pide y por qué debería confiar en ella. Hugging Face reforzó la señal el mismo día con una implementación de referencia que expone Skills, Spaces y MCP servers mediante búsqueda compatible con ARD.
El cambio importante: buscar capacidades, no pegarlas al prompt
Hasta ahora, muchos equipos han tratado discovery como configuración local: un archivo con servidores MCP, una lista de tools, instrucciones largas y quizá un marketplace. Eso funciona cuando tienes cinco capacidades. Se rompe cuando tienes cincuenta.
ARD separa tres capas:
- un manifiesto estático
ai-catalog.jsonpara publicar capacidades en un dominio; - una API dinámica de búsqueda para encontrar recursos por intención;
- metadatos de confianza, publisher, tags, compliance y ejemplos de consultas.
La lectura práctica es simple: el agente no tiene que cargar todo el catálogo en contexto. Puede buscar justo lo que necesita, recibir resultados estructurados y dejar que el cliente o la organización decida qué se conecta.
Hugging Face lo vuelve más concreto
El post de Hugging Face aterriza ARD con hf discover, una herramienta que puede buscar Skills, aplicaciones ML y MCP servers. Su implementación combina búsqueda semántica sobre Spaces con metadata orientada a agentes y devuelve entradas compatibles con ARD.
Ese detalle importa porque ARD no se queda como PDF de estándar. Ya tiene una ruta visible para builders: publicar capacidades, consultarlas desde CLI, exponer un endpoint REST o envolver Spaces como Skills consumibles por clientes compatibles.
Dónde puede salir mal
Discovery dinámico no elimina gobernanza. La vuelve más urgente.
Si tu agente puede encontrar tools nuevas, necesitas decidir:
- qué registries son permitidos;
- qué publishers son confiables;
- qué scopes puede pedir cada recurso;
- cuándo una conexión exige aprobación humana;
- cómo auditas qué recurso sugirió y usó el agente.
La peor versión de ARD sería "el agente encontró algo y lo conectó". La versión útil es más parecida a un buscador con allowlists, reputación, revisión y logs.
Qué haría esta semana
Para un equipo que ya tiene agentes internos, yo no empezaría conectando todo. Haría un piloto pequeño:
- publicar un
ai-catalog.jsoncon tres tools internas; - crear metadata mínima de owner, scopes y casos de uso;
- probar búsqueda desde un cliente controlado;
- registrar cada sugerencia y cada conexión;
- revisar si el agente elige mejor que una lista fija de tools.
Si todavía estás armando la base de tools y contratos, empieza por el curso gratis. La conclusión de ARD es clara: el futuro de los agentes no será solo tener más herramientas, sino encontrarlas con evidencia y conectarlas con control.