ARD impulsa descubrimiento de recursos para agentes IA | Keryc
Agentic Resource Discovery (ARD) es una especificación abierta y federada que pone una capa de descubrimiento frente a los agentes: en vez de preinstalar herramientas, el agente puede buscar capacidades en tiempo de ejecución. La propuesta viene con participación amplia de la industria (Microsoft, Google, GoDaddy, Hugging Face y más) y está pensada como un estándar, no como un producto centralizado.
¿Qué problema resuelve ARD?
Hoy muchos agentes siguen un modelo "instalar primero, usar después": el desarrollador fija URLs, el usuario conecta plugins, y la lista de herramientas crece manualmente. ¿Qué pasa cuando el ecosistema alcanza miles de superficies ad-hoc? No escala.
La alternativa de volcar todas las descripciones dentro de la ventana de contexto del LLM tampoco es solución: la ventana tiene presupuesto limitado y las descripciones suelen ser insuficientes para desambiguar capacidades. ARD mueve la selección fuera del LLM: un registro indexa herramientas con señales ricas (identidad del publicador, consultas representativas, atestados de cumplimiento, etiquetas) y expone un endpoint REST que recibe búsquedas en lenguaje natural. El agente consulta ese registro y ejecuta lo que el motor de búsqueda devuelve. Es pasar de catálogos estáticos a búsqueda basada en intención.
¿Qué define la especificación?
La especificación ARD define principalmente dos artefactos:
Un formato de manifiesto estático: ai-catalog.json. Permite a publicadores anunciar sus capacidades en una URL conocida.
Una API de registro dinámica: POST /search. Proporciona descubrimiento en vivo y resultados ordenados por relevancia.
La idea es simple y poderosa: contratos claros (manifest + API REST) que cualquiera puede implementar y federar.
Implementación de referencia: Hugging Face Discover Tool
Hugging Face lanzó "Discover" como implementación de referencia. Convierte el Hub y sus Spaces en entradas de catálogo ARD combinando la búsqueda semántica existente con metadatos orientados a agentes.
Puntos clave de la adaptación:
La búsqueda semántica del Hub admite un flag agents=true que prioriza Spaces con metadata para agentes.
El adaptador filtra para incluir solo Spaces cuyo runtime stage sea RUNNING.
El adaptador soporta tres media types en la respuesta:
application/ai-skill: por defecto. Devuelve una versión generada tipo SKILL.md que envuelve el agents.md del Space con frontmatter (nombre, descripción, origen).
application/mcp-server+json: entrada de catálogo para servers MCP, cuando el Space está etiquetado mcp-server.
application/vnd.huggingface.space+json: metadata cruda del Space para clientes que quieran gestionarla directamente.
Cuando un Space incluye agents.md, Discover lo transforma en un skill estándar con campos como name, description y la metadata de origen (Space ID, URLs). Para Spaces etiquetados como MCP, el catálogo apunta al endpoint Gradio MCP del Space (usando el dominio runtime si está disponible o el slug .hf.space).
Ejemplos prácticos: CLI y API
Discover está integrado en la CLI de Hugging Face. Algunos comandos para probar:
Instalar la herramienta (si hace falta):
uv tool install huggingface_hub
Buscar recursos para entrenar un modelo:
hf discover search "Fine tune a language model"
Encontrar MCP Servers para generar una imagen:
hf discover search "Generate an image" --json --kind mcp
Además, cualquier cliente MCP puede apuntar al endpoint MCP de Discover en https://huggingface-hf-discover.hf.space/mcp.
Arquitectura y modos de federación
ARD separa descubrimiento y ejecución. El manifiesto está dirigido por tipos de media, lo que permite que distintos protocolos de artefactos compartan el mismo "sobre" sin cambios a nivel de especificación. La API de registro es HTTP REST, así que cualquier cliente puede federarse.
La especificación incluye modos de federación (por ejemplo auto, referrals, none) que definen cómo fluyen las búsquedas entre registros. Discover ya es una prueba funcional: no inventa un nuevo formato de artefacto, sino que envuelve el backend de búsqueda del Hub en el sobre ARD y expone Spaces como skills o MCP servers según lo que solicite el cliente.
Próximos pasos técnicos anunciados: soporte más estrecho para los modos de federación y permitir que perfiles de usuario y organización publiquen ai-catalog.json en el Hub mediante la URL well-known.
Qué significa esto para desarrolladores y empresas
Para desarrolladores de agentes: ya no necesitas preconfigurar todas las herramientas. Puedes buscar capacidades por intención y cargar lo que haga falta en tiempo de ejecución.
Para publicadores: exponer un ai-catalog.json y un agents.md aumenta la visibilidad de tus skills y MCP servers en un ecosistema federado.
Para plataformas: adoptar ARD facilita que clientes heterogéneos descubran y consuman capacidades sin integrar cada protocolo propietario.
Riesgos y consideraciones: la calidad del descubrimiento depende de metadatos, atestados de confianza y prácticas de gobernanza. Identidad del publicador, firmas, y attestations de cumplimiento serán críticos para casos sensibles.
Conclusión
ARD es un paso hacia agentes más flexibles: transforma la pregunta de "¿tengo esto instalado?" por "¿qué herramienta satisface esta intención ahora mismo?". Si trabajas con agentes, vale la pena experimentar con ai-catalog.json, exponer agents.md en tus Spaces y probar el Discover Tool para entender cómo puede integrarse en tu flujo.