OpenShift AI’s workflow navigator turns inference requirements into deployment options

Red Hat has put a developer preview of workflow navigator into OpenShift AI, aiming to replace model-serving guesswork with a requirements-driven planning flow. The tool accepts a natural-language description of a workload, considers available models and cluster hardware, and returns ranked deployment options before generating Kubernetes configuration. The useful idea is not simply “AI manages AI”; it is that latency, capacity and cost constraints become inputs to a reviewable deployment plan.

What the workflow does

In Red Hat’s engineering post, a user can specify a workload such as a retrieval-augmented generation application, expected concurrency and a latency target. Workflow navigator then filters model choices against available hardware, consults benchmark data and compares candidate configurations. Its output can include KServe InferenceService YAML, resource requests, autoscaling rules and observability configuration.

The planning layer comes from the open source llm-d Planner. Its current workflow translates business requirements into traffic profiles and service-level objectives, queries matching benchmark records, estimates missing combinations, filters options by latency and ranks the survivors across quality, cost and latency. The planner can also calculate model-weight, KV-cache, activation and system-overhead memory, then estimate time to first token, inter-token latency and throughput across GPU types.

That distinction matters: the project labels results derived from benchmarks separately from estimated performance. Platform teams should preserve that distinction in reviews rather than treating every recommendation as measured fact.

The control surface is MCP

Workflow navigator uses the RHOAI MCP server as its programmatic control surface. The server exposes OpenShift AI operations for projects, workbenches, model serving, data connections, pipelines, storage and training. Its repository also documents an OpenShift deployment overlay with a TLS route, RBAC and a network policy.

The MCP server includes several safeguards worth checking before a trial: destructive operations are disabled by default, deletion tools require confirmation, a read-only mode can disable writes, and workflow tokens can enforce the ordering of multi-step calls. Authentication can use in-cluster credentials, kubeconfig or an explicit token, so the effective permissions still depend on the identity supplied to the server.

What to test before adoption

This is a developer preview, not a reason to skip capacity testing. Teams evaluating it should begin with a representative workload and compare the recommended configuration against a measured baseline. Check whether the selected result is benchmark-backed or estimated, validate generated resource limits and autoscaling behavior, and review the service account, route and network-policy scope before allowing writes to a shared cluster.

There are also explicit boundaries in the planner’s roadmap. Its repository lists security hardening, finer vLLM parameter search and prefill/decode disaggregation among future enhancements. For now, the strongest use is as a planning assistant that narrows the test matrix and produces an auditable starting configuration—not as an unattended authority over production inference.