An agent registry is the catalog plane of enterprise agent infrastructure: the source of record for every AI agent and MCP server in your environment, what each one can do, who owns it, who is allowed to call it, and what version is in production right now. The registry is not in the call path. It is the directory every other component reads to know whether an agent exists, is current, and is authorized for the requested context.
By April 2026 the registry pattern has consolidated alongside two others — the agent gateway on the data-plane side, and the MCP gateway as a specific gateway flavor for the Model Context Protocol. Confusion between the three is the most common mistake we see in enterprise procurement decks. The registry answers what exists. The gateway answers should this call run. Both are required for governed agentic AI; one is not a substitute for the other.
What an agent registry has to track
A serviceable agent registry tracks a small number of facts well, not a large surface area badly. The minimum viable schema we see in production deployments — at customers running Jarvis Registry, AWS AgentCore, and Azure AI Foundry side by side — covers six fields:
- 01
Identity
A stable agent ID and a human-readable name. Versions live under the same identity, so deprecating v2.1 in favor of v2.3 does not orphan the audit history.
- 02
Capability schema
The MCP tools or A2A messages this agent supports, the input/output contracts for each, and the side-effect classification (read / write / delete). The gateway enforces against this schema; if the registry's copy drifts from the runtime, the gateway becomes over- or under-permissive.
- 03
Ownership
The team or service account that owns the agent. Drives change-approval routing and the page that gets paged when the agent's MCP server starts returning 500s.
- 04
Access policy
Which agents and which user roles are allowed to invoke this one. Usually expressed as RBAC referencing your IdP groups, not a parallel role system that diverges within a quarter.
- 05
Versioning
Which version is current, which versions are deprecated but still running, and the deprecation timeline. The registry is the only place where this state can be consistent.
- 06
Audit foundation
Pointers to the gateway logs, the prompt library, and the evaluation suite that validated this version. Without this, every audit becomes a manual reconciliation across three or four data stores.
Why enterprises adopted the pattern in 2026
Three forces converged in late 2025 that made the agent registry an explicit line item in enterprise budgets, not an internal-tools afterthought.
- Tool sprawl crossed an audit threshold. The Nerq Q1 2026 census indexed 17,468 MCP servers across registries; only 12.9% scored high-trust on documentation and maintenance. "Someone in Engineering already added the GitHub MCP server" stopped being a useful answer at audit time.
- Hyperscalers shipped first-party registries. AWS AgentCore Gateway went GA on October 13, 2025 with Cognito-backed OAuth. Microsoft brought registry semantics into Azure AI Foundry on a similar timeline. CISOs who had been arguing for catalog-plane discipline finally had a vendor-side reference architecture to cite.
- MCP donation to the Linux Foundation closed the single-vendor objection. On December 9, 2025 Anthropic donated the Model Context Protocol to the new Agentic AI Foundation. Neutral governance for the protocol arrived before neutral indexing of the servers — the registry is what fills that gap on the enterprise side.
Registry vs gateway: the failure modes when they are not co-designed
Treating the registry and the gateway as separate products with periodic sync is the most expensive integration mistake in this stack. Three failure modes follow predictably; we have seen all three in customer environments where the registry was procured ahead of the gateway, or vice versa.
| Failure mode | Symptom | Why it happens |
|---|---|---|
| Schema drift | Gateway is over- or under-permissive between releases | Registry approves agent v2.3, gateway is still enforcing the v2.1 capability schema |
| Orphaned policies | Stale policies authorize calls against deprecated versions | Gateway holds its own policy copies and has no automatic cleanup when the registry retires a version |
| Audit gaps | Reconciling registry approval with actual invocations is a manual exercise | Two data stores, no shared version reference, no policy snapshot at the moment of the call |
The architectural fix is co-design: a registry and a gateway that share the schema, the policy objects, and the version reference. The full deep dive is in Agent Registry vs. Agent Gateway.
Vendor evaluation: five questions that separate enterprise-grade from internal-tool
If you are building an agent registry buying matrix, these are the questions that separate a real product from a config UI dressed up as one.
- 01
Federation
Can it index agents across AWS AgentCore, Azure AI Foundry, Cloudflare MCP Server Portals, and your in-house A2A agents in one catalog — or does each provider need its own registry that you reconcile by hand?
- 02
Versioning semantics
When you deprecate an agent version in the registry, how long until the gateway stops routing to it? "Next sync interval" is the wrong answer. Real-time or first-call propagation is the right one.
- 03
Identity integration
Does it consume your IdP groups directly (SAML / OIDC / SCIM), or does it ship a parallel role system that drifts from your IdP within two quarters?
- 04
Capability schema validation
Does it validate that the registered schema matches the actual MCP server's runtime advertisement, or is the schema just a declaration the registry trusts on submission?
- 05
Audit completeness
Does the registry record include the policy snapshot at the moment of approval, not just a policy ID that may have mutated since?
The orchestration layer that sits on top
The registry tells you what exists. The gateway enforces who can call it. Neither answers the harder question: in a multi-step workflow with conditionals, parallel branches, approval gates, and autonomous agent selection, what should run, in what order, and with what oversight? That is the agent orchestration layer, and it is where most enterprise agentic AI deployments quietly fail in 2026.
If you are building a procurement matrix, the orchestration layer belongs above the registry and gateway, not beside them. We cover the failure modes — execution mode confusion, logic-step blind spots, approval gates that turn out to be advisory, autonomous workflows with unbounded agent pools — in the orchestration article linked above.