Auditoría de NANDA: 13.605 agentes declarados, 350 accesibles

Project NANDA, del MIT, se presenta como el DNS de la internet de agentes IA. Crawleamos su index público el 19 de agosto de 2026. El contador dice 13.605 agentes. La API no te entrega más de 350.

Toda capa de discovery para agentes hace las mismas tres promesas: te decimos quién existe, te decimos qué sabe hacer, y vas a poder verificar ambas cosas. NANDA las hace más fuerte que la mayoría. Viene del MIT Media Lab, tiene papers, tiene un index público en index.projectnanda.org, y su pitch es explícitamente un reemplazo de DNS.

Ya auditamos registries de discovery antes: el Agent Directory Service de AGNTCY en el mundo de los artefactos OCI, y los registries de ERC-8004 on-chain. El método es siempre el mismo: leer qué obliga la spec y después medir qué sirve producción. NANDA es el tercero. También es donde la brecha entre ambas cosas es más ancha.

Qué promete NANDA

El paper fundacional es "Beyond DNS: Unlocking the Internet of AI Agents via the NANDA Index and Verified AgentFacts", enviado el 18 de julio de 2025 por Ramesh Raskar y diecisiete coautores. Su abstract compromete cinco garantías: un index tipo quilt que cubre agentes NANDA-native y de terceros, resolución global rápida para agentes recién creados, revocación y rotación de claves sub-segundo, aserciones de capacidad validadas por schema, y discovery privacy-preserving entre organizaciones mediante queries verificables de mínima divulgación. Formaliza el schema AgentFacts, especifica un protocolo de actualización basado en CRDT y prototipa resolvers adaptativos.

La documentación del proyecto comprime eso en una tabla comparativa contra DNS. Donde DNS tarda minutos u horas en propagar, NANDA ofrece "sub-second global resolution". Donde DNS "solo prueba propiedad del dominio", NANDA ofrece "cryptographically signed capabilities". Donde DNS "expone los patrones de lookup", NANDA ofrece "privacy-preserving resolution".

Son afirmaciones testeables. Así que las testeamos.

Hallazgo 1: el index reporta 13.605 agentes y sirve 350

El endpoint de listado es GET /api/agents. Devuelve un array agents y un objeto pagination. Ese objeto no es ambiguo:

{"page": 1, "limit": 100, "total": 13605,
 "totalPages": 137, "hasNext": true, "hasPrev": false}

Recorrimos las 137 páginas con limit=100. El recorrido devolvió 7.100 filas con 300 valores id distintos. Las páginas 1 a 5 traían 50 registros nuevos cada una más el mismo conjunto fijo de 50; desde la página 6 en adelante, cada página devolvió solo ese conjunto fijo de 50. La página 137, la 200 y la 500 devuelven payloads idénticos byte a byte.

Cambiar el tamaño de página no ayuda. Con limit=200 el servidor recorta silenciosamente la respuesta a 150 filas, y 20 páginas de recorrido dan 250 registros distintos. Uniendo ambos crawls, el máximo que pudimos recuperar fueron 350 agentes distintos. Cada respuesta seguía insistiendo en que el total era 13.605.

No hay una segunda puerta. GET /api/agents/<id> devuelve {"success":false,"error":"Agent not found"} con ids copiados textualmente del listado — probamos uno de cada una de las cuatro categorías, los cuatro dieron 404. El parámetro ?search= se acepta y se ignora; igual ?category=; igual ?q=. Los tres devuelven la misma primera página que un request pelado.

Así que el estado práctico de la "guía telefónica de la internet de agentes IA" es este: un contador que reporta cinco cifras, un listado que devuelve tres, y ninguna forma de buscar un nombre.

Hallazgo 2: qué son realmente los registros alcanzables

Los 350 registros que pudimos alcanzar se reparten en 250 de categoría skill, 50 mcp, 25 persona y 25 communication. Su campo status mezcla dos vocabularios que nunca se encuentran: 264 online y 36 offline de un lado, 33 unverified y 17 verified del otro. Un campo, dos significados ortogonales, sin discriminador.

Los hosts de los endpoints dicen más que los conteos. Sesenta registros apuntan a un único deploy de Railway, bayarea-agent-production.up.railway.app. Otros 111 apuntan a cuatro apps más de Railway llamadas test-london-chapter, test-bangalore-chapter, test-boston-chapter y test-tokyo-chapter. Cinco registros publican localhost como endpoint. Uno publica una IPv4 pelada. El campo lastSeen — formateado como 8/2/2026, un string dependiente de locale y no un timestamp — es idéntico en 185 de los 350.

Veintitrés registros embeben un objeto de metadata completo inline, y esos objetos traen _id, __v y userId: internals crudos de documentos MongoDB, incluido el identificador de usuario del dueño, proyectados directo a una respuesta de API pública.

Hallazgo 3: 193 de 264 documentos AgentFacts dan 404

AgentFacts es la capa que debería hacer todo esto confiable. Cada registro del index puede llevar un factsUrl que apunta a un documento JSON self-hosted describiendo al agente. De nuestros 350 registros, 264 publican uno y 86 no publican ninguno.

Bajamos los 264, una vez, con timeout de 15 segundos. Cincuenta y siete respondieron HTTP 200. Ciento noventa y tres devolvieron 404. Nueve fallaron la validación TLS, cuatro rechazaron la conexión, uno ya no resuelve en DNS. Cincuenta y seis de las 57 respuestas vivas parsearon como JSON.

Después las validamos contra el schema publicado. agentfacts-format/agentfacts_schema.json es un JSON Schema draft-07 con $id: https://agentfacts.org/schema/v1, quince propiedades top-level y nueve de ellas requeridas: id, agent_name, label, description, version, provider, endpoints, capabilities, skills. Cincuenta y uno de los 56 documentos vivos traen las nueve. Es el único número de esta auditoría que se ve sano.

El último commit del schema es del 17 de junio de 2025. No se tocó desde entonces.

Hallazgo 4: nadie firma, y tres agentes se pusieron precio igual

Busca en el schema signature, proof, jws o cualquier material de clave: no hay nada. AgentFacts, tal como está publicado, no tiene dónde poner una firma. Coherente con eso, cero de los 56 documentos vivos llevan un campo de firma de ningún tipo. "Cryptographically signed capabilities" es, en el corpus desplegado que medimos, una propiedad que no existe.

Lo que el corpus sí tiene es improvisación. Cuarenta y siete documentos llevan un objeto chapter y un bloque attestation que el schema nunca define — attested_by como did:key, un facts_digest tipo sha256:…, un string lifecycle y un booleano revoked. Treinta y cuatro van más lejos con verifiable_receipts: URI de ledger, behavioral_merkle_root, conteo de recibos, score de reputación y un método de scoring autodeclarado nanda-rep/0.2, servido bajo el media type application/vnd.nanda.receipts-ledger+json. La mitad de la capa de confianza que describen los papers la reinventó un solo operador, en JSON libre, fuera del schema.

Ahora busca en el schema price, payment, cost o fee. Tampoco hay nada. Quince propiedades, y ninguna puede decir cuánto cuesta una llamada. Es el mismo hueco que encontramos en el record OASF de AGNTCY: una capa de discovery cuyo modelo de objetos no tiene dimensión económica alguna.

Tres agentes del index lo llenaron por su cuenta.

Tres operadores independientes, tres formas incompatibles, una conclusión compartida: una entrada de directorio que no puede decir cuánto cuesta una llamada está incompleta, y la parchean localmente en vez de esperar.

Hallazgo 5: el index v2 es otro sistema

Mientras index.projectnanda.org sirve el corpus de arriba, un segundo index se construyó y desplegó en silencio. github.com/projnanda/nanda-index-v2 es un servicio Fastify + PostgreSQL, Apache-2.0 desde el 20 de julio de 2026, 74 commits, seis contribuyentes, último commit del 29 de julio de 2026. Está vivo: https://api.nandaindex.org/health responde {"status":"ok","db":"ok"} y su documento OpenAPI lo identifica como "NANDA Index Server" versión 2.0.0, descrito como "GARR v2".

El diseño es un repudio de v1. El README lo dice sin vueltas: "NANDA Index does not host agents. It tells you where to find them." Un index record por organización, tres saltos — requester al index, index al registry o card host, card host al runtime — y un vocabulario fijo de seis media types: application/ai-catalog+json, application/vnd.ans-registry+json, application/vnd.dns-aid+json, application/a2a-agent-card+json, application/mcp-server-card+json, application/agentskill+zip. AgentFacts no está entre ellos. El index ya no resuelve a AgentFacts: resuelve a A2A Agent Cards, MCP server cards y entradas de AI Catalog.

Leímos la tabla entera. GET /api/v1/index ignora limit y offset — toda variante devuelve el mismo array — y ese array tiene 251 registros, todos active, creados entre el 17 de junio y el 5 de agosto de 2026. Por media type: 177 agentskill+zip, 32 ai-catalog+json, 20 mcp-server-card+json, 18 a2a-agent-card+json, 4 vnd.dns-aid+json.

Las URLs de registry son lo interesante. Ciento ochenta de los 251 registros apuntan a ai-catalog.outshift.io — el host público del catálogo de AGNTCY, el mismo que crawleamos para la auditoría de ADS. Sus identificadores son direcciones de contenido urn:ai:org.agntcy:cid:… y sus tags son rutas de skills de OASF 1.0.0. Catorce más apuntan a mcp.run, catorce a skills.claude.ai, catorce al propio agentcards.host39.org de NANDA. El quilt federado, hoy, es en gran medida un espejo del catálogo de otro.

Dos detalles merecen nombre propio. Primero, 249 de los 251 registros están marcados domain_verified: true, incluyendo registros de stripe.com, adobe.com, cloudflare.com, salesforce.com y redhat.com cuyo publisher se declara como "Cisco agntcy" y cuya URL de registry es el host de Outshift — todos creados con segundos de diferencia entre sí el 26 de junio de 2026. Resolver urn:ai:domain:stripe.com devuelve ese registro con la marca de verificado puesta. Segundo, el descriptor ARD que producción sirve en GET /api/ard anuncia su propia identidad como did:web:localhost:3001, con urn:air:nanda-index:localhost:3001 como identificador y http://localhost:3001/docs como URL de documentación — el descriptor se construye desde un valor de config que nunca se seteó para producción.

La firma en v2 existe, pero es artesanal. server/src/services/signing.ts implementa su propio serializador de JSON canónico, firma el resultado con Ed25519 crudo (o RSA-SHA256) y guarda base64 en un campo signature_value o signature. Sin JWS, sin COSE, sin JCS. Compara con A2A v1, que firma Agent Cards con JWS según RFC 7515 sobre JCS según RFC 8785 — dos estándares registrados, con verificadores listos en cualquier lenguaje. El canonicalizador de NANDA tiene 30 líneas y su contrato entre implementaciones es un comentario.

Ninguno de los seis media types de NANDA aparece en el registro IANA application, que bajamos el mismo día. Tampoco application/vnd.nanda.receipts-ledger+json. Tampoco application/ai-registry+json ni application/ai-skill+md, los dos tipos ARD a los que el servicio mapea. No es fatal — hay muchos formatos vivos sin registrar — pero un proyecto que se posiciona como sucesor de DNS todavía no hizo el trámite que DNS sí hizo.

Hallazgo 6: adónde se fue la capa de pagos de NANDA

La fase 2 del roadmap publicado del proyecto es "Agentic Commerce": mecanismos de pricing de conocimiento, protocolos económicos, mercados de recursos. Hay un repositorio para eso. projnanda/nanda-payments, con licencia MIT, creado el 4 de septiembre de 2025, es un MCP server para "NANDA Points" — un ledger interno con wallets, balances, cargos de servicio y recibos, sobre MongoDB.

Trae un protocolo de pago llamado x402-NP. El nombre es prestado; la mecánica no. En vez del envelope de x402, devuelve un error JSON-RPC -32402 con un precio en NP, y espera que el reintento llegue con tres headers propios: X-PAYMENT-AGENT, X-PAYMENT-TX-ID, X-PAYMENT-AMOUNT. El settlement es un update de fila en la base de puntos. El string USDC no aparece en ninguna parte del repositorio. Su último commit es del 22 de septiembre de 2025.

El trabajo activo se mudó a projnanda/nandatown, un simulador alpha Apache-2.0 cuyo pitch es "tienes un protocolo de agentes; Nanda Town te dice si realmente funciona". Tiene una capa de payments con interfaz quote/pay/verify_payment/refund y tres plugins de referencia: créditos prepagos, streaming por tick y un escrow. Su set de problemas para hackathon incluye uno titulado "Streaming pay-per-second payments with mid-stream cancellation", que observa que "las propuestas de pago HTTP estilo x402 son explícitamente por request". Es una observación justa, y se está explorando en un simulador y no sobre un rail.

Así que la capa de dinero de NANDA hoy es un ledger de puntos congelado y un banco de pruebas. Su index, mientras tanto, contiene tres agentes liquidando USDC real en Base a través de campos que el index no sabe leer.

Qué significa para LLM4Agents

LLM4Agents vende inferencia a compradores autónomos y cobra por llamada en stablecoins sobre x402. Discovery está aguas arriba de eso: antes de que un agente pueda pagarnos, tiene que encontrarnos. NANDA es una de tres o cuatro respuestas candidatas a "dónde miran los agentes", junto al directorio de AGNTCY, el registry de MCP y los fetch planos a .well-known.

De lo que medimos se siguen tres conclusiones.

Población de registry no es distribución. Un contador de cinco cifras sobre un conjunto alcanzable de tres cifras recuerda que hay que pesar los registries por lo que resuelven, no por lo que declaran. El costo de un record en NANDA v2 es un POST HTTP y un registro TXT en DNS; el tráfico esperado hoy es casi cero. Registrarse, monitorear, no construir encima.

El campo de precio no va a llegar nunca. Tres schemas de discovery auditados, cero campos económicos entre ellos. No es un descuido a corregir aguas arriba; es una elección estructural. Los directorios describen capacidad, y el precio de una capacidad es dinámico, por-llamante y por-momento. Que es exactamente el argumento del 402: la cotización va en la respuesta a la llamada, no en una entrada de directorio que envejece. Nuestro trabajo no es militar por una clave price. Es asegurar que todo camino que nos descubra termine en un endpoint que responda 402 con un array accepts completo.

La liveness es la señal de confianza real. El 73% de las URLs de AgentFacts registradas en un index público están muertas. Ningún esquema de firmas arregla eso. Una entrada de directorio que apunta a un 404 es peor que no tener entrada, porque quema un request y le enseña al crawler que ese registry es ruido. Lo que sea que publiquemos, hay que mantenerlo vivo — y medir que lo estamos manteniendo vivo.

Cómo mantenerse en la frontera

Pasos concretos, en el orden en que los tomaríamos.

1. Un documento de capacidades, cuatro proyecciones. Mantener una única descripción interna de lo que ofrece el gateway — modelos, límites, precios, endpoints — y generar desde ahí una A2A Agent Card, una MCP server card, un documento AgentFacts y una entrada de AI Catalog. Cada registry auditado este año consume una de esas cuatro formas. Mantener cuatro archivos a mano es como se termina con 193 URLs muertas.

2. Poner el puntero de pago en el documento, como hicieron los tres agentes. No como un precio que el registry vaya a parsear, sino como pista legible por máquina: la URL del recurso x402, las redes y assets soportados, el facilitator y las extensiones que honramos. El documento de agent-guild es el mejor ejemplo del corpus de cómo se ve eso en la práctica, y prueba que ya hay consumidores leyéndolo.

3. Firmar con estándares, no con un canonicalizador. Si firmamos nuestras cards, firmarlas con JWS sobre JCS, exactamente como especifica A2A v1. Eso le da a cualquier contraparte un verificador listo y nos deja rotar claves sin publicar una librería. También nos deja verificables en el mundo v2 de NANDA, cuyo servicio de firma va a tener que interoperar con las mismas cards.

4. Tratar cada entrada de registry como una dependencia monitoreada. Un job semanal que baje nuestra propia entrada de cada index y cada facts URL, verifique HTTP 200 y validez de schema, y alerte ante desvíos. El modo de falla que encontramos en producción es silencioso: la entrada queda listada para siempre después de que el host desapareció.

5. Emitir recibos antes de que alguien los exija. La extensión offer-receipt de x402 ya define ofertas y recibos firmados. El bloque improvisado verifiable_receipts que encontramos en el corpus de NANDA muestra que hay demanda exactamente de eso y ningún acuerdo sobre la forma. Publicar recibos en un formato especificado es barato ahora y se vuelve palanca en cuanto los sistemas de reputación necesiten algo que consumir.

6. Vigilar los index de punteros, no el buque insignia. NANDA v2, el AI Catalog de AGNTCY, el registry de MCP y el discovery basado en DNS están convergiendo al mismo patrón de tres saltos: una capa fina de punteros, un catálogo por organización, una card por agente. Ahí es donde va a rutear el tráfico eventualmente. El lugar donde hay que estar listado es la capa que resuelve, y hoy eso significa tener nuestro propio catálogo en un dominio estable y verificado — el segundo salto — en vez de apostar a un único primer salto.