Running AI agents on Kubernetes requires more deliberate infrastructure design than typical web services due to GPU scheduling, long-lived sessions, broad credential surfaces, and complex RBAC needs. The post surveys the 2026 agentic Kubernetes ecosystem (kagent, KServe, Kueue, KubeRay, NVIDIA GPU Operator) and shows how to provision a GPU-enabled EKS cluster, install kagent via Helm, manage model provider secrets with Pulumi ESC, and declare agents as versioned custom resources — all in both TypeScript and Python. It argues for general-purpose languages over templated YAML for composing, testing, and governing agent infrastructure, and explains how Pulumi Policies enforce least-privilege and cost guardrails. Pulumi Neo is positioned as an infrastructure-layer agent that proposes and reviews changes to the cluster itself, operating above workload-level agent frameworks like kagent.

13m read timeFrom pulumi.com
Post cover image
Table of contents
What makes agentic AI workloads different from ordinary Kubernetes workloads?What does the agentic Kubernetes stack look like in 2026?How do you provision Kubernetes infrastructure for AI agents with Pulumi?Why write agent infrastructure in a general-purpose language instead of templated YAML?How do you keep agent workloads governed, least-privileged, and cost-aware?Where does Pulumi Neo fit when the infrastructure itself is agentic?Frequently asked questionsWhere to go next
169 Impressions