The Missing Registry: Why Agent Discovery Is the Next Big Open Standard Battle in Agentic AI

We solved the tool-integration problem. MCP gave AI agents a universal way to talk to external tools, databases, and APIs. We solved the agent-to-agent coordination problem. A2A gave agents a standard protocol to discover each other, delegate tasks, and collaborate. But there’s a gaping hole between these two achievements that every enterprise building multi-agent systems is painfully aware of: there is no mature, open-source standard for agent and tool registries.

Every major player in the agentic AI ecosystem — Google, Microsoft, IBM, Cisco, Anthropic, OpenAI — sees the same need. Every major player is building a slightly different answer. And this fragmentation is exactly what open standards exist to prevent.

This post maps the current landscape of open-source registry efforts, the discovery mechanisms built into existing protocols, the emerging projects filling the gap, and what enterprises should do today while the dust settles.

Why Registries Matter: The DNS Analogy

Think about what DNS did for the internet. Before DNS, you had to know the exact IP address of every machine you wanted to talk to. DNS gave the internet a discovery layer — a federated, decentralized system where anyone could register a name, anyone could resolve it, and no single entity controlled the whole thing.

Agent registries are the DNS moment for agentic AI. Right now, if your enterprise has 50 MCP tool servers and 20 specialized agents, every client needs to be manually configured with the endpoints, credentials, and capability descriptions of each one. That’s the equivalent of memorizing IP addresses in 1990.

What we need is a system where:

• Agents and tools can register their capabilities in a structured, machine-readable format
• Client agents can discover the right agent or tool for a task without prior configuration
• Registries can federate with each other, so there’s no single point of control
• Discovery includes identity verification, so you know the agent you found is who it claims to be
• The whole thing works across frameworks, vendors, and deployment environments

We’re not there yet. But the building blocks are emerging fast.

The Discovery Mechanisms Already Built Into Protocols

Before looking at standalone registry projects, it’s worth understanding what discovery capabilities the major protocols already provide. Each takes a different approach, and none of them alone constitutes a full registry solution.

A2A Agent Cards and .well-known/ Discovery

Google’s Agent-to-Agent protocol, now under the Linux Foundation’s AAIF, introduced the concept of Agent Cards — JSON documents that describe an agent’s identity, service endpoint, capabilities, authentication requirements, and skills. Agent Cards are the closest thing we have to a standardized agent manifest with broad industry backing.

A2A recommends DNS-based discovery using the /.well-known/agent.json convention. If you know an agent's domain, you can fetch its Agent Card from a predictable URL. This works well for public agents hosted on known domains, similar to how /.well-known/openid-configuration works for OAuth discovery.

But the A2A specification explicitly acknowledges its limitation here: it does not prescribe a standard API for curated registries. The spec leaves registry implementation as an exercise for the community. Client agents can also discover Agent Cards through curated registries that support capability-based search, but what those registries look like, how they expose their APIs, and how they federate with each other — all of that is undefined.

ACP Agent Manifests and BeeAI’s Registry Implementation

IBM’s Agent Communication Protocol (now merged into A2A under the Linux Foundation) took a different approach with Agent Manifests. ACP supports three discovery modes:

1. Online discovery — querying ACP servers directly and fetching public manifest files from well-known URLs
2. Registry-based discovery — centralized registries that provide a unified view of agents across multiple ACP servers
3. Offline discovery — embedding agent metadata directly into distribution packages like container image labels

The ACP specification explicitly notes that Agent Manifests describe capabilities but not deployment or consumption instructions. The registry-based discovery mode is implemented in the BeeAI Platform but is not yet part of the core ACP spec. BeeAI’s approach of embedding standardized metadata in container image labels is pragmatic and Kubernetes-native, making it one of the most production-ready open-source implementations available today.

ANP Agent Discovery Protocol (Decentralized, DID-Based)

The Agent Network Protocol takes the most architecturally ambitious approach to discovery. ANP positions itself as the HTTP equivalent for the agentic web and uses a three-layer protocol stack:

1. Identity layer — W3C DID (Decentralized Identifiers) for portable, platform-independent agent identity with end-to-end encryption
2. Meta-protocol layer — natural language negotiation of communication protocols between agents
3. Application layer — Agent Description Protocol (ADP) for capability descriptions and Agent Discovery Protocol for finding agents

ANP’s Agent Discovery Protocol specifies how agents publish and retrieve description documents across the network. It supports DID-based authentication, rate limiting, and permission controls distinguishing public from private agents. The protocol uses /.well-known/agent-descriptions documents with pagination support for large-scale deployments.

What makes ANP distinctive is its fully decentralized design. There’s no central registry — agents discover each other through a federated network of description documents, conceptually similar to how WebFinger resolves identities across federated social media platforms. It’s the most “internet-native” approach but also the most complex to adopt.

DUADP (Distributed Universal Agent Discovery Protocol)

DUADP is a newer entrant focused specifically on filling the gap between tool-integration (MCP) and agent coordination (A2A). It uses DID-based resolution via /.well-known/duadp.json to answer the fundamental question: "What is this agent and who vouches for it?"

DUADP doesn’t try to replace MCP or A2A. Instead, it operates as a complementary layer handling discovery and identity — the two things the other protocols intentionally left out of scope.

The Open-Source Registry Projects Actually Being Built

While the protocols define discovery primitives, several open-source projects are building the actual registry infrastructure that enterprises need.

Cisco AGNTCY Agent Directory — The Most Comprehensive Open-Source Effort

AGNTCY, originally incubated at Cisco’s Outshift R&D arm and donated to the Linux Foundation in July 2025, is arguably the most comprehensive open-source agent infrastructure project currently available. It has over 65 supporting companies including Dell, Google Cloud, Oracle, and Red Hat as formative members.

AGNTCY’s Agent Directory is the standout component for the registry discussion. Here’s what makes it architecturally distinctive:

OCI-based metadata storage. Agent metadata is stored as OCI (Open Container Initiative) artifacts, tracked by SHA-based digests. The reference implementation uses ORAS (OCI Registry as Storage) with the zot server implementation. This means agent descriptions are stored using the same infrastructure that powers container image registries — proven, scalable, and well-understood by platform teams.

Peer-to-peer distribution. The directory uses a libp2p Kad-DHT (Kademlia Distributed Hash Table) layer for exchanging directory entries across nodes. Any organization can run its own directory and keep it in sync with others, forming a decentralized network. There’s no single point of control, and new directories can join at any time.

OASF (Open Agent Schema Framework). AGNTCY uses its own schema framework for describing agents — covering core attributes, skills, domains, features, capabilities, and performance metrics. OASF is flexible enough to describe individual agents, multi-agent applications, and even agent-to-tool protocols like MCP. The directory supports A2A Agent Cards and MCP server descriptions as data models within OASF.

IETF Internet-Draft. Cisco has submitted an IETF Internet-Draft (draft-mp-agntcy-ads-00) formalizing the Agent Directory Service specification. This signals serious intent to standardize the distributed directory architecture at the internet standards level — the same process that standardized HTTP, DNS, and TLS.

Free SaaS offering. Outshift by Cisco provides a free, multi-tenant SaaS version of the Agent Directory for developers who want to publish and discover agents without running their own infrastructure.

AGNTCY also includes components beyond the directory: SLIM (Secure Low-latency Interactive Messaging) for secure agent communication with gRPC and MLS encryption, an identity service for task-based authorization, and observability SDKs. It’s a full stack, not just a registry.

mcp-gateway-registry — Community-Driven, Enterprise-Ready

The agentic-community/mcp-gateway-registry project on GitHub is a community-driven, enterprise-ready MCP Gateway and Registry that has been moving fast. As of early 2026, it has completed several critical features:

• A2A Curated Registry Discovery — enabling agent-to-agent discovery through curated registry patterns
• Federation Between MCP Registry Instances — bidirectional sync between registry instances with peer management, chain prevention, orphan detection, and security scan propagation
• Unified UI Registration Flow — streamlined registration for both MCP servers and A2A agents through a single interface
• Registry-Only Deployment Mode — run the registry as a standalone catalog/discovery service without the gateway component

The project integrates with Anthropic’s MCP Registry and supports OAuth authentication through Keycloak and Microsoft Entra. It offers configurable modes (full, skills-only, mcp-servers-only, agents-only) so teams can deploy exactly what they need. For enterprises already running Keycloak or Entra for identity, this is probably the fastest path to a governed agent registry.

Solo.io Agent Gateway and agentregistry

Solo.io’s approach tackles the registry problem from the infrastructure angle. Their open-source Agent Gateway (now also under the Linux Foundation) provides a unified data plane for agent connectivity with native MCP and A2A protocol support. Built in Rust, it serves as a drop-in proxy for agent-to-agent and agent-to-tool communication.

The key registry-relevant features include:

• Federated MCP endpoint — all tool servers appear as a single, virtualized MCP tool server to clients
• Centralized tools registry — federated discovery across heterogeneous tool servers regardless of location
• Policy-based tool exposure — agents only see tools they’re authorized to use, following least-privilege principles
• Automatic OpenAPI-to-MCP translation — existing REST APIs are automatically exposed as MCP-native tools

Solo.io also launched agentregistry, a dedicated project for curating, publishing, and deploying MCP servers and agent skills. It comes with a CLI (arctl) and web UI for managing the registry lifecycle.

The enterprise version adds sandboxed tool servers, IAM integration, and centralized observability — but the core open-source version provides meaningful registry functionality out of the box.

The Convergence That Needs to Happen

Looking across all these efforts, a clear pattern emerges. Everyone is solving the same set of problems with slightly different schemas, slightly different APIs, and slightly different federation mechanisms. The convergence that the ecosystem urgently needs includes:

1. A Shared Manifest Schema

A2A’s Agent Card, ACP’s Agent Manifest, DUADP’s agent definition, OASF’s agent descriptions, and ANP’s Agent Description Protocol all describe largely the same information: what an agent can do, how to authenticate with it, what protocols it speaks, and where to find it. The differences between them are smaller than they appear from the outside.

The analogy here is OpenAPI. Before OpenAPI (née Swagger), we had RAML, API Blueprint, WADL, and half a dozen other API description formats. The value of OpenAPI wasn’t that it described APIs better than any individual format — it was that the industry converged on one machine-readable schema that became the source of truth for code generation, testing, governance, and documentation tooling. Agent manifests need the same convergence.

2. An Open, Federated Discovery Network

Not a single registry controlled by any one company. The ecosystem needs a protocol for federating registries the way DNS federates name resolution — anyone can run a resolver, records are portable, and the network is resilient to any single point of control. AGNTCY’s libp2p-based DHT approach and ANP’s decentralized discovery protocol both point in this direction, but they’re not interoperable with each other yet.

3. Portable Agent Identity

A2A Agent Cards and ACP Agent Manifests describe what an agent can do, but neither provides a portable identity that travels with the agent across deployment environments, frameworks, and vendors. An agent running in LangChain and the same agent redeployed in CrewAI should be provably the same agent. Decentralized Identifiers (DIDs) offer the most promising foundation here — ANP and DUADP both use them — but no standard has unified DID-based agent identity with capability discovery and policy enforcement.

4. Capability-Based Authorization as Protocol Primitives

When Agent A delegates work to Agent B which calls Tool C, who is accountable for the outcome? Current protocols have no standard way to express or record delegation chains across system boundaries. Separation of duties, privilege tiers, and audit trails are enforced entirely at the application layer today — by convention, by documentation, or by hope. Policy frameworks like Cedar and OPA are being used in practice, but they need to become protocol-level primitives.

The Governance Umbrella: AAIF and Linux Foundation

The single most important structural development for registry standardization is the formation of the Agentic AI Foundation (AAIF) under the Linux Foundation in December 2025. Co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block, AAIF provides neutral governance for:

• MCP (Anthropic) — tool integration
• A2A (Google, merged with IBM’s ACP) — agent-to-agent communication
• Goose (Block) — agent framework
• AGENTS.md (OpenAI) — project-level agent instructions
• BeeAI (IBM) — multi-agent platform
• Docling — document processing

AGNTCY is under the Linux Foundation as well, though as a separate project rather than under AAIF directly. Having these projects under the same organizational umbrella creates the institutional conditions for schema convergence and federation protocol standardization to actually happen.

The MCP Dev Summit in New York City on April 2–3, 2026, is likely to surface registry standardization as a key discussion topic. AAIF has already attracted 97 new members as of early 2026, indicating strong industry momentum.

What You Should Do Today

If you’re building enterprise agentic systems and need registry/discovery capabilities right now, here’s a practical framework:

For Kubernetes-Native Teams

Start with Solo.io’s Agent Gateway or BeeAI Platform’s container-label-based discovery. Both are cloud-native, integrate with existing CI/CD pipelines, and understand the Kubernetes deployment model. Agent Gateway’s automatic OpenAPI-to-MCP translation is particularly valuable if you have a large existing REST API surface.

For Multi-Agent Coordination at Scale

Evaluate AGNTCY’s Agent Directory. It’s the most architecturally complete solution for decentralized, federated agent discovery. The OCI-based storage model means your platform teams already understand the underlying infrastructure. The IETF Internet-Draft signals long-term standardization intent.

For Quick Wins with MCP Tool Governance

The **mcp-gateway-registry** community project offers the fastest path to a governed MCP server registry with A2A agent discovery. If you're already using Keycloak or Microsoft Entra, the OAuth integration gets you to production quickly.

For Schema Choices

Use A2A Agent Cards as your primary agent manifest format. It has the broadest industry backing (Google, Microsoft, IBM, AWS, and 50+ technology partners), is under neutral governance at AAIF, and the ACP merger means it subsumes IBM’s Agent Manifest work. Supplement with OASF if you need richer capability descriptions for AGNTCY directory integration.

For Discovery Conventions

Implement /.well-known/agent.json (A2A) as your baseline discovery mechanism. It's simple, DNS-based, and works immediately for domain-scoped agents. Layer registry-based discovery on top for capability search across your agent fleet.

For Identity

Watch the DID-based approaches (ANP, DUADP) closely, but don’t bet your architecture on them yet. They’re the right long-term direction for portable agent identity, but the tooling and enterprise adoption story isn’t mature enough for production use in most organizations. Use OAuth 2.0 / OIDC through your existing identity provider for now.

The Bottom Line

We’re in the “pre-OpenAPI” era of agent registries. The equivalent of Swagger, RAML, and API Blueprint are all competing, each with valid design ideas and real backing. The structural conditions for convergence exist — AAIF provides neutral governance, the major cloud providers are all at the table, and the protocol-level building blocks (Agent Cards, Agent Manifests, OASF) are more similar than different.

The registry problem will be solved. The question is whether it converges around an open, federated standard or fragments into vendor-specific implementations (Microsoft Entra Agent Registry, Kong MCP Registry, and a dozen others). The Linux Foundation’s track record with Kubernetes, Node.js, and PyTorch suggests the open path is viable — but it requires active community participation, not just passive observation.

If you’re an enterprise engineering leader building multi-agent systems, the worst thing you can do is wait. Pick a registry approach, implement it, and contribute your learnings back to the community. The standard will emerge from production experience, not committee deliberation.

The agents are ready. The tools are connected. Now we need them to find each other.

References and Further Reading:

• AAIF — Agentic AI Foundation
• A2A Protocol — Agent Discovery
• AGNTCY Documentation
• AGNTCY Agent Directory Service — IETF Draft
• Agent Network Protocol (ANP) — GitHub
• ACP Agent Discovery
• Solo.io Agent Gateway
• mcp-gateway-registry — GitHub
• Solo.io agentregistry Lab
• “MCP Is Not Enough” — Thomas Scola, Medium (March 2026)
• Kong MCP Registry Announcement
• “Deciphering the alphabet soup of agentic AI protocols” — The Register (January 2026)