Red Hat sketches an operating layer for agent fleets on OpenShift

A new Red Hat Developer architecture guide treats AI-agent operations as more than another service-mesh problem. Its proposed stack combines A2A AgentCards, the Rossoctl Kubernetes controller, SPIRE and Istio identity, temporary OAuth tokens and MLflow traces for fleets running on OpenShift.

The guide’s premise is that agents add three operational problems to familiar microservice concerns: orchestrators discover capabilities at inference time, an agent’s advertised behavior becomes part of its identity, and a technically successful response can still fail semantically. A catalog, mTLS and HTTP metrics each solve only part of that problem.

A catalog built from Kubernetes resources

A2A supplies a standard description at /.well-known/agent-card.json and a JSON-RPC interface for agent communication. Rossoctl adds the cluster catalog. Its controller watches AgentRuntime resources, retrieves agent metadata and creates searchable AgentCard resources; labels govern which workloads participate so the directory follows deployed agents instead of a separately maintained spreadsheet.

There is a deployment-order catch: the public route needed in an AgentCard may not exist until infrastructure is created. Red Hat uses a two-phase Helm flow—first establish the route and capture its hostname, then inject that value into the agent deployment.

The guide positions OpenShift AI as the surrounding platform for model serving and accelerator provisioning, while Rossoctl manages the agent-specific directory. That is an architecture pattern rather than evidence that one controller removes every integration boundary; operators still need to assemble and govern the components.

Identity extends beyond the network path

The security design uses SPIRE to issue short-lived workload certificates from Kubernetes identity and Istio to enforce mTLS between agents. Signed AgentCards are intended to stop a malicious workload from advertising false capabilities, while Rossoctl’s AuthBridge issues scoped, temporary OAuth2 tokens for tool access instead of embedding static credentials.

Those layers answer different questions: which workload made the connection, whether its advertised behavior is authentic and what downstream tools it may call. That separation is useful for agent platforms because network identity alone cannot validate a self-description used by an orchestrator to delegate work.

Traces expose decisions, not just requests

MLflow tracing captures orchestration flow, tool invocations and model latency. The guide describes automatic instrumentation for LangGraph and a hybrid approach for CrewAI. Tracing is opt-in and agents continue if it is unavailable, keeping the telemetry path from becoming a hard availability dependency.

The caveat is volume: multi-agent chains can generate substantial trace data, and poorly chosen timeouts can affect user-facing latency. Red Hat recommends beginning with AgentCards for immediate discovery value, automating the route-to-card deployment sequence and adding stronger identity and authorization controls as risk grows.

That incremental advice matters. The guide explicitly says the full stack may be excessive for an isolated agent; its value emerges when multiple teams own agents, dependencies cross boundaries, or compliance and semantic debugging justify a shared operating layer. A linked starter-kit template provides the concrete Rossoctl registration and MLflow-tracing example for teams ready to test the pattern.