Platform Engineering 2.0 is having a moment.
Pankaj Gupta of VMware by Broadcom has described it as the evolution the AI era demands. Gupta and Sam Barlien of the Platform Engineering community developed that thinking more fully in their joint white paper, Platform Engineering 2.0: An Evolution for the AI Era. Barlien, with contributions from Luca Galante, also explores the convergence of AI and platform engineering in the latest State of Platform Engineering Report, Volume 4. Here at PlatformEngineering.com, Steven Vaughan-Nichols has examined how platform teams can manage the costs and risks of AI without tearing down the infrastructure they spent years building.
Whether we ultimately call it Platform Engineering 2.0 is not the most important question. Technology movements have a habit of acquiring version numbers when the changes become too significant to fit comfortably under the old label. What matters is that the platform must now accommodate workloads, users, costs and risks that were not part of its original design.
The more immediate question is much simpler: What exactly is this next platform made of?
Is it an internal developer portal built with Backstage? Is it Kubernetes and the cloud-native stack adapted for AI? Is it an infrastructure and virtualization layer such as VMware Cloud Foundation? Does it require an AI gateway, a model-serving platform and an agent control plane? Is it all of these?
I suspect the answer depends on what you want to get out of the platform. Platform Engineering 2.0 will not arrive as a standard bill of materials. It will be an opinionated platform product composed from several layers, with its architecture determined by the people, workloads and business outcomes it must support.
We Know What It Must Do
Gupta and Barlien organize Platform Engineering 2.0 around five pillars: An AI-native platform, a multi-persona experience, embedded FinOps, security shifted into the platform and an architecture that is composable by design. Gupta’s VMware blog expands on their framework and argues that infrastructure must become a first-class strategic concern rather than remain invisible plumbing.
In the State of Platform Engineering Report, Volume 4, Barlien, with contributions from Galante, reaches a related conclusion from a broader practitioner perspective. Platform engineering is expanding beyond classical developer experience into security, observability, FinOps, data and AI. Platform teams now have a dual mandate: Use AI to improve the platform while also building platforms capable of supporting AI development and operations.
In my own white paper, What Is Platform Engineering?, I started with the principles that got us here: Self-service, golden paths, reduced cognitive load, developer experience and treating the platform as a product. Those principles do not disappear in the AI era. If anything, they become more important as the underlying complexity increases.
Vaughan-Nichols adds another essential point: This should be an evolution of existing platform investments, not an excuse to discard them and begin again. Enterprises have spent years standardizing Kubernetes clusters, CI/CD pipelines, internal developer platforms and self-service infrastructure. AI may expose the limitations of that foundation, but it does not erase its value.
Taken together, these resources give us a good picture of what the next platform must accomplish. It must support applications, models and agents. It must serve developers, platform engineers, data scientists, security teams, FinOps professionals, business leaders and non-human users. It must govern access to expensive infrastructure and consumption-based AI services. Security, compliance and observability need to be inherent platform capabilities rather than responsibilities handed to every individual team.
That is a demanding job description. It still does not tell us what to build.
Backstage Can Be the Front Door
Backstage is an obvious place to begin because many organizations associate their internal developer platform with the portal through which developers access it.
That is understandable. Backstage provides a software catalog, templates, documentation and an extensible framework for presenting platform capabilities. It can give developers a coherent interface for discovering services, requesting environments and following approved golden paths. It may also become a place where users discover approved models, data products, agents and AI services.
But Backstage is not the platform by itself.
Barlien and Galante warn about the “portal trap”: Building an attractive interface while neglecting the orchestration, automation and core platform logic behind it. A portal can provide the front door, but someone still has to build the house, wire the electricity, install the plumbing and determine who is allowed into each room.
This limitation becomes more apparent as AI agents join the list of platform users. Human developers may consume platform capabilities through a portal. Agents will generally consume them through APIs and machine-readable contracts. The next platform must serve both without assuming that everyone—or everything—will navigate it through a graphical interface.
Backstage can be the storefront. The platform is the system that fulfills what users request from it.
Kubernetes Is the Probable Spine
Kubernetes has the strongest claim to serving as a common workload control plane for Platform Engineering 2.0.
It already gives platform teams declarative APIs, orchestration, reconciliation, policy integration and a large ecosystem of composable projects. It can run across public clouds, private clouds and on-premises infrastructure. It gives platform builders a relatively consistent way to describe and manage workloads without tying every platform capability directly to the underlying environment.
Kubernetes is also being adapted for AI. The community is working on more sophisticated management of GPUs and other specialized hardware, workload-aware and gang scheduling, and model-aware inference routing. The wider cloud-native ecosystem is developing the components needed to run AI workloads with more of the consistency Kubernetes brought to containerized applications.
That makes the familiar description more appropriate than ever: Kubernetes is a platform for building platforms.
It is not, however, the finished Platform Engineering 2.0 product. Kubernetes does not independently provide the full developer experience, enterprise data governance, model evaluation, token accounting, agent identity, Model Context Protocol (MCP) governance or business-level cost management that an AI-era platform requires.
Kubernetes may be the spine, but a spine is not a complete body.
The Hypervisor Never Disappeared
Gupta and Barlien place infrastructure at the foundation of their Platform Engineering 2.0 model. Given Broadcom’s business, we should recognize the commercial perspective behind that position. We should not dismiss it, either.
AI is making infrastructure visible again.
Cloud computing encouraged developers to think of infrastructure as an API. Click a button or make a call, and compute appears. The servers, networks and virtualization layers underneath became someone else’s concern. That abstraction was one of cloud computing’s great accomplishments.
But the hypervisor never disappeared. Public clouds run on virtualization, too. They pool resources, isolate tenants and workloads, allocate compute and memory, enforce boundaries and present physical infrastructure as consumable services. Hyperscalers did not eliminate virtualization; they absorbed it into their platforms and largely hid it from customers.
AI is pulling back the curtain. GPUs and other accelerators are too expensive, scarce and operationally demanding to treat as unlimited commodities. Someone must decide which workloads receive them, how they are shared, how utilization is measured and whether sensitive data and models can coexist safely on the same infrastructure.
This is where VMware deserves serious consideration.
VMware Cloud Foundation is more than the server hypervisor many of us first encountered years ago. It brings together virtual machines, containers, Kubernetes, compute, storage, networking, automation, operations and security as an integrated private-cloud foundation. For enterprises running traditional applications alongside cloud-native and AI workloads, that breadth is significant.
VMware can help organizations pool and govern GPU resources, support private AI, preserve workload isolation and provide cloud-like self-service on infrastructure they control. It offers an evolutionary path for companies with substantial VMware estates rather than demanding that they abandon those investments whenever a new workload arrives.
Asking whether Platform Engineering 2.0 should be built on Kubernetes or VMware presents a false choice. Kubernetes orchestrates workloads. VMware can provide and govern the virtualized infrastructure beneath and around them. VMware’s Kubernetes services connect those layers, allowing enterprises to expose infrastructure through the self-service patterns expected from a modern platform.
The public cloud provides many comparable underlying capabilities, although customers consume them differently. A cloud-first organization may rely on a hyperscaler’s managed infrastructure and Kubernetes services. An AI operator focused on maximum performance may choose bare metal. An enterprise with regulated data, sovereignty requirements, mixed workloads and a long-term hybrid strategy may find VMware’s integrated model particularly compelling.
The choice is not hypervisor or no hypervisor. It is whether the virtualization and infrastructure layer is controlled directly by the enterprise, consumed from a cloud provider or divided between them.
AI Needs Its Own Control Plane
Even a combination of Backstage, Kubernetes and a capable infrastructure layer does not finish the platform.
AI introduces a new control problem. Enterprises need to manage access to external and internally hosted models. They need to route requests, protect credentials, track token consumption, evaluate model performance and enforce limits before an experiment or faulty application produces an unexpected bill.
Agents make this more complicated. An agent needs an identity, permissions and a defined scope of authority. The platform must determine which tools, data sources and MCP servers an agent can access. It must record what the agent did, apply policy to its actions and place boundaries around its autonomy.
These capabilities do not fit neatly inside a traditional developer portal or Kubernetes cluster.
Research from my Futurum colleague Mitch Ashley suggests that the need is already moving from architecture diagrams into enterprise buying decisions. Futurum’s 2026 Software Lifecycle Engineering research found that 76.6% of organizations are actively using AI in development workflows, with another 20.4% evaluating it. Only 3.1% remain outside that trajectory. AI support is no longer a capability that platform teams can schedule for some distant phase of their roadmaps.
Ashley’s Futurum Agent Control Plane Framework offers a useful model for what the agent portion of this platform must contain. It separates execution environments, knowledge authority, behavioral guardrails, governance and multi-agent coordination while placing observability, trust and openness across the entire architecture. In Ashley’s formulation, agents decide, control planes govern, execution environments enforce and systems generate evidence. That is a much more complete description of production agent infrastructure than connecting a model to an MCP server and calling it a platform.
The investment patterns are moving in the same direction. In a Futurum survey of 139 enterprise decision-makers, AI observability ranked fourth among observability procurement priorities at 37.4%, while agent observability ranked sixth at 30.9%. Both ranked ahead of Kubernetes observability and infrastructure monitoring. Cost optimization ranked fifth at 30.2%. Enterprises are preparing to observe, govern and pay for agents before most have deployed them broadly. The platform will need to meet those expectations.
A CNCF cloud-native generative AI reference architecture illustrates how additional components such as an AI gateway and KServe can provide unified model access, credential management, routing, model serving, token-based controls and AI-specific observability. These systems can connect externally hosted services with models running on an organization’s own infrastructure.
An AI control plane will likely include some combination of gateways, model registries, serving platforms, evaluation tools, agent governance, MCP management and data controls. It will not replace Kubernetes, VMware or the public cloud. It will translate AI consumption into requests those underlying systems can govern and fulfill.
This is also where composability becomes more than an attractive architectural principle. AI technology is moving too quickly for enterprises to make one permanent choice about models, gateways, agent frameworks or serving systems. The platform must give teams room to change components without forcing every application and workflow above them to change as well.
The Platform Is the Whole System
The likely architecture begins with an experience layer: Backstage, another portal, an API or a conversational interface. Underneath that sits orchestration: Golden paths, GitOps, infrastructure as code, CI/CD and workflow automation.
A workload control plane manages applications, data jobs and AI workloads across Kubernetes, serverless systems, batch schedulers and virtual machines. An AI control plane governs models, inference, agents and tools. A virtualization and infrastructure layer pools and isolates compute, accelerators, storage and networking. Beneath all of it are the physical resources distributed across public clouds, private data centers, colocation facilities and edge locations.
Security, identity, compliance, observability and FinOps cannot be relegated to separate boxes alongside this stack. They must operate through it. This is the idea behind “shifting down”: The platform absorbs security, reliability, cost and governance requirements so that every developer, data scientist or agent does not have to implement them independently.
Not every organization will need each layer in the same form. A company consuming models exclusively through external APIs may place greater emphasis on an AI gateway, identity and token economics than on GPU scheduling. A company training or serving its own models will care deeply about Kubernetes, accelerators, storage and infrastructure utilization. A regulated enterprise may prioritize private AI, workload isolation, data residency and auditable controls.
The State of Platform Engineering Report offers an important clue here. It finds that platform pluralism is becoming normal as organizations recognize that AI, data engineering and other domains may require purpose-built platforms. The goal may not be one platform to rule them all. It may be a coherent platform strategy built around interoperability, shared controls and intentional separation.
There is a common capability model, but there should not be a mandatory stack.
Start With the Promise
Platform Engineering 1.0 largely represented an agreement between a platform team and application developers: Follow these golden paths and we will give you a faster, safer and repeatable way to ship software.
Platform Engineering 2.0 expands that contract. Bring the platform an application, model, agent or data workload, and it should provide an approved way to build it, run it, observe it, secure it, govern it and pay for it.
That promise is much broader than developer experience. It reaches across infrastructure, application delivery, data, security, AI and business operations. It also means that the platform must serve people who do not call themselves developers and agents that are not people at all.
Backstage proponents naturally see this evolution from the experience down. Kubernetes advocates see the workload control plane. VMware sees it from the infrastructure up. AI platform vendors see models and agents as the new center. Each holds an important part of the answer, but none has the entire platform in its hands.
Backstage may be the front door. Kubernetes may be the spine. VMware or a public cloud may provide the virtualized infrastructure foundation. AI gateways and model platforms may govern the consumption of intelligence. Agent control planes may define how much authority non-human users receive. Security, observability and FinOps must reach through all of them.
None of those is the platform alone.
The platform is the coherent product created when those layers are composed around the outcomes an organization needs. Before we decide what to buy or build for Platform Engineering 2.0, we need to decide what we expect the platform to make possible.
That is my model, but it is not intended to be the last word. PlatformEngineering.com and Futurum Research will be exploring this question in greater depth. We want to understand what practitioners are actually building, not merely what vendors believe they should build.
If you are responsible for a platform, I would like to know what provides its front door, workload control plane and infrastructure foundation. Are you extending an existing platform to support AI or creating a separate one? Are your models primarily consumed through external APIs or hosted internally? Who owns agent governance and AI cost control? Most importantly, which layer is preventing your platform from delivering what the business now expects from it?
The answers may demonstrate that a recognizable Platform Engineering 2.0 architecture is emerging. They may confirm that multiple platform archetypes are the new normal. Either way, those answers—not a vendor’s reference stack or an arbitrary version number—will tell us what the next platform is really made of.
Help Define the Platform Engineering 2.0 Stack
PlatformEngineering.com and Futurum Research are examining how organizations are extending their platforms for AI workloads and agents.
If you lead or contribute to a platform engineering initiative, please take our short, three-minute practitioner survey. Tell us what your platform is made of, where its workloads run, how it supports AI and which capability remains the greatest obstacle.
The results will help inform a forthcoming Platform Engineering 2.0 white paper. Respondents may also volunteer for a short follow-up interview. Survey findings will be reported in aggregate, and no individual or organization will be identified without permission.
Take the Platform Engineering 2.0 Practitioner Survey — https://www.surveymonkey.com/r/TMQRYRQ