The claim: agents are platform consumers now
On July 21 the CNCF published a piece by Lakmal Warusawithana of WSO2 arguing that platform engineering has to absorb a new kind of user. Internal developer platforms were built to serve human engineers through portals, CLIs, and self-service workflows. The argument is that AI agents are becoming consumers of those same platforms, issuing the same kinds of requests to deploy, query, and operate software, and that the platform must now serve both humans and intelligent software as first-class citizens. It is a vendor-authored thesis, tied to WSO2's CNCF Sandbox project OpenChoreo, and the underlying observation is worth taking seriously on its own terms.
The framing lands because it matches what many organizations are already stumbling into. Teams are wiring coding agents and operational agents into their infrastructure through MCP servers and API tokens, often without deciding how those agents fit the platform model. Warusawithana's proposal is to treat applications, resources, and AI agents as three interconnected classes of first-class entity managed together, instead of letting agent access grow as a pile of one-off integrations bolted onto the side. That is a useful lens for any platform lead watching agent usage climb inside their environment.
Context is the part that is genuinely hard
The strongest idea in the piece is that context is the foundation. An experienced engineer investigating an incident draws on a mental model of ownership, topology, dependencies, and operational history to reason about what is happening. The argument is that an AI agent needs that same context to act usefully, and that most platforms do not expose it in a coherent, queryable form. Building that shared understanding, connecting who owns what, how services depend on each other, and what has happened operationally over time, is the real work, and it benefits human engineers whether or not you ever attach an agent to it.
This is where we would push leaders to focus, because it inverts the usual order of an AI project. The instinct is to add an agent and then figure out what it can see. The more durable move is to invest in the context layer first, since a service catalog with accurate ownership, dependency mapping, and operational history is valuable to your engineers today and becomes the substrate an agent needs tomorrow. Organizations that already run a mature internal developer portal have a head start. Those that do not will find that agents amplify the cost of missing context rather than papering over it.
Extend the platform, do not fork a separate AI stack
The central recommendation is architectural discipline: extend your existing cloud-native platform to support agents rather than standing up a separate AI-specific platform beside it. The reasoning is that a parallel stack duplicates governance, security, and observability, and creates two sources of truth that inevitably drift apart. Keeping agents on the same platform that already runs your applications means one set of controls, one catalog, and one operational model covering both populations. For anyone who has watched a shadow platform grow up around a new technology and then spent years reconciling it, the caution rings true.
The counterweight to note is the source. This is a member post promoting a specific project's worldview, and OpenChoreo is an early CNCF Sandbox effort rather than a proven default. The principle, avoid a second control plane, is sound and vendor-neutral. The specific tool is one option among several, and platform leads already invested in Backstage, Port, Humanitec, or a homegrown platform should read the architecture argument as guidance for extending what they run, not as a prompt to adopt a new project. The value is in the model, and the model does not require this particular implementation.
Kubernetes stays the system of record
A concrete piece of the proposal is that Kubernetes remains the system of record, and that agent capabilities should extend it rather than introduce an independent control plane. This is the same instinct that made Kubernetes the substrate for so much platform tooling in the first place: a single declarative source of desired state that everything else reconciles against. Routing agent actions through that existing control plane means an agent-initiated change is subject to the same admission control, the same policy engine, and the same audit trail as a change made by a human or a pipeline. Consistency at that layer is what keeps the system reviewable.
For platform teams, this is reassuring because it means the agent question does not demand a new foundational technology. The Kubernetes-centric platform you have already built is the right place to attach agent capabilities, provided you extend it deliberately. The failure mode to avoid is an agent that reaches around the control plane to mutate infrastructure through side channels, because that is how you lose the guarantees the platform exists to provide. Keeping every actor, human or machine, on the same declarative path is the discipline that makes agent operations auditable instead of chaotic.
Governance parity is the operational core
The most immediately actionable idea is that governance, security, and observability should apply identically across human and AI interactions. An agent that can deploy a service should be subject to the same access controls, leave the same audit trail, and appear in the same observability tooling as the engineer who could deploy it. This is the practical heart of the argument, and it is where most current agent integrations fall short. Agents are frequently granted broad tokens, act outside the normal review path, and produce actions that are hard to attribute after the fact. That gap is a governance liability that grows with every agent you add.
We would treat parity as the near-term priority regardless of which platform philosophy you adopt. Before scaling agent usage, make sure an agent's identity is distinct and scoped, that its actions are logged and attributable, and that it cannot exceed the permissions a human in the same role would hold. Those controls are achievable today with the identity and policy tooling most Kubernetes platforms already run. Getting them right is what separates an agent program you can put in front of an auditor from one that becomes a finding in your next security review.
What platform leads should take from it
Strip away the vendor framing and the piece offers a clear roadmap signal. AI agents are becoming platform consumers whether or not you have planned for them, and the organizations that handle it well will be the ones that extended a coherent platform to accommodate them rather than accreting one-off integrations. The prerequisites, a real service catalog, accurate ownership and dependency data, consistent policy enforcement, and scoped identities, are things a strong platform team should be building anyway. Agents raise the return on that work and raise the cost of skipping it.
The action for a platform lead is to audit where agents already touch your environment and to hold those touch points to the same standard as human access. Then invest in the context layer, ownership, topology, and operational history, because that is the durable foundation both your engineers and any future agents will draw on. Skip the temptation to build a separate AI platform, and resist adopting a specific new project just because a post recommends it. The principle is sound and portable, and the right implementation is the one that extends the platform your teams already trust.
