Project Navigator for AI Deployment Ops
AI platform work often looks simple until the model has to serve real traffic. Teams pick a model, reserve GPUs, tune batch sizes, add autoscaling, wire metrics, and then discover the deployment is slower or more expensive than expected. Red Hat's Project Navigator points at a more operator-friendly workflow.
What Is Project Navigator?
Project Navigator is a developer preview capability in OpenShift AI 3.4. It connects to a cluster, inspects available models and hardware, and helps teams move from an AI intent to a deployable configuration.
The important part for operators is that it works against real cluster context. Teams describe the workload they want to run, then Navigator recommends models and deployment settings based on benchmarks, catalog data, hardware availability, and latency or concurrency targets.
Why SRE Teams Should Care
AI workloads create familiar reliability problems with less familiar failure modes. A model that looks good in a benchmark can be a poor fit for production if it wastes GPU memory, misses latency targets, or requires manual tuning every time traffic shifts.
Navigator focuses on two operational questions:
- Which model is good enough for this workload without wasting expensive accelerators?
- Which Kubernetes configuration gives the service a realistic chance of meeting demand?
That framing moves AI deployment away from leaderboard-driven decisions and toward evidence-based operations.
Deployment Output
According to Red Hat, Navigator can generate Kubernetes resources tailored to the cluster, including:
- A KServe
InferenceServicefor serving the selected model - Resource requests and limits sized for the available hardware
- A
HorizontalPodAutoscalerfor scaling behavior - A
ServiceMonitorfor Prometheus-based observability
Those are exactly the surfaces SRE teams need to review before production. The generated output is not a replacement for change control, load testing, or rollback planning, but it is a stronger starting point than hand-tuned defaults.
MCP in the Workflow
Project Navigator is also built around Model Context Protocol integration. That means engineers can use it from tools such as Claude Code, Cursor, or Gemini CLI as MCP adoption grows.
For SRE teams, this is the pattern to watch: AI assistants become more useful when they can query live platform context through scoped tools. The agent should see the real environment, but access should be narrow, auditable, and tied to clear operator intent.
Operational Tips
Treat Navigator-style recommendations as reviewable infrastructure changes. Store generated manifests in Git, run policy checks, and compare GPU, memory, and autoscaling settings against historical production traffic.
Keep a small catalog of approved model profiles. If teams know which model families are supported for low-latency chat, batch summarization, code assistance, or internal RAG, operators can reduce one-off tuning work.
Add observability before the service goes live. Track request rate, error rate, latency, GPU utilization, memory pressure, queue depth, and model saturation.
Conclusion
Project Navigator is interesting because it treats AI deployment as an operations problem, not just a model selection problem. The value is connecting model choice, cluster capacity, Kubernetes manifests, and observability into one workflow.
If your team is building AI services on Kubernetes, this is the direction to plan for: assistants that understand platform state, generate reviewable changes, and leave SREs in control of production risk.
Need AI agents that help SRE teams investigate incidents and automate operational workflows? Akmatori is an open-source AI agent platform for on-call teams. For high-performance infrastructure, explore Gcore, a global edge and cloud provider built for demanding workloads.