Kubernetes namespaces are a useful boundary, but they are not a complete multi-tenancy model. This becomes painfully visible when teams start sharing AI infrastructure, with different expectations around latency, cost, fairness, isolation, and scarce resources.

The hard part is not creating separate spaces for teams. The hard part is deciding what happens when those teams compete for the same accelerators, model endpoints, sandboxes, network paths, and latency budgets. Some workloads can wait in a queue or be safely preempted. Others need stronger guarantees. Agentic workloads add tool calls, model calls, memory stores, browser or code sandboxes, external APIs, and human-facing latency. Inference workloads add another twist, especially when patterns such as prefill/decode disaggregation make placement, locality, and capacity planning part of the serving path.

In this talk, we will look at why “one namespace per team” is not enough for multi-tenant AI platforms on Kubernetes. We will discuss hierarchical queues, PrioriyClasses, preemptable and non-preemptable workload classes, topology-aware scheduling, sandboxed execution, GPU scarcity, inference placement, and the operational limits of namespace-based isolation. Along the way, I will share the pitfalls we found ourselves in, and the questions that would have helped earlier: how to think about fairness before and after the cluster is full, how to separate workload guarantees before users lose trust, how to reason about topology before latency becomes mysterious, and what users need to understand when the platform says “not yet.”