Platform engineering for the agentic enterprise: how to manage applications, resources and AI agents

The article, written by Lakmal Warusawithana (WSO2) and published on the CNCF blog, argues that the discipline of platform engineering —born to tame the complexity of Kubernetes, microservices, GitOps and distributed architectures— now faces a fundamental shift: AI agents are moving from being mere tools to becoming full-fledged consumers of internal developer platforms (IDPs), on the same level as human developers.

The text recalls the origins of IDPs: instead of requiring every development team to master deployment, infrastructure, networking, security, observability and compliance, platforms packaged those practices into self-service workflows, standardized environments and "golden paths," over time integrating CI/CD, GitOps, policy enforcement and governance into a unified operating model. That model worked very well, but it started from an implicit assumption: the platform's primary user was always a human.

According to the author, that assumption no longer holds. AI agents provision infrastructure, deploy applications, investigate incidents, analyze telemetry, invoke operational workflows and automate tasks that previously required human intervention. As a result, the platform ceases to be exclusively "for developers" and becomes the shared operational foundation through which developers, platform engineers, SREs and AI agents build, operate and continuously improve enterprise software.

The central concept the article proposes is that of the "Agentic Enterprise," which is not defined simply by the presence of AI agents, but by a simultaneous change along two dimensions: what the platform manages and whom it serves. On one hand, enterprise software is no longer composed solely of applications (APIs, microservices, event-driven systems, web applications, integration services); AI agents now become active participants in that ecosystem, collaborating with applications, consuming and managing resources, coordinating deployments and enforcing policies. On the other hand, the platform itself must offer interfaces designed for both humans and AI agents, granting each actor its own identity, scoped permissions and a clear audit trail, so that a developer using a portal, an SRE using CLI/GitOps and an AI agent invoking an MCP server are all governed under the same security controls and the same policy guardrails.

From there, the article introduces three categories of "first-class software assets" that the platform must understand and manage. Applications remain the center of business value delivery: they implement logic, expose APIs and process events. Resources —databases, messaging systems, object storage, AI models, identity providers, secrets, Kubernetes clusters, SaaS services and runtime environments— cease to be treated as mere infrastructure details and become platform objects with their own lifecycle, ownership, governance and operational history. And AI agents are described as a fundamentally different type of software actor: they do not implement business logic directly, but rather reason about context, invoke tools, collaborate with humans and with other agents, and automate operational activities.

The key idea the author emphasizes is that these three entities are not independent of one another: applications consume resources to deliver business capabilities, AI agents consume many of those same resources to understand and operate the system, and at the same time they interact with the applications, while these expose capabilities that agents can invoke. Resources thus become the common connection point between applications and agents. This shifts the focus of platform engineering: it is no longer enough to manage software components in isolation; one must understand the relationships and dependencies between them, and how changes propagate throughout the entire system.

A central section of the article argues that "context" is becoming a first-class platform capability. Traditional observability systems (logs, metrics, traces, events) are descriptive: they tell you what happened, but rarely explain why it happened or how one event relates to another. Experienced engineers, when investigating incidents, naturally combine deployment history, ownership, topology, dependencies, operational policies, prior incidents and organizational knowledge to build a complete understanding of the system. The article maintains that AI agents need exactly that same capability: an agent investigating a failed deployment needs to know which application owns that deployment, which resources it depends on, what has changed recently, who is responsible for those resources, which policies apply and whether there have been similar incidents before. Without that broad context, even the most capable AI model is limited to reasoning about disconnected observations.

For that reason, according to the text, modern platforms must build and maintain a shared model of understanding of the entirety of enterprise software, connecting applications, resources, AI agents, deployments, ownership, policies, topology, operational history and organizational knowledge into a coherent representation on which both humans and agents can reason. Once the platform becomes "context-aware," it can expose that knowledge through the interfaces appropriate for each consumer: portals, CLIs, APIs or dashboards for humans, and protocols such as MCP (Model Context Protocol) for AI agents, all of them representing the same underlying understanding of the system. This contextual foundation, according to the article, also enables additional capabilities such as reusable "skills" that encapsulate common engineering tasks invocable by humans and agents alike, and built-in agents specialized in domains such as site reliability (SRE), security, compliance or FinOps, all operating on the same contextual model to collaborate consistently.

As a practical example of these ideas already in motion, the article presents OpenChoreo, a CNCF Sandbox-stage project, which as described maintains everything expected of a modern IDP (CI/CD, GitOps, policy enforcement, self-service) using Kubernetes as its system of reference, so that every platform abstraction reflects the actual runtime state rather than introducing a separate control plane. What changes, the author notes, is not only what the platform manages but whom it serves: OpenChoreo is designed for human users and AI agents alike, so that developers, platform engineers and SREs continue to use portals, CLIs, APIs and GitOps workflows, while AI agents access the same platform through MCP servers, all on the same underlying understanding of applications, resources, relationships and operational state. In this model, resources (databases, messaging, object storage, APIs, AI models, secrets, identity providers, external services) are modeled as managed platform objects, with their own lifecycle, ownership, governance and relationships, rather than being treated as simple infrastructure details. The article also mentions that OpenChoreo is designed as an extensible platform through an ecosystem architecture, in which new functionality is incorporated via ecosystem modules that can expand the capabilities of applications; the available content cuts off at this point, right as it begins to detail those modules, so it is not possible to specify here what concrete capabilities they add.

Taken together, the article's argument is not that platform engineering must be reinvented from scratch, but that it must be extended: keeping its cloud-native foundations (Kubernetes, GitOps, self-service, governance) while incorporating AI agents as manageable software actors and as legitimate consumers of the platform, and while turning operational context —the relationships between applications, resources and agents— into the piece that allows humans and machines to reason and act coherently on the same system.