Agentic partners integration: AI support agents for Microsoft Azure Red Hat OpenShift

How a multi-agent system diagnoses and resolves support cases across partner ecosystems

October 22, 2026
Carlos Camacho Gonzalez Sharon Dashet
Related topics:
Artificial intelligence
Related products:
Red Hat OpenShift AI

Red Hat AI quickstarts are ready-to-run demo applications that demonstrate real-world AI use cases, designed for seamless deployment on the Red Hat AI platform. The Azure Red Hat OpenShift sub-module of the agentic-partners-integration AI quickstart is a demo of real-world enterprise scenarios where multiple ISVs within the same ecosystem collaborate to resolve support cases using an open source multi-agentic system.

When an operations team troubleshoots a production issue on Azure Red Hat OpenShift, the workflow typically involves switching between the Azure portal, command-line sessions, and monitoring dashboards, correlating data across resource health checks, memory metrics, and advisor recommendations for each affected resource. The engineer doing the triage needs to already know which tools to reach for and which Azure services to inspect.

AI support agents that rely on knowledge bases and training data can help with documented, previously solved issues. But live infrastructure troubleshooting depends on the current state of specific resources, not on what an LLM learned during training or what exists in a ticket history.

The Azure Red Hat OpenShift partner agent, available on the Azure Red Hat OpenShift branch of the agentic-partners-integration quickstart, demonstrates how to close this gap. It connects an AI agent to a containerized Microsoft Azure MCP server that exposes Azure resource management operations as MCP tools. The agent discovers available tools at runtime, decides which to invoke based on the user's question, executes them using the MCP protocol, and synthesizes the results into a response based on real infrastructure data. Most support organizations face the same bottleneck: A ticket arrives incomplete, triage takes hours, and the engineer must switch between several different tools. Static knowledge bases can't replace live system inspection, and this is exactly what the agentic-partners-integration quickstart delivers: Live system inspection paired with intelligent reasoning, systematic investigation, and built-in trust through Open Policy Agent (OPA) authorization and full audit trails.

Figure 1 shows the end-to-end request flow. A user submits a question through a chat interface. The request passes through a central orchestration and security layer (request manager), which authenticates the user using Keycloak (JWT-based identity and department roles) and enforces access control with OPA before anything reaches an agent. Cleared requests are then dispatched, communicating through the A2A protocol, by a routing agent to 1 of 4 domain-specific language model agents: Kubernetes support, network support, software support, or Microsoft Azure Red Hat OpenShift support. The Azure Red Hat OpenShift support agent, the focus of this article, is the only one connected to an MCP server that exposes tools, resources, and prompts for live Azure infrastructure access.

Components of the agentic-partners-integration quickstart
Figure 1: Components of the agentic-partners-integration AI quickstart.

Architecture

We've added 2 new components to the basic agentic-partners-integration AI quickstart:

  • Microsoft Azure MCP Server: Containerized proxy exposing Azure resource management operations as MCP tools over HTTP (runs on port 5008)
  • Azure Red Hat OpenShift partner agent: Standalone AI agent that discovers and invokes MCP tools to query Azure infrastructure (runs on port 8004)

Microsoft Azure MCP Server

The MCP server spawns the Microsoft Azure MCP binary as a subprocess in stdio mode, and exposes its tools over a standard HTTP endpoint at /mcp. On startup, it discovers all available tools and caches them. The tools cover Azure's management plane. Some examples::

  • Resource health: Availability status for any Azure resource type
  • Azure advisor: Security, cost, and reliability recommendations
  • Azure monitor: CPU, memory, disk, and network metrics, alerts, diagnostics
  • AKS / Microsoft Azure Red Hat Openshift: Cluster health, node pool state, container app inspection
  • Storage: Account details, capacity, throughput
  • Key vault: Secret and certificate inventory
  • Databases: Cosmos DB, PostgreSQL, SQL, and Redis operations

Microsoft Azure Red Hat OpenShift partner agent

The agent is a generic LLM + MCP tool-calling loop, not a collection of hard-coded Azure commands. It uses the OpenAI-compatible API models, which means swapping the LLM backend is a single environment variable change. Ollama works too, for a fully local option with no API key.

  • Connect: When a question arrives, the agent first opens a session with Microsoft Azure MCP Server and calls list_tools() to discover available operations
  • Reason: It then sends the user's question and the tool definitions to the LLM
  • Execute: Should the LLM calls a tool, the agent invokes it through MCP, feeds the result back, at which point the LLM might call another tool or produce a final answer
  • Iterate: This loop continues, allowing the agent to correlate findings across multiple Azure services before responding

The agent's system prompt enforces a discover-then-execute pattern: First call a tool with an intent to learn its sub-commands, then call it again with a specific command and parameters. This 2-step approach lets the agent navigate Azure's tool hierarchy without the LLM needing to memorize every available operation.

Microsoft Azure MCP Server is not an agent, it's a tool provider. It exposes Azure Resource Manager APIs as discoverable tools, provides tool definitions with name, parameters, and return types, executes API calls when the agent invokes them, and returns structured results. The agent is the reasoning system, and the MCP server is the infrastructure access layer.

Real-world example: The OOMKilled investigation

Suppose a user asks: "My pods on the Microsoft Azure Red Hat OpenShift cluster keep getting OOMKilled. What's going on?"

The agent calls resourcehealth to learn the available health-check operations, then calls it again for the Microsoft Azure Red Hat OpenShift cluster's availability status. It interacts with the Azure MCP server to discover available metrics, and understand for instance memory utilization among other metrics on the cluster's node pool, to finally discover recommendations on the resource group. The final response synthesizes the health status, memory metrics, and recommendations into a diagnosis with data-backed remediation steps. Each tool call is logged with the tool name, arguments, and a result preview providing a full audit trail of what the agent inspected and what data it used.

A query example to interact with the Microsoft Azure MCP Server (using Microsoft Azure Red Hat OpenShift support).
Figure 2: A query example to interact with the Microsoft Azure MCP Server (using Microsoft Azure Red Hat OpenShift support).

FIgure 2 shows another example of the UI in action. On the left panel, the available agents are listed, the routing agent (always active), Microsoft Azure Red Hat OpenShift support, Kubernetes support, software support are accessible, while network support shows no access for the current user, demonstrating OPA enforcement in practice.

In the main chat area, the user (Carlos) asks "Get the latest Azure Static Web Apps best practices?"

The routing agent delegates the question to Microsoft Azure Red Hat OpenShift support. That agent responds with a detailed, structured answer, covering workflow references (azure-prepare, azure-validate, azure-deploy) and deployment path selection guidance, all based on live Azure knowledge retrieved through the MCP server.

Security: Read-only by design

Giving an AI agent access to a cloud management plane raises immediate questions about the blast radius. The Microsoft Azure Red Hat OpenShift agent addresses these through multiple layers.

Minimal Azure permissions

The default service principal uses the Azure Reader role, read-only access to the management plane. The agent can inspect resource health, query metrics, and list configurations, but cannot create, modify, or delete infrastructure. Production deployments would typically scope the service principal to specific resource groups.

OPA policy gating

Every request passes through OPA before reaching any agent. OPA evaluates the intersection of the user's department permissions and the agent's capabilities, a user without azure department access cannot reach the Microsoft Azure Red Hat OpenShift agent, regardless of what they type.

Full audit trail

Every A2A call records which agent handled the request, the response content, and processing time. Within the agent, each MCP tool call logs the tool name and arguments. Security teams can trace exactly what the agent inspected.

Agent isolation

The Microsoft Azure Red Hat OpenShift agent runs as a fully independent container with its own LLM connection and no shared code with other agents. It communicates with the orchestrator solely through the A2A HTTP contract. A partner could rewrite this agent in any language or framework, only the invoke endpoint's JSON schema matters.

Deploying in OpenShift

This system can be deployed to Red Hat OpenShift using our Helm chart. All container images are pre-published to github.com/orgs/rh-ai-quickstart/packages, with no local builds required.

Prerequisites:

  • Red Hat OpenShift 4.12+ cluster, with an authenticated oc session
  • Helm 3.8+
  • An LLM API key

First, clone the repository and change directory into the directory:

$ git clone -b Azure Red Hat OpenShift https://github.com/rh-ai-quickstart/agentic-partners-integration
cd agentic-partners-integration

Then use the oc command to create a new project:

oc new-project partner-agent

Use helm to install:

helm install partner-agent ./helm \
  --namespace partner-agent \
  --set llm.apiKey='your-api-key' \
  --set llm.provider=gemini \
  --set llm.model=gemini-2.5-flash \
  --set azure.tenantId='your-azure-tenant-id' \
  --set azure.clientId='your-azure-client-id' \
  --set azure.clientSecret='your-azure-client-secret' \
  --set azure.subscriptionId='your-azure-subscription-id' \
  --set networkPolicies.platform=openshift

After installation, 2 test users have azure department access:

carlos@example.com

  • Password: carlos123
  • Departments: software, kubernetes, azure

sharon@example.com

  • Password: sharon123
  • Departments: software, network, kubernetes, azure

Sign in as Carlos and ask: "Are there any active alerts in our subscription?" The agent discovers the monitor tool, executes it against your live Azure environment, and returns actual alert data. For OpenShift deployments, create azure-sp-credentials and azure-ad-credentials Kubernetes secrets and deploy from the catalog. See the full deployment guide for detailed instructions.

Deploying the MCP Server using OpenShift AI MCP catalog

Red Hat OpenShift AI 3.5.1 includes an MCP catalog integrated into the AI Hub dashboard, providing pre-curated MCP servers from Red Hat, technology partners, and the open source community. Instead of sourcing container images or writing Kubernetes manifests manually, you can browse, deploy, and manage MCP servers directly from the dashboard.

Enabling the MCP catalog

The MCP catalog is a Technology Preview feature that requires 3 steps to enable:

1. Enable the MCP Lifecycle operator

Enable the MCP Lifecycle operator in the DataScienceCluster. This operator manages the lifecycle of MCP server instances on your cluster, creating, scaling, upgrading, and removing them using the MCPServer custom resource (mcp.x-k8s.io/v1alpha1):

oc patch datasciencecluster default-dsc --type merge \
  -p '{"spec":{"components":{"mcplifecycleoperator":{"managementState":"Managed"}}}}'

2. Install the MCP Gateway operator

This operator provides the Envoy-based gateway layer for MCP server federation and routing, and is a prerequisite for the catalog UI to appear in the dashboard:

oc create namespace mcp-gateway

cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: mcp-gateway
  namespace: mcp-gateway
spec: {}
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: mcp-gateway
  namespace: mcp-gateway
spec:
  channel: preview
  installPlanApproval: Automatic
  name: mcp-gateway
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF

3. Enable the required feature flags

Finally, you must enable the feature flags in the dashboard configuration. The MCP catalog and registry pages are gated behind feature flags in the OdhDashboardConfig resource:

oc patch odhdashboardconfig odh-dashboard-config \
  -n redhat-ods-applications --type merge \
  -p '{"spec":{"dashboardConfig":{"mcpCatalog":true,"mcpRegistry":true}}}'

After all 3 steps are complete, the MCP servers tab appears under AI Hub in the OpenShift AI dashboard.

Deploying the Microsoft Azure MCP Server

With the MCP catalog enabled, deploying an MCP server is a matter of a few clicks. In this example, we deploy the Microsoft Azure MCP Server, which exposes Azure resource management tools to your AI agents and applications through the model context protocol.

Navigate to AI Hub, then to the MCP servers in the OpenShift AI dashboard. The catalog displays available MCP servers organized by support tiers (Red Hat, Partner, and Community), along with descriptions, supported tools, and transport protocols. Use the filters to narrow the results by deployment mode or transport to find the server you need.

Figure 3 displays the catalog filtered by MCP servers, with the Microsoft Azure Red Hat OpenShift module listed:

The MCP servers catalog from Red Hat AI.
Figure 3: The MCP servers catalog from Red Hat AI.

The deployment dialog for the Azure MCP Server from Figure 4 shows the YAML configuration where users can set Azure credentials via environment variable references to Kubernetes secrets, adjust runtime parameters, and specify a service account. Clicking Deploy submits the configuration to the MCP Lifecycle Operator, which provisions the server as a managed workload in the target namespace.

Microsoft Azure MCP Server configuration details displayed in the AI Hub.
Figure 4: Microsoft Azure MCP Server configuration details displayed in the AI Hub.

Beyond Azure: The MCP ecosystem pattern

MCP integration is not Azure-specific. The same architecture, a containerized MCP server, an agent discovering tools at runtime, and OPA authorization gates works for any infrastructure backend. Each new MCP server ISV in the Red AI ecosystem becomes a potential new agent capability with no framework changes and no cross-team coordination.

The Oracle SQLcl MCP server quickstart demonstrated this pattern for database access on OpenShift. The Microsoft Azure Red Hat OpenShift agent extends it to cloud infrastructure management and both run side by side in the same partner support system. Any infrastructure backend that exposes an MCP server becomes a potential agent capability through the same architecture, with no framework changes required.

What's next

We plan to extend the agentic-partners-integration AI quickstart with agentic AI observability using platforms like MLFlow and Langfuse. In addition, we will offer the option to deploy the pattern in other on-premise and cloud environments and with multiple inference services.

For more information, check out these resources: