Why this distinction matters in 2026
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 registry: catalog plane
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 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 gateway: data plane
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.
The single question the gateway answers, per invocation: should this particular call actually happen right now?
Security governance: what the combined layer protects
Neither the registry nor the gateway alone covers enterprise security requirements. Three properties depend on both planes being co-designed.
- 01
Access policy without enforcement is a document
The registry defines which agent can invoke which other agent and which user roles are authorized. The gateway executes that policy as a runtime decision. A registry without a gateway is a directory of intentions; a gateway without a registry has no source of truth for what to enforce, so it falls back on whatever was loaded last.
- 02
Both planes must be attributed in the audit record
A complete audit record includes the gateway side (who invoked, what version of the agent ran, which MCP tools were called, with what inputs) and the registry side (which version was current and what policy was in effect at the moment of the decision). Without attribution from both, the audit is either raw logs without semantic meaning, or registry snapshots without corresponding invocations.
- 03
Policies must propagate ahead of time
When access is revoked or an agent deprecated, there is a window between the registry update and the gateway enforcing the new state. Real-time propagation is a baseline security property, not a performance optimization. Stale policy enforced past its revocation window is a security incident in slow motion.
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.
Two questions that reveal whether a vendor has both
Most vendor decks list the same features. The two questions below cut through the feature parity and expose the architecture.
- 01
Deprecation propagation
If you deprecate an agent version in the registry right now, how long until the gateway stops routing invocations to it? The right answer is real-time, or at the next call. Anything that includes a sync interval, a cache TTL, or a manual cache flush exposes a window where the gateway is enforcing a state the registry has retired.
- 02
Access revocation
If you revoke a user's access in the registry right now, how long until the gateway stops authorizing their invocations? Same question, same correct answer. If the answers differ for these two scenarios, you are looking at two products with different sync semantics, not a unified control plane.
How Jarvis Registry implements both
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. 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.
Common questions
-
What is the difference between an agent registry and an agent gateway?
The registry is the catalog plane: source of record for which agents exist, what they do, who owns them, who can call them, and what version is current. Out of the call path. The gateway is the data plane: in the call path, enforcing authentication, authorization, routing, and observability for every invocation. Different planes, different failure modes, different vocabularies. Both are required for governed agentic AI in 2026. -
Can I buy a registry without a gateway, or vice versa?
You can. We do not recommend it. A registry without a gateway is a directory of agents nobody is enforcing access to. A gateway without a registry is enforcing whatever policy was last loaded into it, with no source of truth for whether the policy is current. Both shapes pass a basic demo and fail the first audit. The architectural answer is one product where both planes share schemas, policy objects, and version reference. -
How do registries and gateways interact with the orchestration layer?
The orchestration layer sits above both. It uses the registry to discover which agents and MCP servers exist (and what they can do); it relies on the gateway to enforce the access policy on each invocation it triggers. The orchestration layer itself owns workflow lineage, logic-step semantics, approval gates, bounded autonomous agent pools, and the tool-level audit. The full breakdown is in /agent-registry/agent-orchestration-layer/. -
What are the diagnostic questions that catch a vendor pretending to have both?
Two. First: if you deprecate an agent version in the registry now, how long until the gateway stops routing invocations to it? Second: if you revoke a user's access in the registry now, how long until the gateway stops authorizing their invocations? The right answer to both is real-time, or at the next call. Any sync interval, cache TTL, or manual flush exposes the registry-gateway split as two products with reconciliation between them, not a unified control plane. -
Where does Jarvis Registry fit in this architecture?
Jarvis Registry is a unified registry and gateway in one product. The catalog plane and the data plane share schemas, policy objects, and version reference, so deprecation and revocation propagate on the next call rather than the next sync. Federates across AWS AgentCore, Azure AI Foundry, Cloudflare MCP Server Portals, and self-hosted MCP and A2A servers. Connects Jarvis Chat, Claude Desktop, Claude Code, VS Code, Cursor, GitHub Copilot, Microsoft Copilot, Windsurf, and ChatGPT through one MCP-compatible endpoint.