Seven Fields, Five Questions: What an Agent Registry Has to Answer Before You Trust It — Luminity Digital
The Agent Registry Teardown  ·  Series 28  ·  Companion to Data Substrate  ·  Prologue  ·  July 2026
The Agent Registry Teardown

Seven Fields, Five Questions

Every agent registry now shipping arrives with its own comparison table, drawn by the party that wins it. This companion arc reads the field on one fixed rubric instead — the five criteria a substrate must satisfy before an enterprise can defend what it deployed. First, the definition: what an agent registry actually is, from the literature, before any vendor scores it.

July 2026 Tom M. Gomez Luminity Digital 9 Min Read
This opens The Agent Registry Teardown, a companion arc to Data Substrate or Scaffolding — the series that defined the Substrate Fitness Criteria, the five properties a data substrate must hold before it can carry agentic workloads an enterprise is accountable for. Each teardown reads one agent registry against that rubric: A2A, MCP, AGNTCY, Entra Agent ID, and AgentFacts, closing with a synthesis matrix. This prologue does the first job: fix the definition — and the category term — on independent ground before any format is scored.

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.

The Instrument

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.

The Comparison the Field Does Not Draw for Itself.

If you are evaluating agent-identity architecture for an enterprise deployment and want a practitioner conversation, the calendar is open.

Start the conversation
The Agent Registry Teardown  ·  Series 28  ·  Companion to Data Substrate or Scaffolding
Prologue  ·  Now Reading Seven Fields, Five Questions
Post 01  ·  A2A The Card That Climbed
Post 02  ·  MCP A Manifest Is Not an Identity
Post 03  ·  AGNTCY Honest About Trust Roots
Post 04  ·  Entra The Issuer Is the Enterprise
Post 05  ·  AgentFacts Credentialed, Not Verified
Post 06  ·  Synthesis The Field on One Grid
References & Sources

Like this: