The Rise of AI-Native Platform Engineering

Almost every developer has a local AI coding harness now. It writes code, suggests fixes, scaffolds features. It feels fast and capable inside that sandbox. Then someone asks about running it against a production Kubernetes cluster, and the room gets quiet.

That hesitation is well-founded. The gap between "AI-native on my laptop" and "AI-native in production" is real, and you can see it most clearly in how developers actually work today. AI tools have made generating code dramatically easier, but the moment that code is ready to ship, the workflow goes manual again (tickets, YAML edits, portal clicks, pipeline triggers). The agent that felt smooth and capable in the editor suddenly has nothing it can safely touch once infrastructure is involved. And that's just the deployment problem. Underneath it sit harder ones: agents reasoning over raw Kubernetes YAML are expensive and unreliable, broad local credentials mean an agent is one prompt away from touching the wrong thing in production, and nobody has quite figured out how ops and SRE work changes when agents start doing some of it. Platform engineering is still maturing as a discipline, adding AI autonomy on top of practices that aren't fully settled yet feels risky to most teams, and for good reason.

A recent conversation hosted by Bret Fisher featuring Lakmal Warusawithana and Sameera Jayasoma, core maintainers of OpenChoreo, explored exactly these problems. The conversation was about working through what it actually takes to run AI agents safely in infrastructure; what's ready, what isn't, and what patterns help.

OpenChoreo, a CNCF Sandbox project donated by WSO2, was the working example throughout: a Kubernetes-based platform layer built to give developers, platform engineers, SREs, and AI agents a shared, governed interface to infrastructure.

The abstraction problem

Many internal developer platforms assemble Kubernetes, CI/CD, GitOps, observability, networking, autoscaling, and policy tools, then place a portal on top. But if that portal simply exposes Kubernetes in a nicer interface, the complexity hasn't disappeared, it's just been repainted. Developers still need to understand YAML, deployment strategies, networking, scaling, and a long list of platform-specific details.

Agents have the same problem. If an agent has to reason over raw Kubernetes primitives; kubectl, CRDs, networking rules, observability config, the context window bloats, prompts get expensive, and reliability drops. This is a big part of why production AI-native infrastructure still feels out of reach for most teams: the native vocabulary of Kubernetes is just too low-level for agents to work with cheaply and reliably.

The solution, whether you're building for humans or agents, is the same: raise the level of abstraction. Instead of exposing infrastructure primitives, expose intent. Give developers and agents a vocabulary that maps to what they're actually trying to accomplish; deploy this, promote that, connect these two services and let the platform handle the translation underneath. This is what the better internal developer platforms are moving toward, and it's the same principle that makes AI agents viable in production rather than just in a sandbox.

OpenChoreo's approach is a middle abstraction layer. Developers and agents both work with higher-level concepts: projects, components, environments, releases. They express intent like "deploy this component," "promote to staging" and the control plane handles the translation into whatever Kubernetes and platform resources are actually needed. Platform engineers still control the implementation underneath. The higher-level vocabulary just gives both humans and agents something more meaningful to work with.

The practical payoff for agents: fewer tokens, clearer reasoning, more predictable behavior, lower cost. It's the difference between writing in assembly and writing in a higher-level language, same machine underneath, but the cognitive and computational overhead drops significantly.

The customization dilemma

Abstractions are appealing in theory, but platform engineers have a legitimate worry on the other side. Kubernetes became the default infrastructure substrate precisely because of how much control it gives you. Most platform teams have spent years tuning that environment; networking, scheduling, scaling, security policies to fit their specific needs. That's not accidental complexity, that's craft. The last thing they want is an abstraction layer that quietly trades away that control for the sake of simplicity.

And then there's the agent problem on top of that. Even if you're comfortable with the abstraction, are you comfortable with an agent making decisions inside a system you've spent years carefully calibrating? One that doesn't know why you made the choices you did?

So the dilemma is real: you need abstractions to make agents reliable and cost-effective, but you don't want abstractions that box you in. And you don't want to hand an agent a set of keys that gives it the run of a system your team has been quietly perfecting since before AI agents were a thing anyone worried about.

OpenChoreo's answer to this is a multi-plane architecture. The idea is to separate concerns cleanly enough that you can apply the right level of governance at each layer, without collapsing everything into a single opinionated stack you can't see inside. The control plane is the center of gravity; it's where developers, platform engineers, SREs, and agents all interact with the system, and where governance and policy get enforced. The data plane handles runtime and networking (Cilium, KEDA, API gateways, network policies). The build plane takes care of CI-related work via Argo Workflows and Buildpacks. The observability plane covers logs, metrics, traces, and alerting through tools like Prometheus, OpenTelemetry, and OpenSearch. And the experience plane is the outermost layer – the Backstage-powered portal, MCP servers, APIs, and CLI that both humans and agents actually talk to.

The important thing here for platform engineers: none of this forces you to replace the tools you're already running. OpenChoreo sits on top of whatever Kubernetes environment you have - EKS, AKS, GKE, Rancher, doesn't matter. The tools in each plane are the ones many teams already use. What OpenChoreo adds is a consistent abstraction and governance layer above them, so there's one place where access, policy, and intent get managed, regardless of what's running underneath.

Figure 1: OpenChoreo architecture

Agents as governed users, not privileged actors

Even if you've solved the abstraction problem, there's a harder question sitting underneath it: how much do you actually trust an agent to act inside your infrastructure? And the honest answer for most teams right now is: not much. Not because the technology isn't capable, but because trust has to be earned, and agents don't have a track record yet. Give an agent too much access too soon and you're not running AI-native infrastructure, you're just running a faster way to make a mistake.

The real risk isn't the agent doing something malicious. It's the agent doing something reasonable that turns out to be wrong for reasons it had no way of knowing, e.g., a config change that conflicts with a decision made six months ago or a deployment to the wrong environment because the credentials in scope were too broad. Most developers already have wide-open local credentials covering AWS, Kubernetes, GitHub, and production. An agent running in that context inherits all of it by default.

The solution most teams are landing on is treating agents the same way you'd treat a new engineer on their first week: scoped access, defined responsibilities, and a clear audit trail of everything they touch. You don't give a new hire the root password. You give them what they need to do their job, watch what they do with it, and expand access as trust develops.

OpenChoreo makes this explicit in two ways. First, agents aren't a special privileged class; they're treated as another type of platform user, subject to the same golden paths, guardrails, and role-based access as any human. A super-admin agent persona might have access to 120+ control plane tools through MCP. A developer agent gets a scoped-down set (inspect components, deploy to dev environments). An SRE agent can query logs, metrics, and service health. The scope matches the role, and every action is auditable. When something goes wrong, you can see exactly what the agent did, through which tools, and when.

Second, OpenChoreo can act as a gateway for the local credential problem specifically. Instead of an agent inheriting whatever broad credentials exist in a developer's local environment, OpenChoreo exposes only the MCP tools and permissions appropriate for the specific environment and role with separate scopes for dev, staging, and production. The agent only sees what it's supposed to act on.

Start narrow: Purpose-built agents over general-purpose ones

One of the more counterintuitive lessons from teams that have actually deployed agents in infrastructure: the most useful agents aren't the most capable ones. They're the most focused ones.

A general-purpose agent with broad access to your infrastructure sounds powerful, but in practice it's hard to reason about, expensive to run, and difficult to trust. You never quite know what it might decide to do with the context it has. A purpose-built agent with a specific job (such as investigate this class of alert, analyze cost patterns in this environment, and reason about service dependencies) is cheaper, more predictable, and much easier to audit.

OpenChoreo ships with exactly this kind of specialized agent lineup. The SRE agent only deals with operational alerts and incident investigation. The FinOps agent only looks at cost patterns and resource usage. The architecture agent only reasons about service structure and dependencies. Each one has a narrow scope, a defined set of tools it can reach, and a clear idea of what success looks like. That narrowness isn't a limitation, it's the point.

Figure 2: AI integration in OpenChoreo

There's a practical question sitting underneath all of this: do you build your own agents, or do you start from ones someone else has already figured out? Building your own gives you full control over behaviour and scope, but it also means owning the prompt engineering, the testing, the edge cases, and the ongoing maintenance as your infrastructure evolves.

Starting from purpose-built agents that ship with the platform, like the ones OpenChoreo provides, means you're building on top of something that has already been tested against real operational scenarios. You still configure them, scope their access, and decide how much autonomy they get. But you're not starting from zero.

For most teams, the right answer is probably both: start with platform-provided agents to build confidence and understand the patterns, then build custom agents for the workflows that are specific to your environment. The important thing is not to let the "build everything ourselves" instinct slow you down from getting started.

One thing worth emphasizing above everything else: none of this removes humans from the equation. The goal isn't autonomous infrastructure; it's infrastructure where agents do the time-consuming, context-gathering work so engineers can make better decisions faster. The agent investigates; the human decides. That division of labour is what makes AI-native platform engineering trustworthy rather than just fast.

Where to go from here

The shift to AI-native platform engineering isn't coming. It's already underway. The teams feeling it most acutely are the ones who have already built serious internal platforms and are now asking what it means to let agents operate inside them. The answer, based on the experience shared in this conversation, isn't to slow down or wait for the tooling to mature further. It's to build the right foundations now: clean abstractions, scoped permissions, audit trails, and a culture of earned autonomy rather than assumed trust.

The teams that get this right won't necessarily be the ones with the most sophisticated agents. They'll be the ones who built the platform carefully enough that agents had something solid to stand on.

If you want to see these principles in action, OpenChoreo is a good place to start. It's one of the more serious early attempts to build a platform with AI-native operations in mind from the ground up rather than as an afterthought. You can try the quick start guide, star and contribute to the repository, join the OpenChoreo Slack channel, or weigh in on where the project is headed via GitHub Discussions.