Ahora mismo, la mayoría de los agentes de IA usan solo las herramientas que una persona les dio. Alguien escribe una lista de servidores y API, la pega en un archivo de configuración y el agente trabaja dentro de esa pequeña caja. No puede ir a buscar una herramienta mejor. Agentic Resource Discovery (ARD) intenta arreglarlo.

¿Qué es Agentic Resource Discovery?

ARD es una especificación sobre cómo los agentes de IA encuentran herramientas externas, API, skills y otros agentes. A finales de mayo de 2026 se publicó un borrador v0.9. Google lo anunció con socios, y entre los colaboradores citados figuran Microsoft, GitHub, Hugging Face, Cisco, Databricks, Nvidia, Salesforce, ServiceNow y Snowflake. Usa la licencia Apache 2.0 y se basa en el modelo de datos AI Catalog de un grupo de trabajo de la Linux Foundation.

En ARD, un recurso es cualquier cosa que un agente pueda querer usar: un servidor MCP, un agente A2A, una skill, una API o un archivo de conocimiento.

Una buena comparación son los inicios de la búsqueda en la web. Antes de los buscadores, había que conocer la dirección de un sitio. Luego la búsqueda permitió escribir lo que necesitabas y obtener una lista de lugares que ayudan. ARD intenta lo mismo para los agentes. El agente pregunta “¿Qué herramienta puede leer esta base de datos?” y obtiene opciones reales.

• Los publicadores enumeran lo que ofrecen en un archivo de catálogo.
• Los registros reúnen esos archivos y los hacen buscables.
• Los agentes buscan, comprueban la confianza y se conectan.

Por qué los agentes necesitan descubrimiento

1. No escala. La descripción de cada herramienta debe caber en la ventana de contexto del modelo antes de que pueda elegir. Con miles de herramientas, las descripciones por sí solas agotan el espacio pensado para la tarea real.
2. Las listas se quedan obsoletas. Aparecen herramientas nuevas cada semana, y una lista fija es vieja el día que la guardas.
3. Limita al agente. Un agente que no puede mirar más allá de su lista nunca encontrará una herramienta mejor.

ARD saca el paso de elegir del modelo y lo lleva a un servicio de búsqueda, para que el modelo se concentre en la tarea. Encaja con la idea de la “web agéntica”, donde los agentes de software hacen tareas para las personas y hablan directamente con los servicios. ARD cubre el encontrar y el confiar. MCP y A2A gestionan la conversación en sí. También combina bien con WebMCP, que ayuda a los agentes a usar herramientas dentro de una página web.

Cómo funciona ARD en cuatro pasos

1. Publicar: una empresa crea ai-catalog.json y lo aloja en su propio dominio.
2. Descubrir: los registros rastrean e indexan los catálogos. Un agente envía una búsqueda que describe su tarea.
3. Verificar: el agente o su anfitrión comprueba quién publicó el resultado. En un nivel básico, significa que el publicador controla el dominio. En un nivel más fuerte, significa comprobar datos de confianza firmados.
4. Conectar: el agente se conecta de la forma normal, mediante MCP, A2A o una API. ARD nunca se interpone en la llamada.

Los bloques de construcción

¿Qué es ai-catalog.json?

Es un archivo legible por máquinas que dice a los agentes y registros lo que ofrece un dominio. Piensa en él como el robots.txt de las capacidades: en lugar de decir qué no pueden tocar los rastreadores, dice qué pueden usar los agentes. Vive en una ruta conocida (RFC 8615):

https://your-domain.com/.well-known/ai-catalog.json

Un catálogo tiene tres partes obligatorias: una versión de la especificación, un objeto host que nombra al publicador y un array entries. Este es un ejemplo simplificado, así que consulta la última especificación para ver las reglas exactas:

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Example Dev Tools",
    "identifier": "did:web:example.com"
  },
  "entries": [
    {
      "identifier": "urn:ai:example.com:server:invoice-lookup",
      "displayName": "Invoice Lookup Server",
      "type": "application/mcp-server+json",
      "url": "https://api.example.com/mcp/invoices.json",
      "description": "Busca y resume las facturas de los clientes.",
      "representativeQueries": [
        "busca la última factura de un cliente",
        "muestra las facturas impagadas del mes pasado"
      ]
    }
  ]
}

• identifier es una URN única del recurso.
• type es un tipo de medio que indica al cliente qué clase de recurso es.
• url apunta a la descripción propia del recurso (una entrada usa una URL o datos en línea).
• representativeQueries son solicitudes de ejemplo que un usuario podría hacer. Ayudan a los registros a emparejar las búsquedas.

Este es un breve script de Python que lee un catálogo público. Lee los campos con .get() para que un cambio futuro no lo rompa:

import requests

url = "https://huggingface.co/.well-known/ai-catalog.json"
resp = requests.get(url, timeout=10)
resp.raise_for_status()

for entry in resp.json().get("entries", []):
    print(entry.get("displayName"), "-", entry.get("type"))

¿Nuevo en Python? Empieza con nuestro tutorial de Python.

Cómo buscan los agentes en un registro

Leer miles de catálogos no ayudaría a un agente, así que los registros hacen el trabajo. Un registro indexa descripciones y consultas de ejemplo y luego ordena los resultados según la solicitud del agente. Muchos usan búsqueda vectorial, que empareja por significado y no por palabras exactas. Así, “convierte este PDF en texto” puede encontrar una herramienta descrita como “extracción de documentos”. El lanzamiento de Hugging Face también menciona modos de federación (auto, referrals, none) que describen cómo un registro puede pasar una búsqueda a otros.

Qué puede descubrir ARD

• Servidores MCP: un agente que hace pruebas de navegador podría encontrar un servidor como el de nuestra guía de Playwright MCP. Para el diseño de servidores, consulta la arquitectura MCP sin estado.
• Agentes A2A: los catálogos pueden apuntar a tarjetas de agente, de modo que un agente encuentre a otro que sea bueno en un trabajo.
• Skills: instrucciones empaquetadas que enseñan a un agente un tipo de trabajo.
• API: API simples, a menudo descritas con OpenAPI. Los buenos hábitos, como las pruebas de API, importan más cuando los agentes las llaman solos.

ARD vs otros métodos de descubrimiento

Seguridad y confianza

Un agente que encuentra y usa herramientas nuevas por su cuenta es poderoso y arriesgado.

• Verificación del publicador: un catálogo servido desde example.com lo publicó quien controla example.com. Esa es una raíz de confianza básica.
• Identidad criptográfica: la especificación describe datos de confianza firmados para comprobaciones más fuertes.
• Confianza opcional: en el borrador actual, los datos de confianza son opcionales, y el registro o el cliente decide en qué confiar. ARD da señales, pero no obliga a nadie a comprobarlas.
• Recursos maliciosos: cualquiera puede alojar un catálogo. Una herramienta dañina puede describirse con palabras amables. Y si un agente que lee contenido no fiable también puede encontrar y llamar a herramientas nuevas a mitad de una tarea, un texto oculto podría dirigirlo hacia una mala.

Casos de uso

• Agentes empresariales: un registro interno limitado a recursos aprobados.
• Agentes de desarrollo y QA: encuentran la herramienta de navegador o de API adecuada por proyecto. Consulta la IA en la automatización de pruebas.
• Sistemas multiagente: un coordinador encuentra el mejor agente para cada subtarea.
• Comercio agéntico: servicios de reservas, pagos e inventario entre empresas, que necesitan una verificación fuerte porque hay dinero de por medio.
• Descubrimiento entre organizaciones: dos empresas que nunca se han conocido pueden dejar que sus agentes se encuentren y se verifiquen entre sí.

Cómo publicar tu primer catálogo

1. Enumera los servidores, agentes o API que quieres que los agentes encuentren.
2. Escribe una descripción clara de cada uno, más dos o tres representativeQueries.
3. Crea ai-catalog.json siguiendo la especificación.
4. Valídalo con un breve script que compruebe los campos obligatorios.
5. Alójalo en /.well-known/ai-catalog.json mediante HTTPS como JSON.
6. Guárdalo en Git (tutorial de Git) y valídalo en GitHub Actions.
7. Añade datos de confianza firmados cuando puedas.

Límites de ARD hoy

• Estado de borrador: es una propuesta v0.9. Los campos y las reglas pueden cambiar.
• Adopción: un registro solo es útil si se usa ampliamente. Google dijo que el soporte nativo en su registro de agentes llegaría en los meses posteriores al lanzamiento. Busca noticias más recientes.
• Confianza: “publicador verificado” puede significar solo “controla el dominio”, y una búsqueda entre registros puede heredar las reglas del registro más débil.
• Tipos de medio: algunos registros de tipos de MCP y A2A seguían pendientes.
• ¿Lo necesitas? Si usas menos de unas veinte herramientas que rara vez cambian, una configuración sencilla con lista de permitidos es más segura y simple.

Preguntas frecuentes

Sigue aprendiendo