Google y Hugging Face empujan ARD: el discovery que faltaba para tools, skills y agentes

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.json para 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:

1. qué registries son permitidos;
2. qué publishers son confiables;
3. qué scopes puede pedir cada recurso;
4. cuándo una conexión exige aprobación humana;
5. 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.

Demanda e intención de búsqueda

No hay SEO tooling conectado en esta corrida, así que no invento volumen. La demanda se infiere por señales actuales: Google publicó la especificación, Hugging Face lanzó una implementación de referencia y GitHub ya menciona ARD en Agent finder. Las queries Agentic Resource Discovery, ARD specification agents, ai-catalog.json, MCP tool discovery y agent registry tienen intención clara de equipos que están pasando de tools sueltas a plataformas de agentes.

Agente IA puede competir porque la cobertura en español probablemente se quedará en "nuevo estándar". El ángulo útil para builders es otro: cómo diseñar discovery sin convertirlo en una puerta trasera de permisos.

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.json con 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.