A vendor-neutral, practitioner explainer of agent discovery: Agent Cards, MCP registries, AGNTCY’s directory, DNS-style ANS, and whether you actually need one.
What is an AI agent registry?
An AI agent registry is a catalog — a phone book for autonomous agents — that stores each agent’s identity, capabilities, and network location so other agents and systems can find it, trust it, and call it without hardcoding anything. Instead of your orchestrator opening a literal connection to finance-agent-v1, it asks the registry a question: “find me something that can query Q3 revenue, is allowed to, and is healthy right now.” The registry answers with an endpoint and the proof you need to trust it.
If you’re meeting agent discovery for the first time, the simplest mental model is DNS. DNS turns a human-friendly name (alatirok.com) into a machine address and gives you confidence you reached the right server. An agent registry does the same job for agents: it turns “an agent that can translate HIPAA documents” into a concrete, verifiable endpoint. The vocabulary is new in 2026, but the pattern is forty years old.
Here’s where the term gets slippery, and why this guide exists. “AI agent registry” is used for at least five genuinely different things: a self-published JSON file at a known URL (A2A Agent Cards), a centralized package index (the MCP Registry), a distributed peer-to-peer directory (AGNTCY), an enterprise identity directory (Microsoft Entra Agent ID), and a DNS-style universal naming layer (the Agent Name Service). They overlap, compete, and solve overlapping slices of the same problem. The rest of this article disambiguates them so you can answer the only question that matters: do I need one, and which one?
A registry answers three questions about an agent before you call it: who is it (identity), what can it do (capability), and where is it (location) — plus, in production-grade systems, is it allowed and is it alive.
Why do agents need a registry at all? The discovery problem
Agents need a registry because in a multi-agent system, no single agent knows in advance which other agents exist, what they can do, or how to reach them safely — and hardcoding that knowledge breaks the moment anything changes. This is the agent discovery problem, and it is widely described as one of the most pressing unsolved challenges in enterprise AI for 2026.
Consider three agents you built yourself. Discovery is trivial: you wire them together in code, you know every endpoint, and you trust them because you wrote them. Now imagine 300 agents across finance, support, procurement, and legal — some yours, some from vendors, some spun up last week by another team. Hardcoded connections become a combinatorial nightmare, and worse, you have no way to know whether the agent answering on a given endpoint is the one you think it is.
The discovery problem has two halves that people constantly conflate. The first is location: where does the capability I need live? The second is identity and trust: is this endpoint really that agent, is it allowed to act, and is it healthy? A directory that solves only the first half — “here’s a URL” — is not infrastructure; it’s a phishing surface. Every serious registry design in 2026, from OWASP’s Agent Name Service to AGNTCY’s Agent Directory, treats verifiable identity as a first-class requirement rather than an afterthought.
This is why the question “how do AI agents find each other” rarely has a single answer. The right mechanism depends on scale, trust boundaries, and how dynamic your fleet is. A handful of co-located agents can use direct configuration. Agents that span organizations need cryptographic identity and a shared naming scheme. The sections below walk through each real-world mechanism you’ll actually meet.
“A directory that tells you where an agent lives but not whether it’s really that agent is a phishing surface, not infrastructure.”
Surya Koritala, founder of Cyntr
Agent registry vs model registry: what’s the difference?
A model registry tracks static artifacts — trained model versions, weights, and metadata — while an AI agent registry tracks live, autonomous programs that reason and act, adding real-time discovery, health heartbeats, access control, and dynamic orchestration that a model registry never needs. They sound similar and are sometimes built on the same tooling, but they answer different questions.
A model registry (think MLflow, SageMaker Model Registry, or a Hugging Face repo) answers: “which version of this model do I deploy, what data trained it, and what were its eval metrics?” The artifact is inert. It sits on disk until something loads it. Versioning, lineage, and stage promotion (staging → production) are the core jobs, as TrueFoundry’s guidance lays out.
An agent registry answers a fundamentally more dynamic question: “which running agents exist right now, what can they do, are they reachable, am I allowed to call them, and how do I authenticate?” The catalog entries point at live processes, not files. That introduces requirements a model registry simply doesn’t have: heartbeat or health monitoring (the registry marks stale agents and removes dead ones), runtime access-control policy, audit logging of invocations, and capability-based search rather than version lookup.
The practical tell: if your so-called agent registry has no concept of liveness and no concept of “who is allowed to call whom,” you’ve built a model registry with extra columns. That’s fine for tracking which agent definitions you’ve shipped — but it won’t let one agent safely discover and invoke another at runtime, which is the entire point.
| Dimension | Model registry | AI agent registry |
|---|---|---|
| What it catalogs | Trained model versions, weights, metadata | Live, running agents and their capabilities |
| State of the entry | Static artifact on disk | Live process with an endpoint |
| Core operation | Version lookup & stage promotion | Capability-based discovery & routing |
| Liveness | Not applicable | Heartbeats / health monitoring |
| Identity & trust | Provenance of the artifact | Runtime identity (PKI, signed cards), access control |
| Typical tools | MLflow, SageMaker, Hugging Face | AGNTCY Directory, Entra Agent ID, ANS, A2A registries |
How do AI agents find each other? The five real mechanisms
In 2026, agents find each other through five overlapping mechanisms: self-published A2A Agent Cards, the centralized MCP Registry, AGNTCY’s distributed Agent Directory, enterprise directories like Microsoft Entra Agent ID, and the DNS-inspired Agent Name Service (ANS) — each catalogs different things and lives at a different point on the centralized-to-distributed spectrum. The arXiv survey of registry solutions (2508.03095) compares exactly these approaches across security, authentication, scalability, and maintainability.
A2A Agent Cards (decentralized self-description). The Agent2Agent protocol, open-sourced in 2025 and now under the Linux Foundation, has each agent publish a JSON “Agent Card” describing its name, endpoint, capabilities, and authentication requirements. The standardized location is https://{domain}/.well-known/agent-card.json — notably the first AI-agent-specific entry in IANA’s .well-known registry. There’s no central server; discovery is “if you know my domain, you can read my card.” A2A also supports curated registries and direct configuration as discovery strategies, though it doesn’t yet standardize a registry API.
The MCP Registry (centralized index). The official Model Context Protocol registry at registry.modelcontextprotocol.io launched in preview in September 2025, backed by Anthropic, GitHub, Microsoft, and PulseMCP. It’s an app-store-style catalog of MCP servers — the tools agents use — published as structured descriptors. It’s designed to be consumed by downstream aggregators (Smithery, PulseMCP, Docker Hub) rather than end users directly. Strictly speaking this catalogs tools/servers, not agents, but it’s the discovery layer most builders meet first.
AGNTCY Agent Directory (distributed). AGNTCY — the Internet of Agents initiative started by Outshift by Cisco and donated to the Linux Foundation — runs a peer-to-peer Agent Directory built on a Kademlia DHT, with OCI artifact storage and Sigstore-backed signing for integrity. Any organization can run its own directory and keep it in sync with others, forming a federated inventory. Agents are described using the Open Agentic Schema Framework (OASF) and discovered by attributes.
Enterprise directories (Microsoft Entra Agent ID). The enterprise pattern treats agents as first-class identities inside an existing identity provider, with policy enforcement and zero-trust integration. You get governance and lifecycle for free, at the cost of platform lock-in. This is the “agents are just non-human identities” view, and it’s where most regulated enterprises will land first.
Agent Name Service (ANS). The universal naming layer that ties the others together — covered in depth in the next section.
What is the Agent Name Service (ANS)? DNS for AI agents
The Agent Name Service (ANS) is a DNS-inspired, protocol-agnostic universal directory for AI agents that uses PKI certificates for verifiable identity, proposed to fill the absence of any public, secure agent-discovery framework. It was introduced in arXiv:2505.10609 and is endorsed by the OWASP GenAI Security Project, which positions it explicitly as “the DNS of the AI era.”
ANS borrows DNS’s best ideas and adapts them for agents. First, a structured naming scheme. An ANS name encodes protocol, capability, provider, version, and optional extensions in a single human-readable, machine-parseable string — for example a2a://textProcessor.DocumentTranslation.AcmeCorp.v2.1.hipaa. You can read off the transport protocol (A2A), the capability, the provider, the version, and a compliance hint (HIPAA) at a glance.
Second, verifiable identity. Where DNS bolted on security later (DNSSEC), ANS bakes in PKI from the start: every agent registration is backed by a certificate, so resolving a name doesn’t just give you an address — it gives you cryptographic proof you reached the agent you asked for. This is the half of the discovery problem that self-published cards alone don’t fully solve.
Third, protocol-agnosticism. ANS defines a modular Protocol Adapter Layer so the same directory can resolve agents speaking A2A, MCP, ACP, or others. It also formalizes a registration and renewal lifecycle — agents register, certificates expire and renew, stale entries age out — and capability-aware resolution, so you can search by what an agent does, not just by its name.
Importantly, ANS is a proposal and reference architecture as of 2026, not a deployed global utility like DNS. The right way to read it is as the conceptual blueprint the other mechanisms are converging toward: a naming and trust layer that could sit above A2A cards, MCP servers, and AGNTCY directories rather than replace them.
Two patterns dominate. (1) Signed Agent Cards / credentialed facts — the card or fact record is cryptographically signed (A2A, NANDA AgentFacts), so you verify the signature on what you fetched. (2) PKI certificates at resolution — ANS returns a certificate-backed identity when you resolve a name, like TLS for agents. Either way, the rule is the same: never trust an endpoint you discovered until you’ve verified the identity attached to it.
Centralized vs federated vs distributed registries: which model?
Agent registries split into three architectural models — centralized, enterprise/federated, and distributed — and the right choice is a trade-off between control, governance, and resilience, not a question of which is technically best. The arXiv registry survey frames it cleanly: centralized registries give you control but a single point of failure; enterprise solutions give policy enforcement and zero-trust but require infrastructure lock-in; distributed approaches give resilience and cross-org interoperability but add real complexity in discovery and verification.
Centralized. One authoritative catalog (the MCP Registry, a single TrueFoundry-style agent registry, your own internal directory). Easiest to build, easiest to govern, easiest to search. The downside is obvious — if it’s down, discovery stops, and one operator controls the namespace. For a single organization, this is almost always the right starting point.
Enterprise / federated. A directory tied to your identity provider (Entra Agent ID) or several synchronized directories (the AGNTCY federation model, where each org runs its own and they gossip). You get strong policy and governance, and federation lets trust span organizations without one central kingmaker. The cost is operational complexity and, in the IdP case, lock-in.
Distributed. No central authority at all — a DHT or gossip network where agents announce and discover peer-to-peer (AGNTCY’s underlying transport, P2P research designs). Maximally resilient and censorship-resistant, ideal for large, dynamic, cross-org fleets. But verification gets genuinely hard: without a central authority, you lean entirely on cryptographic identity (signatures, content addressing, PKI) to know who you’re talking to.
Pros
Cons
Do I need a registry for 3 agents or 300? A decision guide
You do not need an agent registry for 3 agents — direct configuration or a single Agent Card per agent is enough — but somewhere between roughly 15 and 50 agents, when you can no longer answer ‘which agent is allowed to call which, and is it healthy?’ from memory, a registry stops being optional. Scale is the obvious trigger, but it’s not the only one.
Three signals matter more than raw count. First, trust boundaries: the moment agents from different teams or different organizations need to call each other, you need verifiable identity and a shared place to discover it — a registry with PKI or signed cards. Second, dynamism: if agents come and go (autoscaling, ephemeral task agents), you need heartbeats and a directory that prunes the dead ones, because stale endpoints cause silent failures. Third, governance: if you must prove who-called-what for compliance, you need the audit log and access control a registry provides.
A useful rule of thumb. For 3 agents: skip the registry, use a config file and code review. For ~10-30 agents within one team: start with A2A Agent Cards at well-known URLs, or a lightweight centralized catalog. For dozens of agents across teams, or any cross-org calls: adopt a real registry with identity (a centralized directory, Entra Agent ID, or an AGNTCY/ANS-style approach). For hundreds of agents spanning organizations: that’s the federated/distributed territory the research papers are actually designed for.
Don’t over-build. A registry that nobody queries is just a stale config with a database bill attached. Add the machinery when the pain — duplicated wiring, mystery endpoints, ‘is this the real payments agent?’ — actually shows up, not before. The decision table below maps each mechanism to when it earns its place.
| Mechanism | What it catalogs | Model | Identity mechanism | Discovery protocol | When you need it |
|---|---|---|---|---|---|
| A2A Agent Cards | Individual agents (self-described) | Decentralized | Signed / authenticated agent card | /.well-known/agent-card.json | ~3-30 agents; same or trusted domains |
| MCP Registry / Smithery | MCP servers (tools), not agents | Centralized | Namespace + publisher verification | REST index, consumed by aggregators | Whenever agents need to discover tools |
| AGNTCY Agent Directory | Agents via OASF schema | Distributed / federated | Sigstore signing, content addressing | Kademlia DHT, OASF attribute search | Hundreds of agents across orgs |
| Microsoft Entra Agent ID | Agents as enterprise identities | Enterprise (centralized) | IdP + zero-trust policy | Directory query within tenant | Regulated enterprises; governance-first |
| Agent Name Service (ANS) | Any agent, any protocol | Universal directory (proposed) | PKI certificates | DNS-style capability-aware resolution | Cross-protocol, trust-critical fleets |
| Model registry (for contrast) | Trained model versions & weights | Centralized | Artifact provenance | Version lookup | You’re shipping models, not discovering live agents |
How an agent registry works end to end
Start centralized, demand identity, scale to federation only when it hurts
An agent registry works in four runtime phases — register, discover, verify, invoke — with health monitoring and governance running continuously underneath. Walking through them makes the abstract concrete and shows exactly where identity does its job.
1. Register. An agent publishes a metadata payload — effectively an Agent Card — declaring its name, version, endpoint, capabilities, supported protocols, and authentication requirements. In an ANS-style system this also means obtaining a PKI certificate; in AGNTCY it means signing the record with Sigstore. The registry stores the entry and, in lifecycle-aware systems, sets an expiry that forces periodic renewal.
2. Discover. A client agent (or orchestrator) queries the registry by capability, not by hardcoded address — “find an agent that can translate documents and is HIPAA-compliant.” The registry returns one or more matching entries with their endpoints and identity material. Capability-aware resolution is what lets you swap translator-v2 for translator-v3 without touching the caller.
3. Verify. Before invoking, the client checks the identity attached to the result — validating the certificate (ANS), the card signature (A2A), or the credentialed assertion (NANDA AgentFacts). This is the step naive integrations skip and the step that prevents one agent from being tricked into calling an impostor.
4. Invoke. The client connects to the verified endpoint using the auth scheme the card declared (mutual TLS, OAuth 2.0, bearer token), and the registry logs the invocation for audit. Underneath all four phases, health monitoring pings agents and prunes stale ones, and access-control policy decides which agents are even allowed to discover or call which — the governance layer that turns a directory into infrastructure you can put in front of payments or PII.
The pattern to internalize: discovery and identity are one problem. Any registry you adopt should answer ‘where is it’ and ‘is it really who it claims to be’ in the same breath — because an unverifiedBuilder’s take
I run platforms where agents have to find each other without a human in the loop, so I have opinions about when a registry earns its keep. The short version: most teams reach for a registry years before they need one, and a few reach for it years too late.
- For 3 agents you don’t need a registry. You need a config file and a code review. A registry that nobody queries is just a stale YAML with a database bill attached.
- The moment you can’t answer ‘which agent is allowed to call payments, and is it healthy right now?’ from memory, you’ve crossed the line. That’s usually somewhere between 15 and 50 agents, not 300.
- Discovery and identity are the same problem wearing two hats. A directory that tells you where an agent lives but not whether it’s really that agent is a phishing surface, not infrastructure. PKI or signed cards are non-negotiable above a handful of agents.
- Don’t confuse a registry with a model registry. If your ‘agent registry’ is just MLflow with extra columns, you’re tracking weights, not live actors. Heartbeats and revocation are the tell.
- Pick centralized until federation actually hurts. At Cyntr and Loomfeed I default to a single catalog with strong auth; the distributed-DHT story is real but it’s a tax you pay for cross-org trust you don’t have yet.
Frequently asked questions
It’s a phone book for AI agents. An AI agent registry is a catalog that stores each agent’s identity, capabilities, and network location so other agents and systems can discover, trust, and call it without hardcoding connections. Production-grade registries also track whether an agent is healthy and whether the caller is allowed to reach it.
A model registry tracks static artifacts — trained model versions, weights, and lineage — and its core job is versioning and stage promotion. An AI agent registry tracks live, running agents, adding real-time capability-based discovery, health heartbeats, runtime access control, and audit logging. The tell: an agent registry has a concept of liveness and ‘who can call whom’; a model registry does not.
The Agent Name Service (ANS) is a DNS-inspired, protocol-agnostic universal directory for AI agents that uses PKI certificates for verifiable identity. Proposed in arXiv:2505.10609 and endorsed by the OWASP GenAI Security Project, it defines a structured naming scheme (e.g. a2a://textProcessor.DocumentTranslation.AcmeCorp.v2.1.hipaa), a Protocol Adapter Layer supporting A2A/MCP/ACP, and capability-aware resolution. As of 2026 it is a reference architecture, not a deployed global utility.
Through five overlapping mechanisms in 2026: self-published A2A Agent Cards at /.well-known/agent-card.json, the centralized MCP Registry for tool servers, AGNTCY’s distributed Agent Directory (a Kademlia DHT with Sigstore signing), enterprise directories like Microsoft Entra Agent ID, and the DNS-style Agent Name Service. The right one depends on scale, trust boundaries, and how dynamic your fleet is.
An A2A Agent Card is a JSON manifest at https://{domain}/.well-known/agent-card.json that advertises an agent’s identity, endpoint, capabilities, and authentication requirements — it was the first AI-agent-specific entry in IANA’s .well-known registry. A single card is decentralized self-description, not a registry. A registry is what you get when a curated catalog collects many cards so clients can search them by capability.
No. For about 3 agents, direct configuration or a single Agent Card per agent is enough — a registry nobody queries is just a stale config with a database bill. You start needing one somewhere between roughly 15 and 50 agents, or sooner if agents cross team/organization trust boundaries, if your fleet is dynamic (agents come and go), or if you need audit logs and access control for compliance.
Primary sources
- Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability (arXiv:2505.10609) — arXiv
- Evolution of AI Agent Registry Solutions: Centralized, Enterprise, and Distributed Approaches (arXiv:2508.03095) — arXiv
- Agent Discovery — A2A Protocol — Linux Foundation / A2A Project
- AGNTCY Agent Directory overview — AGNTCY
- The MCP Registry — about — Model Context Protocol
- What is AI Agent Registry — A Complete Guide — TrueFoundry
- Introducing ANS: DNS-Inspired Secure Discovery for AI Agents — InfoQ
- Agent Name Service (ANS) for Secure AI Agent Discovery v1.0 — OWASP GenAI Security Project
Last updated: June 2, 2026. Related: Agent Infrastructure.
