Agents are just workloads — Kubernetes discipline applies

Strip away the vocabulary and an AI agent is a workload: bursty, resource-hungry, somewhat stateful, occasionally long-running. The agent-infrastructure industry is busy building bespoke schedulers, bespoke isolation, and bespoke fleet management for it — and most of that effort is reinvention, because platform engineering already owns this problem. Before an "agent infra" purchase or build, my first question is now: which Kubernetes primitive is this repackaging?

Run down the requirements list and the mapping is nearly one-to-one. Agent fleets need fair resource sharing across teams — that's ResourceQuota and LimitRange, and at fleet scale it's batch-scheduler queues with weights, hard capability ceilings, and dominant-resource fairness across CPU, memory, and GPU. Multi-agent jobs need all-or-nothing placement — that's gang scheduling, which exists precisely because a distributed job holding seven of eight required slots deadlocks the cluster while starving everyone else. Agents need isolation proportionate to their privileges — that's Pod Security Standards, RBAC, and zero-trust NetworkPolicy, a graduated hardening stack refined over a decade. Inference pods need probes that understand that "container started" is not "model loaded" — the readiness-probe discipline for slow-warming services, applied. Spiky agent traffic wants scale-to-zero and event-driven activation. GPU efficiency wants MIG partitioning, time-slicing, and binpacking against fragmentation. None of this is agent-specific. All of it is production Kubernetes, documented, battle-tested, and hiring-market-available.

The serverless corner makes the same point from the opposite direction. Lambda's fifteen-minute ceiling forces long-running agents to decompose into chained invocations that checkpoint state and re-enqueue — and state externalisation, the non-negotiable enabling pattern of serverless, is exactly the discipline agents needed anyway: state in Redis or DynamoDB, artifacts in object storage, nothing precious inside the process. Teams resent the constraint until they notice it forced them to build resumable agents. The platform's limits imposed the architecture the workload should have had.

The cost of ignoring all this is not hypothetical. Teams that treat agent deployment as a novel problem hand-roll a Python orchestrator that schedules agents onto VMs, then over the following year rediscover — via incidents — why quotas exist, why noisy neighbours need isolation, why health checks must reflect actual readiness, and why unbounded retry storms take down shared dependencies. They are speedrunning 2015's outages with a 2026 workload. The boring alternative — containerize the agent runtime, declare its resources, let the scheduler schedule — inherits ten years of operational hardening for the price of a Dockerfile.

The concession, and it's a real one: the genuinely novel part of the agent workload is invisible to the platform. The kubelet can see an OOM kill; it cannot see coherence collapse. The scheduler can enforce a CPU quota; it cannot enforce a token budget, because the meter lives at the API gateway, not the cgroup. And the failure modes that matter most are semantic — an agent confidently doing the wrong thing is "healthy" by every probe it will ever answer. Kubernetes governs the substrate, not the semantics; the eval gates, trajectory observability, and cost governance have no platform primitive and must be built at the agent layer.

But that division of labour is the argument, not an exception to it. Spend your novel engineering exclusively on the semantic layer — where agents genuinely are new — and refuse to rebuild the substrate, where they aren't. Agents are just workloads. Treat them like it, and save the invention for the part that needs it.