El Agent Directory de AGNTCY: discovery direccionado por contenido, sin precio

Un directorio que puede decirte qué agentes saben resumir un contrato, probar quién los publicó y escanearlos en busca de código malicioso — pero no puede decirte cuánto cuesta ninguno.

El Agent Directory Service (ADS) es la capa de discovery de AGNTCY, el proyecto que Cisco liberó en marzo de 2025 y contribuyó a la Linux Foundation el 29 de julio de 2025, con Cisco, Dell Technologies, Google Cloud, Oracle y Red Hat como miembros formativos y más de 65 empresas de apoyo.

Es el más denso en ingeniería de todos los registries de agentes. Donde el MCP Registry es una API REST sobre una base de datos y x402 Bazaar es un índice construido con tráfico de settlement, ADS es un sistema peer-to-peer: artefactos OCI direccionados por content identifier, una distributed hash table Kademlia para routing, Sigstore para provenance, SPIFFE para federación. También es aquel cuya implementación está más lejos de su propia especificación.

Leímos el draft del IETF completo, auditamos los repositorios dir y oasf en HEAD, y crawleamos el registry público de staging el 6 de agosto de 2026. Esto es lo que encontramos.

La especificación

El texto normativo vive en agntcy/dir-spec como un solo archivo, draft-mp-agntcy-ads-02, una independent submission de Luca Muscariello y Ramiz Polic, de Cisco. En el commit que auditamos (846e475, 6 de julio de 2026) el draft tiene unas 9,500 palabras. Su acompañante académico es arXiv 2509.18787, "The AGNTCY Agent Directory Service: Architecture and Implementation" (Muscariello, Pandey, Polic, enviado el 23 de septiembre de 2025).

El diseño de storage es la parte más sólida. Un record de agente es un documento OASF empaquetado como artefacto OCI, así que el directorio hereda infraestructura de container registry que no tuvo que construir: autenticación, tooling de firma, escáneres de vulnerabilidades, distribución por CDN. El manifest trae requisitos duros. artifactType MUST ser application/vnd.agntcy.dir.record.v1+json. config MUST referenciar el descriptor vacío application/vnd.oci.empty.v1+json. La capa índice 0 MUST usar application/vnd.agntcy.oasf.types.{version}.Record+json y MUST llevar su contenido inline en base64 en el campo data. Skills, domains, locators y modules se vuelven capas propias, cada una con annotations bajo claves como agntcy.oasf.skill/name. Un descriptor subject opcional apunta a un record previo, y así se expresa el historial de versiones.

Los consumidores MUST reconstruir los records bajando el manifest, decodificando la capa 0, trayendo cada blob restante, verificando su digest SHA-256 contra el descriptor, y validando el objeto fusionado contra la versión de schema OASF nombrada en las annotations. El content addressing hace el trabajo que en otros sistemas hacen las firmas: la sustitución es estructuralmente detectable, sin depender del transporte.

El discovery es un DHT de dos niveles con clave en skills

ADS separa la búsqueda de capacidades de la ubicación del contenido. El primer mapeo va de skill a content identifiers; el segundo, de content identifier a los peer IDs de libp2p que lo tienen. Los dos viven en un DHT Kademlia — la misma implementación go-libp2p-kad-dht que sostiene a IPFS. Una consulta por "agentes de natural language processing en finanzas" resuelve cada término de la taxonomía a un conjunto de CIDs, intersecta los conjuntos, luego resuelve los CIDs sobrevivientes a peers, y recién ahí baja los records por el protocolo de distribución OCI.

Una decisión de diseño gobierna todo lo demás: toda consulta MUST incluir al menos un criterio de skill. Las consultas solo por domain o solo por module están explícitamente no soportadas, porque los skills son la clave primaria del DHT. Domain y module actúan como filtros sobre un conjunto derivado de skills, no como ejes independientes.

Eso convierte a la taxonomía de skills en el muro de carga del sistema entero. Y las taxonomías se mueven.

El record tiene once campos

El schema vive en agntcy/oasf — 328 stars, publicado como v1.1.0 el 10 de julio de 2026, con schema/version.json en main marcando 1.2.0-dev. En main la taxonomía tiene 18 categorías de skills con 392 hojas, 24 categorías de domains con 165 hojas, y 12 definiciones de modules divididas en Core (language_model, prompt, agentskills, evaluation, observability) e Integration (mcp, a2a, agentspec, y un acp_manifest deprecado).

El objeto Record en sí es chico. Tiene exactamente once atributos: name, version, schema_version, description, authors, annotations, created_at, skills, domains, locators, modules. Esa lista es idéntica entre el tag v1.0.0 y main.

Esto importa porque el draft promete lo contrario. Su introducción dice que el directorio permite "evaluar características de performance incluyendo costo, latencia y requisitos de recursos", y pregunta "¿qué combinación de skills y costos optimiza para la tarea B?". Sus tres ejemplos muestran records con evaluation_data.cost_per_million_tokens: 2.50, cost_per_image: 0.05 y cost_per_problem: 0.10, junto a bloques performance_metrics, capabilities y registries. Ninguno de esos campos existe en el schema contra el que valida la implementación. Los ejemplos además usan nombres de skills y domains previos a 1.1.0 (natural_language_processing, images_computer_vision, analytical_skills, finance_and_banking) que fueron renombrados cuando se reorganizó la taxonomía.

La API de búsqueda confirma el hueco de manera independiente. El enum RecordQuery en dir soporta consultas por name, version, skill ID, skill name, locator, module, domain, author, fecha de creación, schema version, annotation, description, más VERIFIED, TRUSTED, SCAN_SEVERITY y SCAN_SAFE. No hay dimensión de costo para consultar, porque no hay costo que guardar.

Confianza: Sigstore, JWKS well-known y escáneres

La firma es keyless por defecto. El SignService — marcado explícitamente como "un servicio del lado cliente, no disponible en el servidor" — firma records a través de Fulcio y registra en Rekor usando un token OIDC, o con un archivo de llave cosign si prefieres administrar la tuya. Firmas, llaves públicas y metadata de confianza se guardan como objetos referrer de OCI adjuntos al record.

El naming es donde ADS está calladamente adelante de sus pares. Los records pueden llevar un nombre como cisco.com/agent, y un scheduler del backend verifica que la llave de firma del record esté autorizada por ese dominio bajando https://<dominio>/.well-known/jwks.json (RFC 7517) y comparando identificadores de llave. La resolución acepta referencias estilo Docker: name para todas las versiones de más nueva a más vieja, name:version, name@cid, o name:version@cid para un lookup verificado por hash. Es el mismo truco que usa el MCP Registry para namespaces DNS y Web Bot Auth para su directorio de firmas — un dominio que ya controlas se vuelve el ancla de identidad, sin autoridad de registro en el medio. Escribimos sobre ese patrón en Web Bot Auth.

La tercera capa de confianza es el escaneo, y está viva. Los records de la red pública llevan referrers agntcy.dir.security.v1.ScanReport. Uno que bajamos al azar fue producido el 22 de julio de 2026 por SCANNER_TYPE_SKILL versión 2.0.11, corriendo analizadores behavioral, bytecode, pipeline, static y trigger, devolviendo isSafe: true con un único hallazgo informativo: MANIFEST_MISSING_LICENSE. Los records de agentes se tratan como artefactos de supply chain, que es el instinto correcto.

Qué contiene realmente la red pública

AGNTCY opera una red pública de staging en ads.outshift.io: una API gRPC detrás de un gateway OIDC, un issuer Dex en idp.ads.outshift.io, un endpoint de bundle de SPIRE en spire.ads.outshift.io, y un registry OCI en store.ads.outshift.io. Unirse no es un signup. Según la guía de onboarding de dir-staging, tienes que correr tu propio servidor SPIRE, federar su trust domain con el de ellos usando el perfil de bundle https_web, y exponer cuatro nombres DNS públicos con certificados de Let's Encrypt detrás de un ingress controller. "La federación es requerida antes de poder descubrir o publicar agentes".

El registry OCI, sin embargo, es de lectura pública. El 6 de agosto de 2026 lo crawleamos.

# toda la red pública es un solo repositorio
$ curl -s https://store.ads.outshift.io/v2/_catalog
{"repositories":["dir"]}

# los tags son CIDv1 en base32; paginados de a 1,000
$ while more; do curl -s ".../v2/dir/tags/list?n=1000&last=$last"; done
9814 tags

# muestra aleatoria de 600 manifests, clasificados por annotation
ScanReport   345
record       116
Signature     74
PublicKey     65

Extrapolar la proporción de records de esa muestra al total de tags da unos 1,900 records de agentes en el directorio público. Todos los records muestreados declaraban org.agntcy.dir/oasf-version: 1.0.0.

Después leímos 60 de esos records completos. Cuarenta y cinco llevaban el módulo core/language_model/agentskills y quince llevaban integration/mcp. Los autores eran GitHub, Microsoft (escrito tanto Microsoft como microsoft), NVIDIA, Anthropic, Google, RedHatInsights y arm. Es decir: el directorio público es sobre todo agent skills y descriptores de servidores MCP importados desde repositorios de vendors, no agentes que se registraron a sí mismos.

Dos números de esa lectura merecen quedarse un rato. Solo 15 de 60 records llevaban locator — tres cuartos de la muestra describen una capacidad sin ninguna dirección donde invocarla. Y el skill más común fue retrieval_augmented_generation/retrieval_of_information, presente en 36 de 60 records. Esa hoja ya no existe en OASF actual: v1.0.0 tenía 15 categorías de skills de primer nivel incluyendo retrieval_augmented_generation; main tiene 18, con RAG degradado a ai_ml_engineering/retrieval_augmented_generation y retrieval_of_information eliminado por completo. La clave de índice más usada de la red viva no está en la taxonomía actual. Para un DHT cuya clave primaria es el nombre del skill y cuyas consultas están obligadas a incluir uno, eso no es un problema cosmético.

La spec y la red que corre no coinciden

Todos los manifests no-referrer que bajamos se veían así:

{
  "artifactType": "application/vnd.oci.image.manifest.v1+json",
  "layers": [{ "mediaType": "application/json", "size": 7030 }],
  "annotations": {
    "org.agntcy.dir/type": "record",
    "org.agntcy.dir/name": "github-actions-efficiency",
    "org.agntcy.dir/oasf-version": "1.0.0"
  }
}

Compáralo con el draft: artifactType MUST ser application/vnd.agntcy.dir.record.v1+json, la capa 0 MUST ser un media type OASF tipado con data inline en base64, y skills, domains y locators MUST ser capas separadas con annotations. La red desplegada no hace nada de eso. Guarda un único blob JSON opaco y pone la metadata buscable en annotations org.agntcy.dir/*. Parte del hueco es desfase de versiones — dir-staging fija el servidor en v1.3.0 mientras el repositorio va por v1.6.2 (29 de julio de 2026) — pero la especificación de artefactos es la parte del draft con más cláusulas MUST, y nada en producción la respeta.

Hay un segundo hueco, más silencioso. Lo que se agregó al draft en julio de 2026 es una sección de interoperabilidad con AI Catalog, un sobre de discovery delgado mantenido por el Agent Card Working Group bajo la Linux Foundation y todavía marcado como documento draft. ADS proyecta records a entradas de catálogo según sus modules: integration/mcp se vuelve application/mcp-server-card+json, integration/a2a se vuelve application/a2a-agent-card+json, agentskills se vuelve application/agentskill+md, y un record con dos o más modules conocidos se vuelve un catálogo anidado. Los records sin ningún module conocido no son proyectables.

Pero las formas no encajan. La entrada de AI Catalog requiere identifier, type, y exactamente uno de url o data, con displayName opcional e identificadores recomendados en forma urn:air. El draft de ADS y el protobuf de dir requieren identifier, display_name y media_type — un campo que la especificación destino llama type — y emiten identificadores como urn:ai:org.agntcy:cid:<cid>, verificado en los propios tests de catálogo del repositorio. Una capa de interoperabilidad cuyos campos requeridos difieren de la especificación con la que interopera va a interoperar con exactamente una implementación.

Y la superficie de discovery que los clientes genéricos deberían usar está cerrada. GET /.well-known/ai-catalog.json en el host público devuelve 401 {"error": "Unauthenticated", "message": "missing credentials"}, igual que /v1/agents. Un well-known URI detrás de autenticación es una contradicción en sus términos.

Todavía no hay red global

Una línea en server/routing/config/config.go en HEAD (a37aba3, 5 de agosto de 2026) explica más que cualquier diagrama de arquitectura:

var DefaultBootstrapPeers = []string{
    // TODO: once we deploy our bootstrap nodes, we should update this
}

Dieciocho meses después de creado el repositorio y seis releases menores más tarde, un nodo nuevo no se une a ninguna red por defecto. El autosync está apagado por defecto bajo una política explícita de deny-by-default, y el servicio de relay está apagado salvo que seas alcanzable públicamente. La maquinaria Kademlia es real y está testeada, pero la "Internet of Agents" hoy es un conjunto de overlays privados más una instancia de staging operada por Cisco a la que entras federando un trust domain de SPIFFE.

Es una decisión empresarial defendible — es esencialmente el modelo que describimos en el artículo sobre enterprise-managed authorization, donde el identity provider corporativo decide quién entra. Simplemente no es el discovery permissionless que sugiere el framing.

Qué significa para LLM4Agents

ADS responde una pregunta que nuestro stack no responde: dada una capacidad, qué agentes dicen tenerla, quién responde por ellos, y si alguien los escaneó. Content addressing más Sigstore más nombres verificados por dominio es una historia de provenance mejor que cualquier cosa en el MCP Registry, y el referrer de scan report es una idea genuinamente buena que deberíamos copiar en espíritu.

Lo que no responde es la pregunta que hace usable a un agente para otro agente sin humano en el medio: cuánto cuesta una llamada y cómo la pago. La palabra x402 aparece cero veces en el draft. La aplicación de referencia insignia, coffeeAgntcy, incluye un servidor MCP de pagos cuya tool create_payment devuelve un "payment_id": "stub_payment_id" hardcodeado por $100.00 USD, con un comentario que aclara que un sistema real debería aplicar control de acceso. No hay stablecoins en ninguna parte del repositorio.

Es la misma forma que encontramos en el Universal Commerce Protocol: una capa de negociación y discovery bien construida con el rail de settlement dejado como problema de otro. Y es la misma conclusión a la que llegamos auditando ERC-8004 — una entrada de directorio es una afirmación, y las afirmaciones sin anclaje económico derivan hacia el ruido. Que tres cuartos de los records de la red pública no tengan locator es esa deriva, medida.

En concreto: ADS es un buen lugar para estar listado y un mal lugar para facturar. Se ubica por encima de nuestro gateway como catálogo empresarial, no como reemplazo del camino de settlement. El record es deliberadamente delgado, el mapa de annotations es libre, y el sistema de modules es el punto de extensión diseñado — así que el precio faltante es una apertura, no un muro.

Cómo mantenerse en la frontera

En orden, de lo más barato a lo más ambicioso.

Publicar un record firmado. Construir un record OASF para el servidor MCP de LLM4Agents con un módulo integration/mcp y un locator real, firmarlo keyless con Fulcio y Rekor, y reclamar el nombre llm4agents.com/gateway sirviendo /.well-known/jwks.json. El naming verificado por dominio cuesta un archivo estático y nos pone en la minoría de records que son a la vez direccionables y atribuibles.

Llevar el precio en annotations. Hasta que OASF tenga campo monetario, publicar el pricing bajo un namespace de annotations en DNS inverso (com.llm4agents.x402.accepts) que replique textualmente el objeto accepts de x402, para que un cliente que ya habla x402 pueda pagar directo desde la entrada del directorio sin un round trip extra de discovery.

Servir nuestro propio catálogo. Publicar /.well-known/ai-catalog.json en nuestro dominio, sin autenticación, listando el gateway y cada tool MCP paga. Es un documento chico, es el sobre de interoperabilidad al que convergieron tanto el Agent Card WG como ADS, y publicarlo abierto es un diferenciador frente a una red pública que devuelve 401 en esa misma ruta.

Proponer el módulo de pago upstream. Los modules son la forma en que OASF se extiende. Un módulo integration/x402 — payment requirements, redes aceptadas, scheme de precio — es la contribución correcta, y la misma jugada que señalamos para la gobernanza abierta de UCP. Las capas de discovery que no pueden expresar precio van a seguir empujando la pregunta hacia el settlement de todos modos; mejor definirlo una vez.

Fijar la taxonomía. Publiquemos lo que publiquemos, registrar de qué versión de OASF vino cada identificador de skill y republicar ante cada rename. La eliminación de retrieval_of_information muestra qué pasa si no: una clave de índice que ya no existe, en un sistema donde la clave de índice es obligatoria.

Y después medir. Correr un nodo DIR privado contra nuestro propio conjunto de bootstrap, cargar nuestro catálogo más los records del staging público, y comparar latencia y recall de consultas por capacidad contra un crawl directo del MCP Registry. Si el DHT no le gana a un índice hosteado a nuestra escala, aprendimos algo barato; si le gana, ya tenemos el formato de record y el pipeline de firma listos.