Modern Kubernetes Is the Agentic Substrate
For ten years, every platform company sold the same deal: "we hide Kubernetes, so you don't have to." Run your app on our abstraction. Click deploy. Never see a YAML. It was a good deal — Kubernetes is genuinely hard to operate by hand, and most teams wanted to ship software, not run a control plane.
That deal carried a hidden term: somebody still operates Kubernetes. The platform vendor does — behind your back, on their cloud, under their pricing, inside their roadmap. You get the benefits of GitOps and containers and autoscaling without the surface area. That trade only makes sense if the person who'd otherwise touch that surface area is a human developer who doesn't want to.
Remove that assumption and the whole deal collapses.
Two worlds
There are now two worlds, and the gap between them is the entire bet.
World 1 — "Kubernetes made easy." A PaaS sits on top of Kubernetes, owns the manifests, runs GitOps on your behalf, and hands you a friendly console. Take Qovery: by their own positioning they're "built on top of GitOps principles" and "automate the creation and management of Kubernetes manifests." They even wire in ArgoCD — but as a managed integration, not a primitive you reach for. You get the outcomes of GitOps. You don't get GitOps.
World 2 — "agents made capable of Kubernetes." No abstraction layer that
hides the substrate. Instead, the substrate is exposed as a clean, inspectable,
machine-readable surface — and an agent operates it directly through a CLI. Not
a human typing kubectl until they cry. An agent that reasons about Helm charts,
reconcilers, and policies the way a senior platform engineer would, at machine
speed.
The first world assumes the operator is a human who needs shielding. The second assumes the operator is an agent that needs surface area.
What you trade away when you abstract it
"Hide the complexity" sounds free. It isn't. Abstract Kubernetes and you lose direct ownership of the exact things that matter once an agent is doing the operating:
| Primitive | What you lose when it's abstracted away |
|---|---|
| Flux / ArgoCD | A reconciler you can inspect and modify — desired vs. actual state, visible and intervenable |
| Helm charts | First-class, versioned, reusable artifacts instead of opaque vendor bundles |
| Registries & promotion | Image flows you control — build, scan, sign, promote across environments |
| NetworkPolicy, ResourceQuota, Gateway API, egress | The actual isolation, policy, and traffic knobs — not a vendor's approximation |
| Operators & CRDs | The standard extension model — the ability to teach the cluster new tricks |
A PaaS gives you the result of each row without the knob. That's the right call when you don't want the knob. It's the wrong call when your agent could turn that knob for you — better and faster than a vendor's one-size console ever could.
One line captures it: Qovery gives you GitOps benefits without GitOps surface area. Kilter gives you GitOps surface area.
Why now — the substrate converged
None of this worked five years ago. Operating Kubernetes by hand meant choosing a CNI, an ingress controller, a policy engine, a delivery tool, a secret store — a dozen independent, half-compatible decisions, none of them canonical. The reason a PaaS abstraction won is that raw Kubernetes had no canonical shape.
It does now. The stack converged:
- Cilium is becoming the default — CNI, service mesh, and network policy in one eBPF layer, instead of three competing components.
- Gateway API replaced the ad-hoc ingress zoo with one standard, role-oriented traffic model.
- GitOps — Flux or ArgoCD — is the settled delivery model. Nobody argues push-vs-pull anymore.
- Operators and CRDs are the standard extension mechanism. Want the cluster to understand a new resource? Write an operator, not a vendor integration.
For the first time there's a canonical Kubernetes — a stack you can assume, that looks the same from one cluster to the next, that an operator (human or agent) can reason about without re-deriving the whole architecture each time.
The agent is the missing operator
Here's the piece that flips the table.
For a decade the argument for abstraction was: Kubernetes is too complex for the developer to operate, so hide it. True — when "operate" meant a human reading docs and typing commands.
Not true when "operate" means a capable agent reasoning over a clean, canonical, machine-readable surface. Claude-4.5-class models don't need the complexity removed. They need it exposed, structured, and inspectable, so they can drive it the way a senior engineer would: discover what exists, compose a change, validate it, ship it.
That's what a CLI like Kilter's is for — not to hide Kubernetes, but to make it drivable:
Notice what the agent is touching: the real substrate. Flux underneath. Helm charts as artifacts. NetworkPolicy and quotas as actual knobs. Nothing hidden, nothing re-approximated — because the thing operating it can handle the real thing.
The real bet
So this isn't "Kubernetes made easy." That's World 1, and Qovery lives there, honestly and well.
Kilter is betting on World 2: agents made capable of Kubernetes. The developer stops being the operator — the agent is — and once the operator is an agent, the thing it needs is not a smaller abstraction. It's the full, converged, inspectable substrate, delivered through a surface it can actually drive.
The PaaS existed to stand between a confused human and a hard system. The confused human is no longer in the loop. The hard system grew a canonical shape. Both halves of the old deal just evaporated.
Where to go next
- Read how to build an enabling agentic substrate — the layered build guide that stands on this foundation.
- Start from the k8gentic manifesto — why real infrastructure has to live under the agents.
- See the Kilter Platform — the canonical stack, composed.
- Start your free trial — the full platform, 7 days, no card.