Posted on July 21, 2026 by Lakmal Warusawithana, WSO2

CNCF projects highlighted in this post

OpenChoreo logo

Platform engineering is evolving

Platform engineering has become one of the defining disciplines of the cloud native era. As organizations embraced Kubernetes, microservices, GitOps, and distributed architectures, the complexity of building and operating software grew beyond what individual development teams could reasonably manage. Every application required deployment pipelines, infrastructure provisioning, networking, security, observability, compliance, and operational expertise. While each capability was valuable, expecting every development team to master all of them quickly became unrealistic.

Internal Developer Platforms (IDPs) emerged to address this challenge. Rather than asking every team to build its own operational tooling, platform engineering teams created shared platforms that encapsulated best practices behind opinionated workflows, self-service capabilities, standardized environments, and golden paths. These platforms enabled developers to focus on delivering business functionality while the platform consistently handled deployment, security, governance, and operations. Over time, they evolved far beyond deployment automation, integrating continuous delivery, GitOps, observability, policy enforcement, governance, and developer experience into a unified operating model.

That model has been enormously successful, but it was built around a fundamental assumption: the primary consumer of the platform is a human developer. Developers use the platform to provision environments, deploy applications, consume resources, and operate software, while the platform abstracts away much of the underlying complexity.

The Agentic Enterprise changes that assumption.

Increasingly, AI agents are becoming consumers of the platform alongside human engineers. They provision infrastructure, deploy applications, investigate incidents, analyze telemetry, invoke operational workflows, interact with enterprise resources, and automate tasks that previously required human intervention. Rather than serving only developers, the platform must now serve both humans and intelligent software, each interacting through interfaces appropriate to their capabilities while operating under the same governance model.

This shift is about much more than exposing APIs to AI. It fundamentally changes what the platform is responsible for. Instead of acting solely as a developer platform, it becomes the operational foundation through which developers, platform engineers, SREs, and AI agents build, operate, and continuously improve enterprise software.

At the same time, the software being managed is evolving as well. Applications remain central to delivering business value, but they are no longer the only software assets the platform understands. Resources become first-class platform objects, and AI agents become first-class software actors that interact with both applications and resources.

The next evolution of platform engineering is therefore about extending the existing platform so it can support both humans and AI agents as first-class consumers, enabling them to collaboratively build, operate, and govern applications, resources, and AI agents within a unified operational model.

The agentic enterprise

Much of today’s industry discussion focuses on AI agents themselves—how to build them, orchestrate them, or connect them to large language models. While these are important developments, they represent only one aspect of a much broader transformation.

The Agentic Enterprise is not defined simply by the introduction of AI agents. It represents a fundamental shift in both the way software enterprises operate and the way that software is built and managed.

Enterprise software is no longer composed solely of applications. Organizations will continue to rely on APIs, microservices, event-driven systems, web applications, and integration services to deliver business capabilities. Those applications will continue to depend on databases, messaging systems, object storage, AI models, identity providers, APIs, secrets, SaaS services, and countless other shared resources. What changes is that AI agents become active participants within this software ecosystem. They collaborate with applications, consume and manage resources, investigate incidents, coordinate deployments, analyze telemetry, enforce policies, and automate operational workflows.

At the same time, the consumers of the platform are evolving. Historically, developer platforms were designed primarily for human users, developers building applications, platform engineers operating infrastructure, and SREs maintaining production systems. In the Agentic Enterprise, AI agents become platform consumers alongside these human users. They interact with the same platform to provision resources, deploy applications, inspect operational state, invoke workflows, and perform tasks on behalf of their human collaborators.

This shift has important implications for platform engineering. The platform can no longer assume that every interaction originates from a human. It must provide interfaces designed for both humans and AI agents, while giving each actor a distinct identity, scoped permissions, and a clear audit trail. A developer using a portal, an SRE using a CLI/GitOps, and an AI agent invoking an MCP server may interact with the platform differently, but their actions should be governed through consistent security controls, policy boundaries, and operational guardrails.

The Agentic Enterprise therefore changes both what the platform manages and who the platform serves. It must manage applications, resources, and AI agents as first-class software assets, while simultaneously supporting humans and AI agents as first-class consumers of the platform. That evolution, not simply the rise of AI agents, is what defines the next stage of platform engineering.

Applications, resources, and AI agents

Recognizing that both humans and AI agents are becoming first-class consumers of the platform naturally changes what the platform itself must manage.

Historically, Internal Developer Platforms revolved around a single primary abstraction: the application. Infrastructure existed beneath it, CI/CD pipelines surrounded it, observability systems monitored it, and security controls protected it. Everything ultimately existed to simplify the delivery and operation of applications.

That model served the industry remarkably well because applications were the primary software assets organizations built and operated. In the Agentic Enterprise, however, applications are no longer the only first-class entities the platform needs to understand.

Applications remain central to enterprise software. They implement business logic, expose APIs, process events, and deliver business capabilities. They continue to be the primary software artifacts that development teams create and evolve.

Resources provide the capabilities that make those applications possible. They include databases, messaging systems, object storage, AI models, APIs, identity providers, secrets, Kubernetes clusters, SaaS services, and execution environments. Traditionally these were treated simply as infrastructure or external dependencies. Increasingly, however, they have become first-class software assets with their own lifecycle, ownership, governance, operational history, security requirements, and policies.

AI agents introduce a fundamentally different kind of software actor. Rather than implementing business functionality directly, they reason over context, invoke tools, collaborate with humans and other agents, and automate operational activities. Like human engineers, they interact with both applications and resources to investigate incidents, coordinate deployments, provision infrastructure, enforce policies, and continuously improve software systems.

The key insight is that these three entities are not independent. Applications consume resources to deliver business capabilities. AI agents consume many of those same resources to understand and operate the system. AI agents also interact with applications, while applications themselves expose capabilities that AI agents can invoke. Resources therefore become the common foundation that connects applications and AI agents within the enterprise software estate.

For platform engineering, this changes the focus from managing individual software components to managing the relationships between them. The platform must understand not only applications, resources, and AI agents as first-class entities, but also how they depend on one another, how changes propagate across the system, and how both humans and AI agents can safely interact with them.

This broader view of enterprise software forms the foundation for the next generation of platform engineering, one that manages the complete enterprise software estate rather than applications alone.

Context is the new foundation

As enterprise software evolves into an interconnected system of applications, resources, and AI agents, understanding the relationships between these software assets becomes just as important as managing the assets themselves. Platform engineering is no longer responsible only for deploying software; it must also understand how software behaves, how its components depend on one another, and how changes propagate across the enterprise software estate.

Traditional observability platforms already collect enormous amounts of operational data. Logs record events, metrics measure system behavior, traces reveal request flows, and events capture changes across infrastructure and applications. These signals remain essential, but they are fundamentally descriptive. They tell us what happened, but rarely explain why it happened or how one event relates to another.

When experienced engineers investigate production issues, they naturally go beyond telemetry. They combine deployment history, ownership, topology, dependencies, operational policies, previous incidents, and organizational knowledge to build a complete understanding of the system. They reason using context rather than isolated pieces of data.

AI agents require exactly the same capability.

An agent investigating a failed deployment needs more than logs. It needs to understand which application owns the deployment, which resources it depends on, what changed recently, who owns those resources, what policies apply, whether similar incidents have occurred before, and what remediation actions previously proved successful. Without that broader context, even the most capable AI model is limited to reasoning over disconnected observations.

This is why context is becoming a first-class platform capability.

Modern platforms need to build and maintain a shared understanding of the enterprise software estate. That understanding connects applications, resources, AI agents, deployments, ownership, policies, topology, operational history, and organizational knowledge into a coherent model that both humans and AI agents can reason over. Instead of navigating disconnected dashboards and APIs, every platform consumer works from the same contextual representation of the system.

Once the platform becomes context-aware, it can expose that knowledge through the interfaces best suited to each consumer. Human users may access it through portals, command-line interfaces, APIs, or dashboards, while AI agents consume the same contextual information through protocols such as the MCP. Although the interfaces differ, they all represent the same underlying understanding of the platform.

This contextual foundation also enables richer platform capabilities. Reusable skills encapsulate common engineering tasks that can be invoked by both humans and AI agents, while built-in agents specialize in domains such as site reliability, security, compliance, or FinOps. Because these capabilities operate on the same contextual model, they can collaborate consistently rather than functioning as isolated automations.

Ultimately, context transforms the platform from a system that merely executes workflows into one that understands the software it operates. That shared understanding becomes the foundation upon which humans and AI agents can collaboratively build, operate, and continuously improve increasingly complex enterprise systems.

OpenChoreo: A practical example

A flow chart image of the OpenChoreo workflow

These ideas are already beginning to appear in modern cloud-native platforms. OpenChoreo, a CNCF Sandbox project, demonstrates one approach to evolving platform engineering for the Agentic Enterprise while remaining firmly grounded in Kubernetes and cloud-native principles.

At its core, OpenChoreo continues to provide everything expected from a modern Internal Developer Platform. It enables developers to build, deploy, secure, observe, and operate applications through familiar cloud-native practices such as CI/CD, GitOps, policy enforcement, and self-service. Kubernetes remains the system of record, ensuring that every platform abstraction reflects the actual runtime state rather than introducing an independent control plane.

What evolves is not only what the platform manages, but also who it serves.

OpenChoreo is designed for both human users and AI agents. Developers, platform engineers, and SREs continue to interact with the platform through familiar experiences such as portals, CLI, APIs, and GitOps workflows, while AI agents access the same platform through MCP servers. Although these interfaces are different, every consumer operates on the same platform, using the same underlying understanding of applications, resources, relationships, and operational state.

This shared understanding begins with applications and resources. Applications remain the primary software artifacts delivered by development teams, while resources become first-class platform abstractions. Rather than treating databases, messaging systems, object storage, APIs, AI models, secrets, identity providers, and external services as infrastructure details, OpenChoreo models them as managed platform objects with their own lifecycle, ownership, governance, and relationships. This gives both humans and AI agents a consistent view of the complete enterprise software estate.

OpenChoreo is also designed as an extensible platform through its ecosystem architecture. Rather than embedding every capability into the core platform, new functionality can be introduced through ecosystem modules. These modules can extend the platform with new application capabilities, higher-level resource abstractions, enterprise integrations, observability providers, security services, deployment targets, or domain-specific workflows, allowing organizations to evolve the platform without changing its core architecture.

The same ecosystem approach naturally extends to AI capabilities. Built-in agents and reusable skills allow organizations to automate common operational activities, while additional ecosystem modules introduce capabilities such as an Agent Manager, AI Gateway, sandboxing, policy enforcement, and evaluation frameworks. These capabilities enable AI agents to safely participate in platform operations while operating within the same governance, security, and observability model as the rest of the platform.

This modular architecture is perhaps the most important aspect of the platform. As enterprise software continues to evolve, new resource types, AI capabilities, operational patterns, and integrations can be added as ecosystem modules without redefining the platform itself. The platform remains consistent while its capabilities continue to grow.

Ultimately, OpenChoreo demonstrates that the future of platform engineering is not about creating separate platforms for applications, resources, or AI. It is about extending a single cloud-native platform that enables both humans and AI agents to collaboratively build, operate, and govern the complete enterprise software estate.

Conclusion

Platform engineering has always evolved in response to changes in how software is built and operated. It began by simplifying infrastructure management, then matured into Internal Developer Platforms that standardized software delivery, reduced developer cognitive load, and established consistent operational practices across engineering organizations. As enterprise software continues to evolve, platform engineering must evolve with it.

The Agentic Enterprise represents the next stage of that journey. Its defining characteristic is not simply the introduction of AI agents, but the emergence of a richer software ecosystem where applications, resources, and AI agents continuously collaborate to deliver business outcomes. Applications remain the primary way organizations deliver value. Resources become first-class software assets with their own lifecycle and governance. AI agents become intelligent participants that reason over context, automate workflows, and assist both developers and platform engineers.

This evolution does not call for a separate platform for AI, nor does it diminish the role of applications. Instead, it expands the scope of platform engineering itself. Modern platforms must provide a unified operational model where applications, resources, and AI agents share common foundations for identity, governance, security, observability, policy enforcement, and lifecycle management. By managing these software assets consistently, organizations can embrace AI without introducing new operational silos or fragmented governance models.

The next generation of platform engineering will therefore be measured not only by how effectively it enables developers, but also by how well it manages the complete enterprise software estate. Platforms that understand the relationships between applications, resources, and AI agents, and provide the context, governance, and extensibility needed to operate them together, will become the foundation of the Agentic Enterprise.

Ultimately, the future of platform engineering is not about building platforms for AI. It is about evolving the platform into the trusted operational foundation where applications, resources, and AI agents can work together securely, consistently, and at enterprise scale.