A secured agent that can’t reach anything is just expensive autocomplete with a badge. In “Why prompt-level guardrails aren’t enough,” the previous article in this series covered how Red Hat AI allows you to give each agent a cryptographic identity and lock down what it can touch. That solves the trust problem, but it doesn’t solve the connectivity problem — and the connectivity problem is where most enterprise agent rollouts stall. Not because the model fails, but because the plumbing does.

In earlier articles in this series, three failures hit a single AI agent deployment overnight: 43 duplicate tickets, $4,000 charged to the wrong account, and a hallucinated refund policy that led to a $280 return the company had to honor. Those 43 duplicate tickets were partly a connectivity failure. The agent treated the ticketing API like a raw HTTP call: fire, get a timeout, retry, repeat. No idempotency envelope, no protocol-level retry safety, and no infrastructure between the agent and the API that understood “this request already succeeded.” The framework handled tool calling. It didn’t handle governed tool connectivity.

The gap between a working agent in development and a production-ready deployment isn’t a framework problem — it’s an infrastructure problem. BYOA (bring your own agent) is Red Hat AI’s approach: the platform provides production infrastructure for any agent framework without code changes. That includes the connectivity layer.

One Agent, One Tool, No Problem

Wiring a LangChain agent to a Jira API in an afternoon is straightforward. The authentication is manageable, the data format is documented, and the error handling is tractable. That isn’t the hard part.

The hard part is what happens at organizational scale. Dozens of agents connecting to hundreds of systems, each with different authentication schemes, different data formats, and different access policies. Every new connection is a custom integration. Every custom integration is a security surface that needs credential rotation and access reviews. Before long, the integration layer becomes a second code base that nobody budgeted for.

Model Context Protocol (MCP) standardizes this. An MCP server wraps a system’s capabilities into a tool catalog. Any MCP-compatible agent can discover and call those tools through that catalog. When Red Hat ships an MCP server for Red Hat OpenShift Cluster Management for Kubernetes, any compatible agent — LangChain, CrewAI, Claude Code, or custom — can call OpenShift operations without writing a Kubernetes API integration from scratch.

For decision makers, MCP means fewer custom integrations to fund and maintain. For developers, it means writing one connector instead of one per agent. But standardizing the protocol doesn’t answer the harder questions: which MCP server can this agent call? With what credentials? Under whose authority?

Governed Access Through a Single Endpoint

Those harder questions are exactly what MCP Gateway (an Envoy-based proxy, currently in tech preview on Red Hat AI) exists to answer. It does three things, and all three matter for the duplicate ticket problem.

  • Aggregation. The agent points at a single gateway endpoint and receives a unified tool catalog aggregated from every MCP server the organization has registered. The developer doesn’t need to know which back-end server hosts a particular tool. The agent calls the tool; the gateway routes it. For a team managing dozens of MCP servers across different departments, this is the difference between agents that need per-server configuration and agents that discover tools from a single endpoint.

  • OAuth2 token exchange. When the agent calls a tool that requires access to a downstream system — a database, a ticketing API, a Kubernetes cluster — MCP Gateway exchanges the agent’s identity token for a scoped downstream access token (a temporary credential limited to one specific service). The agent never holds cross-service credentials. If a billing agent’s token gets compromised, the potential impact stops at the billing API. There’s no lateral movement to the ticketing system or the cluster. This is the mechanism that prevents the kind of credential sprawl that led to the $4,000 wrong-account charge.

  • Authorization by token claims. Which tools an agent can call is determined by the claims in its identity token — not by what the model generated in a prompt. The tool catalog the agent sees is already filtered to what it’s authorized to use. A prompt injection attack (where malicious input tries to trick the model into calling unauthorized tools) fails at the network layer, before the call reaches any MCP server.

Connecting those three capabilities back to the 43 duplicate tickets: a properly configured MCP Gateway connection to the ticketing API would include idempotency handling at the protocol layer. Retry logic becomes a platform concern — not something every agent team reinvents for every API. For decision makers, this means fewer production incidents caused by missing infrastructure. For developers, it means the hardest integration problems are solved before they write their first line of agent code.

When a Single Agent Isn’t Enough

MCP Gateway connects agents to tools. But complex enterprise workflows rarely fit inside a single agent’s context window or capability set.

Consider a customer support workflow. An orchestrating agent receives a ticket. It needs to check the customer’s billing history, look up the return policy, verify the product warranty status, and route an escalation if the case qualifies. That is four different domains, each with separate data sources, distinct access policies, and domain-specific safety controls. Stuffing all of that into a single agent produces a model that is mediocre at everything and expert at nothing.

Agent-to-Agent (A2A) is an open protocol originally developed by Google that allows one agent to discover, delegate to, and coordinate with other agents across team and organizational boundaries. A2A makes multi-agent coordination explicit and auditable. Instead of one monolithic agent, the orchestrating agent delegates to specialists: a billing agent handles account history, a policy agent checks return windows, and a security agent evaluates posture. Each specialist returns structured results.

The mechanism that makes this work is the AgentCard — a machine-readable description of an agent’s capabilities, required tools, and model dependencies. An orchestrating agent discovers available specialists through their AgentCards, delegates work, and receives results without hardcoded coupling. If the billing team deploys an improved billing agent, the orchestrating agent discovers it through the updated AgentCard. No integration rewrite required.

This mirrors how organizations already work. Teams specialize. They publish interfaces. They coordinate through well-defined contracts. A2A does the same thing for agents — through an open protocol rather than a proprietary orchestration layer. For decision makers, this means the organizational structure of your agent network can mirror your human organizational structure. For developers, it means building a specialist agent for your domain rather than trying to build the one agent that does everything. For a detailed analysis of A2A security considerations — AgentCard protection, replay prevention, and cross-agent prompt injection — see How to enhance Agent2Agent security on Red Hat Developer.

Red Hat is building A2A support through OpenShell, an open source agent runtime developed in collaboration with NVIDIA that Red Hat is integrating into Red Hat AI for agent security and operationalization. OpenShell’s proxy supports A2A protocol transport, while AgentCard discovery is handled at the catalog and gateway level — making agents discoverable and delegatable across the cluster without requiring changes to the developer’s original agent code. OpenShell also injects production identity via SPIFFE and enforces tool governance, so A2A-compliant infrastructure comes as a platform concern rather than a developer burden. For a walkthrough of how OpenShell and Red Hat AI work together for secure agent execution, see Red Hat AI and OpenShell: Driving security-enhanced agent execution for enterprise AI.

Finding What Already Exists

The shift from single agents to agent networks creates a discovery problem that most teams underestimate.

Without a catalog, discovering what agents and MCP servers exist in an organization requires tacit knowledge. Teams spend weeks building a connector to a system that another team connected six months earlier. That duplication isn’t just wasted engineering time — it’s also a governance gap. Agents get deployed without metadata about what they can do, what tools they need, which model they depend on, or who owns them.

Red Hat addresses the MCP server discovery problem through its MCP catalog, currently available in developer preview, where teams can browse and register MCP servers across the organization. Red Hat is also building an MCP lifecycle operator, also in developer preview, that manages the deployment and governance of MCP servers on Red Hat OpenShift. For agent discovery, Red Hat is planning an agent registry — a service catalog for AI agents where a team looking for a billing specialist can search by capability, review its AgentCard, and delegate to it instead of building one from scratch.

Red Hat’s longer-term vision extends this into a managed layer for centrally hosting, observing, and auditing MCP servers as part of a unified AI hub. For an overview of Red Hat’s end-to-end MCP lifecycle — from registry to catalog to gateway — see Building effective AI agents with MCP on Red Hat Developer.

There is currently no “Hugging Face for agents” — no central marketplace for discovering and reusing agentic capabilities within organizational boundaries. These catalog and registry capabilities are positioned to fill that gap.

For decision makers, discovery tools directly reduce duplicate engineering work and provide the governance layer that procurement and security teams require before approving agent deployments at scale. For developers, they mean starting from what exists rather than starting from scratch.

What You Can Connect to Today

While the agent registry is planned, the connectors themselves are shipping now. Red Hat provides a growing library of MCP servers for enterprise systems — covering Red Hat OpenShift, Red Hat Ansible Automation Platform, and other core infrastructure — so agent teams can connect to production systems through governed, auditable tool calls without building integrations from scratch. The platform infrastructure described throughout this series — cryptographic identity, token exchange, authorization by claims, protocol-level retry safety, and multi-agent coordination via A2A — is designed to make that connectivity production-ready from the first deployment.