AWS respalda Agentic Resource Discovery como capa de federación para Agent Registry

Amazon Web Services ha respaldado la especificación Agentic Resource Discovery, publicando un informe detallado el 24 de agosto de 2026 sobre cómo se espera que el estándar abierto funcione junto a AWS Agent Registry, su catálogo gestionado de agentes de IA, herramientas y habilidades que entró en vista previa a principios de este año.

La publicación de AWS presenta ARD como la respuesta a un problema que deja abierto el propio producto de AWS. AWS Agent Registry, disponible a través de Amazon Bedrock AgentCore, brinda a una organización un catálogo centralizado y buscable de agentes, servidores MCP, herramientas, habilidades de agentes y recursos personalizados, pero solo dentro de su propio entorno de AWS. La mayoría de las empresas ejecutan agentes en múltiples nubes, infraestructuras locales y plataformas SaaS, cada una con su propio registro y formato de metadatos, y conectar esos entornos hoy implica crear conectores a medida entre cada par de registros.

ARD propone la alternativa de formato compartido: si cada registro describe los recursos de la misma manera y expone el descubrimiento a través de un protocolo común, los publicadores describen sus recursos una sola vez y los consumidores los descubren en todas partes.

Dentro del modelo de AWS Agent Registry

El registro, actualmente en vista previa a través de Amazon Bedrock AgentCore, se construye alrededor de dos conceptos: registros, que son catálogos que un administrador crea con sus propias configuraciones de autorización y aprobación, y entradas, los metadatos que describen cada recurso. El flujo de publicación pasa de administrador a publicador, a curador y a consumidor, con una puerta de aprobación antes de que cualquier entrada sea descubrible. El acceso se controla mediante credenciales de AWS Identity and Access Management o JSON Web Tokens de un proveedor de identidad corporativo, y el propio registro se expone como un punto final remoto MCP, de modo que cualquier cliente compatible con MCP pueda buscarlo directamente.

Esa capa de gobernanza es la parte que AWS se esfuerza por preservar. En la publicación, AWS describe ARD como una capa de interoperabilidad que se sitúa fuera del punto de aplicación: la organización que publica un catálogo controla lo que contiene, quién puede verlo y cuándo revocar el acceso, mientras que los controles de aprobación y acceso existentes de Agent Registry permanecen donde la política se aplica realmente. El lenguaje es deliberado: ARD se encarga de encontrar cosas, no de confiar en ellas para producción.

Qué estandariza realmente la especificación ARD

ARD no es un proyecto de AWS. La especificación se anunció el 17 de junio de 2026 por un grupo de trabajo cuyos participantes incluyen a Google, Microsoft, Hugging Face y GoDaddy, con Cisco, Databricks, GitHub, NVIDIA, Salesforce, ServiceNow y Snowflake entre los colaboradores del lanzamiento. Está licenciada bajo Apache 2.0 y publicada en agenticresourcediscovery.org, con implementaciones de referencia en GitHub. AWS aportó comentarios durante el desarrollo en lugar de redactar la especificación.

Según el anuncio de Google, la arquitectura se basa en dos primitivas. Un catálogo es un archivo que una organización publica bajo su propio dominio (un ai-catalog.json en una ruta bien conocida) describiendo sus agentes disponibles, servidores MCP, agentes A2A, herramientas OpenAPI o catálogos anidados, y la propiedad del dominio sirve como base criptográfica para la identidad del publicador. Los registros actúan como motores de búsqueda sobre esos catálogos: rastrean, indexan y responden a solicitudes de descubrimiento en lenguaje natural, devolviendo coincidencias junto con los metadatos de confianza verificables que un cliente necesita para confirmar la identidad del publicador antes de conectarse.

El límite que traza ARD es el descubrimiento, no la ejecución. Un cliente que encuentra un recurso a través de ARD lo invoca mediante cualquier mecanismo que el recurso soporte de forma nativa: MCP, una API, un marco de agentes. El propio sitio de la especificación deja claro que ARD no es un tiempo de ejecución, no reemplaza a MCP ni al protocolo A2A, y no es un catálogo central; el diseño asume muchos servicios de descubrimiento, cada uno aplicando sus propias políticas de confianza y clasificación. La analogía de AWS es DNS: los registros locales se federan mediante el protocolo compartido sin acuerdos bilaterales ni conectores propietarios, al igual que la resolución de nombres funciona en redes.

Cómo encajan las piezas

Para los clientes de Agent Registry, la propuesta es federación sin migración. Una organización con infraestructura agentic distribuida entre nubes, sistemas locales y herramientas SaaS podría exponer todo en el formato de ARD y hacerlo descubrible en todos los entornos mientras mantiene el control local, y podría publicar un catálogo en su propio dominio para que lo descubra cualquier cliente compatible con ARD, abriendo rutas interorganizacionales que un registro de un solo proveedor no puede alcanzar.

AWS también llega con el producto listo mientras otros aún están construyéndolo. El propio Agent Registry de Google, parte de su Gemini Enterprise Agent Platform, está programado para añadir soporte nativo de ARD en los próximos meses; GitHub y Hugging Face están entre los participantes del grupo de trabajo detrás de la especificación. El patrón en las tres nubes es el mismo: un registro gestionado y gobernado en el interior, y un protocolo de federación abierto en el exterior.

La advertencia es que la integración descrita en la publicación de AWS es direccional, no está disponible. AWS indica lo que espera que ARD habilite para los clientes de Agent Registry en lugar de anunciar una fecha de entrega, y el registro sigue en vista previa. Lo que el 24 de agosto de 2026 establece es alineación: el mayor proveedor de nube ha nombrado la especificación abierta con la que pretende federarse, y es la misma que Google y Microsoft están construyendo.