A secured agent that can't reach anything is just expensive autocomplete with a badge. In "Why prompt-level guardrails aren't enough," I walked through 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 I see most enterprise agent rollouts stall—not because the model fails, but because the plumbing does.In our previous articles, we talked about how 3 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 problemI can wire a LangChain agent to a Jira API in an afternoon. I've done it. The authentication is straightforward, the data format is documented, the error handling is manageable. 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 1 connector instead of 1 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 endpointThose harder questions are exactly what MCP Gateway (an Envoy-based proxy, currently in tech preview on Red Hat AI) exists to answer. I think of it as doing 3 things, and all 3 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.Now connect those 3 capabilities back to those 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 enoughMCP 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 4 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 helps make multi-agent coordination explicit and auditable. Instead of 1 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 is compelling because it 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 existsThe shift from single agents to agent networks creates a discovery problem that I think most teams underestimate.Without a catalog, discovering what agents and MCP servers exist in an organization requires tacit knowledge. I've watched teams spend weeks building a connector to a system that another team connected 6 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 it.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 todayWhile the agent registry is planned, the connectors themselves are shipping now. Red Hat provides a growing set of domain-specific MCP servers—ready-made connectors that teams can use today rather than building them yourself:MCP Server for Red Hat OpenShift handles cluster CRUD operations, Helm chart management, KubeVirt, observability integration and service mesh queries.OVN-Kubernetes MCP covers networking diagnostics.Red Hat Advanced Cluster Security for Kubernetes MCP provides vulnerability scanning and security posture queries.MCP server for Red Hat Advanced Cluster Management for Kubernetes supports multicluster queries.Assisted Installation MCP offers cluster installation guidance.Lightspeed Advisor MCP delivers Red Hat Insights and risk prediction.Ansible Automation Platform MCP Server lets agents trigger playbooks, check job status and orchestrate configuration changes.Developer Hub MCP plugins expose Backstage actions, software catalog and TechDocs.The ecosystem extends beyond Red Hat. The MCP catalog in OpenShift AI 3.4 (in developer preview) provides a curated, multi-tier catalog: Red Hat servers alongside technology partner servers from Confluent Cloud, EDB Postgres AI, IBM Terraform, Microsoft Azure, and Dynatrace, plus community servers for MongoDB and MariaDB. All are deployed through the MCP lifecycle operator, connected via MCP Gateway and consumable in gen AI studio—the same governed lifecycle regardless of who built the server.These aren't theoretical. A team building an autonomous SRE agent can start with the MCP server for Red Hat OpenShift and have cluster operations wired in before lunch. A security team can connect to MCP server for Red Hat Advanced Cluster Security and query vulnerability data without writing a single line of API integration code. The same platform infrastructure that powers an autonomous SRE agent can support an HR onboarding assistant, a procurement approval workflow, or a customer service escalation bot—the infrastructure is domain-agnostic even when the use cases differ.What I find particularly useful is that all of these MCP servers are accessible from any MCP-compatible IDE—VS Code, Cursor, GitHub Copilot, Claude Desktop, etc. Developers can query live cluster state, troubleshoot deployments, and get pipeline suggestions without leaving their editor. They can also be combined, extended, or used as patterns for building organization-specific connectors. For decision makers, shipping domain-specific MCP servers means the first agents can reach production systems in days, not the months that custom integration projects typically require.The real transitionThe monolith-to-microservices transition took years and produced distributed system complexity that no one fully anticipated. The equivalent transition for agents—from one agent calling one API to networks of agents coordinating across enterprise systems—is happening faster, with higher stakes, because agents act autonomously. What made microservices manageable was the infrastructure that emerged around it: service meshes, API gateways, container orchestration. The same pattern applies here. The connectivity infrastructure built on open protocols—MCP and A2A rather than proprietary vendor APIs—is what makes the agent transition manageable while keeping the organization in control of its integrations.The identity layer is in place. The connectivity layer is taking shape. But none of it matters if the model behind the agent can't reliably call tools when it needs to.Get startedReady to connect your agents to enterprise tools with Red Hat AI?Try OpenShift AI free in the Developer Sandbox: Connect agents to MCP servers in a preconfigured environmentExplore the MCP servers interactive demo: Discover, deploy and connect MCP servers on OpenShift AIBrowse Red Hat AI documentation: OpenShift, networking, security, multicluster, and moreRead the A2A protocol specification: Agent-to-agent coordination standardStart with the BYO Agent starter kits Pre-configured MCP Gateway integration includedThe MCP catalog is here: Discover, deploy, and connect on Red Hat OpenShift AI: Curated catalog of Red Hat, partner, and community MCP servers with lifecycle management