Agent Registry vs. Agent Gateway

When enterprises in 2026 evaluate agent infrastructure, the most common confusion is treating registries and gateways as interchangeable components that can ship in the same product slot. They are not the same thing, and conflating them introduces real holes.

The failure modes are different. The security surface is different. The governance requirements are different. This article draws the line, covers the three places they overlap, and connects back to the orchestration problem both are trying to solve. For the broader treatment of why the orchestration layer is non-negotiable, see The Agent Orchestration Layer.

The agent registry is the source of record for the agents and MCP servers that exist, what capabilities each supports, who owns each one, and who is allowed to call each one. Identity, capability schema, access policy, versioning, ownership. The capability schema itself is what makes the registry usable at runtime: a typical entry carries an agent_id, a version string (semver, with the previous active version retained for rollback), a tools array where each tool advertises a JSON Schema for its arguments and a returned-type contract, and a policy_ref pointing at the access policy currently bound to that version. The tool half of that shape is not our invention — the MCP tools specification defines a tool as a name, an optional title, a description, an inputSchema that "MUST be a valid JSON Schema object (not null)", an optional outputSchema, and optional annotations. When the registry approves a new version, those four fields are what the gateway reads on the next call to decide whether an incoming invocation matches the surface the registry now advertises.

One reason the registry cannot simply trust what an agent submits: the same specification warns that "clients MUST consider tool annotations to be untrusted unless they come from trusted servers," and notes that tool-name uniqueness is scoped to a single server, so anything aggregating tools across servers "SHOULD implement a disambiguation strategy such as prefixing tool names with a server identifier." Establishing which servers are trusted, and owning the namespace that disambiguates them, is catalog-plane work.

The registry is not a broker or an intermediary in the invocation path. It exists as a catalog every interested component queries to gather information. Each entry provides an audit foundation that lets invocations be traced.

The single question the registry answers: does this agent exist and am I using it correctly?

The agent gateway is where enforcement happens — at the invocation point, between the orchestrator / LLM and the registered agents and MCP servers. It handles authentication, authorization, routing, rate limiting, and circuit breaking. It generates the per-call observability record: the resolved MCP tool, the resolved arguments, the resolved result, the agent version that served the call, and the policy snapshot the gateway used to authorize it.

That is a policy enforcement point in the sense the access-control literature already uses. NIST's glossary defines a policy enforcement point as a component that "enforces policy decisions in response to a request from a subject requesting access to a protected object; the access control decisions are made by the policy decision point" — and, in the CNSSI wording carried in the same entry, as "a system entity that requests and subsequently enforces authorization decisions." The registry/gateway split is that split. NIST SP 800-207, Zero Trust Architecture (August 2020) applies the same decomposition to network access, which is why zero-trust reviewers usually recognize this architecture on sight.

The vendor implementations name the same jobs. AWS describes Amazon Bedrock AgentCore Gateway as "a fully managed AI gateway that provides a single, secure entry point for agentic traffic" that "converts APIs, Lambda functions, and existing services into Model Context Protocol (MCP)-compatible tools," and states that it "is the only solution that provides both comprehensive ingress authentication and egress authentication in a fully managed service" in its developer guide. Its capability list is a data-plane list: Security Guard, Translation, Composition, Secure Credential Exchange, Semantic Tool Selection, Infrastructure Manager.

The single question the gateway answers, per invocation: should this particular call actually happen right now?

Five questions show where the two planes diverge — and why neither can stand in for the other.

Neither the registry nor the gateway alone covers enterprise security requirements. Three properties depend on both planes being co-designed.

Three additional governance properties — traceable identity, enforced approval gates, blast-radius control — also depend on the combined layer. We cover them in the orchestration article. Governance is not a separate plane bolted on top of an orchestration stack; governance is what makes the orchestration stack trustworthy enough to run production code.

Many vendors ship the registry and the gateway as separate products with periodic sync. Three failure modes follow predictably when this is the architecture.

The protocol gives the enforcement side a hard edge to hold. Under the MCP authorization specification, MCP servers "MUST validate that access tokens were issued specifically for them as the intended audience, according to RFC 8707 Section 2," clients "MUST implement Resource Indicators for OAuth 2.0" and send the resource parameter "in both authorization requests and token requests," and servers "MUST implement OAuth 2.0 Protected Resource Metadata (RFC 9728)." A token minted for one server therefore cannot be replayed against another — but only if the enforcement point knows which resource identity the registry currently assigns to that agent version. Shared state is what makes the audience check mean anything.

The pattern in that table is the argument of this article, stated in numbers. The two rows with no propagation window at all are the two things the protocol evaluates on every single request — audience validation and version declaration. Everything the gateway holds as its own cached copy of state acquires a window, and the windows are published: thirty seconds for a rate-limit or emergency-block change on AWS's managed gateway, unbounded when the limiter itself is unhealthy, and manual for catalog-side version retirement on Foundry. None of those are defects — AWS documents the thirty seconds and the fail-open behaviour openly, which is more than most vendors do. They are the cost of holding state in two places.

That is what the two diagnostic questions below are really testing. Ask any vendor for the equivalent of this table for their own product, in their own documentation. If the number is not written down anywhere, it is not a number they are managing. Figures above are from the MCP authorization specification, the MCP versioning guide, the MCP feature lifecycle and deprecation policy, AWS's AgentCore Gateway rate-limit best practices, and Microsoft's Foundry Agent Service quotas and limits.

Most vendor decks list the same features. The two questions below cut through the feature parity and expose the architecture.

Jarvis Registry is a unified registry and gateway, not two products synced together. The catalog and data planes share schemas and policy objects. It indexes A2A agents, MCP providers, and external providers like AWS AgentCore and Azure AI Foundry as part of a federation layer. Both of those carry their own catalog semantics that a federation layer has to read: AgentCore Gateway composes "multiple APIs, functions, tools, agents, and model providers behind a single endpoint" and supports "OpenAPI, Smithy, and Lambda as tool input types" per the AWS developer guide, while Microsoft Foundry Agent Service gives each agent "a dedicated Microsoft Entra identity," snapshots versions automatically, and publishes agents into the Entra Agent Registry per Microsoft Learn. Access policy, capability schema, and version information are stored in one place and read by the gateway in real time at call evaluation.

The product registers as the unified MCP endpoint that Jarvis Chat, Claude Desktop, Claude Code, VS Code, Cursor, GitHub Copilot, Microsoft Copilot, Windsurf, and ChatGPT all connect to. From the client's perspective there is one MCP server. Behind it Jarvis Registry is brokering invocations across providers, with one audit trail and one policy surface.

Deprecation in the registry takes effect in the gateway on the next call. Access policy revocation does the same. The per-call audit record names the registry version and the policy configuration in effect at the moment of the call — eliminating the post-hoc reconciliation that splits the registry-gateway-as-two-products architecture.

Governance is not an additional layer tacked on. Governance is the system.

Primary sources behind the protocol and vendor claims in this article. All URLs verified August 2026.