Red Hat’s internal sales agent shows what production AI orchestration actually requires

Red Hat has published the architecture behind Sales Assistant, an internal AI agent that it says handles thousands of requests from sellers each day. The useful part is not the sales use case. It is the production shape of the system: specialized agents, governed tool access, model routing, retrieval pipelines and familiar Kubernetes operations all have to work together before an agent can do more than answer a demo prompt.

What Red Hat built

According to Red Hat, sellers use the assistant from Salesforce, Slack, the web and a mobile application. A supervisor agent running on Red Hat OpenShift AI coordinates specialized agents that reach Salesforce, pricing and configuration systems, product lifecycle data and internal knowledge repositories. Tool execution goes through Model Context Protocol servers registered in the OpenShift AI MCP registry.

The design keeps consequential actions reviewable. Red Hat’s example has the agent prepare a quote for human review rather than submit it autonomously. Responses are also presented with citations to the enterprise data used to generate them. Those two choices—source visibility and a human gate—matter more than a polished chat interface when the agent can touch business systems.

The retrieval and inference layers

Red Hat says the platform has ingested more than 300,000 documents through pipelines built with KubeRay and Docling on OpenShift AI. At query time, it retrieves candidate material, reranks the results using models served through Red Hat AI Inference and injects selected context into the prompt.

Inference is hybrid rather than tied to one model. Red Hat describes automatic selection between hosted and frontier models based on latency, performance and cost. That makes routing policy part of the application architecture: teams have to decide which requests may leave their environment, what quality threshold justifies a more expensive model and how failures fall back.

The less glamorous layers are equally important. Users authenticate through Red Hat single sign-on technology based on Keycloak. Backend services use Quarkus and Red Hat Universal Base Image. Kustomize promotes the application through development, staging and production, while horizontal pod autoscaling and observability handle changing load and operational visibility.

What platform teams should take from it

This is a vendor account of Red Hat’s own deployment, not an independent performance study; it gives no accuracy, latency or cost measurements. Still, it exposes a practical boundary for enterprise agents. The model is only one dependency. Identity, MCP server registration, retrieval quality, action approval, model-selection policy and deployment controls are the real system.

Teams adapting the pattern should start with one bounded workflow and make every tool call attributable. They should define which operations require human approval, test retrieval and reranking separately from generation, and treat model routing as policy rather than an invisible optimization. The architecture suggests that production agent work belongs jointly to application, data and platform teams—not to a prompt engineer operating alone.