Every agent registry now shipping arrives with a comparison table.
NANDA’s table marks itself against A2A. A2A’s marks itself against unstructured discovery. Each table is drawn by the party that wins it. That is not a criticism — it is how specifications compete. But it means the enterprise architect evaluating agent identity is handed seven or eight vendor-chosen axes per format, no two tables agreeing on which axes matter, and every table terminating in the author’s own check-mark column.
The parent series already answered which axes matter. A substrate that carries agentic workloads has to satisfy five criteria — Discoverability, Context integrity, Action authority, Permissioning, Provenance — and those five are structural, not chosen. They come from what an agent does to enterprise state, not from what a format wants to advertise. So the field of agent registries can be read one way that cuts through every vendor table: collapse each format’s marketing axes into the five, and see what is actually solved.
What an Agent Registry Is
A word on the term, because it decides what this arc is scoring. The most complete public survey of the field groups exactly these five under one heading — agent registry solutions[1] — and that is the term used here. It is worth stating plainly why, because the field’s vocabulary is drifting. Google’s A2A calls its own artifact an Agent Card, and that name has begun traveling loosely across formats that publish nothing resembling a card: MCP publishes server manifests, AGNTCY publishes content-addressed records, AgentFacts publishes signed credential documents, and Entra publishes no document at all — it issues an identity. Borrowing one format’s product name for the whole category is how a category boundary gets crossed without anyone noticing, which is precisely the failure the second teardown examines. This arc takes its category term from the literature rather than from any format inside it.
The subject, then, is the agent registry: the record layer through which an AI agent is named, described, found, and trusted — so that other agents, and the systems governing them, can discover it, understand what it claims to do, and decide whether to rely on it. Each format in this arc produces a different artifact at that layer. What they share is the job.
An agent registry is not a new idea wearing new branding. It is the current phase of a documented evolution, and the literature already names the shape.
The most complete public survey of the field places the registry record inside a three-phase progression.[1] Phase one is static, isolated discovery: files published at well-known locations on an agent’s domain, consumed manually or by tightly coupled runtimes, carrying minimal fixed metadata — agent name, endpoint, basic capabilities. Google’s /.well-known/agent.json is the survey’s own example, though, as the first teardown shows, A2A has since climbed well past that static phase. Phase two adds runtime introspection through REST APIs and validated schemas. Phase three adds cryptographic verification and federated trust: metadata signed as Verifiable Credentials or PKI certificates, with TTL and revocation for cache control.
That progression is the definition this arc uses, because it comes from the field rather than from any format inside it. A registry record, in its base sense, is the static self-description of an agent — name, endpoint, and declared capabilities — resolved at a well-known location. Everything past that base is a later phase reaching for something the static file cannot hold: freshness, verifiable provenance, privacy, revocation. The formats this arc examines are, each of them, a wager about which of those additions matters most and how to build it.
The Rubric the Field Does Not Apply
Here is the load-bearing observation. The same survey evaluates its formats along four dimensions: security, authentication, scalability, maintainability.[1] Those are the right questions for whoever operates a registry. They are not the questions an enterprise has to answer for the agent it deploys. “Is this record cryptographically signed” is a security question. “Can I prove to an auditor that the capability this agent exercised was one it was actually authorized and verified to hold” is an assurance question — and no operational dimension asks it.
The five Substrate Fitness Criteria ask it. They were derived, in the parent series, from what an agent does to enterprise state — not from what a registry needs to run, and not from what a format wants to advertise. Discoverability: can the agent, and its current capability set, be found and resolved reliably. Context integrity: does the record reflect the agent’s actual live state, or a stale snapshot. Action authority: is what the agent is permitted to do bound to its identity, or merely described alongside it. Permissioning: can authority be granted, scoped, and revoked independently of the other planes, on a clock that matches enterprise governance. Provenance: can each claim be traced to an accountable issuer, and is issuance separable from truth.
Every format in this arc gets scored on these five. The scoring is not a bake-off and it does not crown a winner. Each teardown credits what a format gets structurally right and names the one place its own framing overreaches — most often the overreach the AgentFacts reading isolates, where a cryptographic signature over a claim is presented as proof the claim is true. A signature is a notarization that a named issuer asserted something. It is not a verification that the something is real. That distinction — coordination-grade infrastructure versus alignment-grade assurance — is the line every teardown walks.
Two Halves of One Problem
Reading the formats against one fixed rubric is the only way to see the shape of the field rather than the shape of each vendor’s table. A static self-published card binds identity, capability, and endpoint into one record on one clock. A cryptographically verifiable fact model splits them into independently revocable planes. A distributed directory addresses records by content digest and makes signing optional. An enterprise identity directory issues agent identities from a real authority and leaves capability to other systems. These are not better and worse versions of one thing. They are different bets about where assurance has to live — and the enterprise question is never “which format won its own table,” but “which planes am I buying, from whom, and can I defend the composition.” The series ends where the parent series’ argument points: a single matrix, every format scored on the same five axes, the comparison table the field does not draw for itself.
A registry record is the static self-description of an agent — name, endpoint, declared capabilities — resolved at a well-known location. Every richer format is a later phase reaching past what the static file can hold.
The field evaluates these formats for how well a registry runs. This arc evaluates them for whether an enterprise can defend the agent it deployed — scored on five criteria the operational lens never applies.
