This is the first of a three-part series on the evolution of platform engineering.
AI isn’t changing the goals of platform engineering. It’s changing who consumes the platform.
Once software agents become platform consumers alongside developers, the platform must expose APIs, policy, identity, governance, and cost controls differently. This series examines why that shift is happening and what it means for platform teams.
Your organization wants AI. That’s a fact. According to VMware by Broadcom’s Private Cloud Outlook 2026 study, 57% of enterprise IT organizations say their top modernization strategy is adding AI capabilities to existing applications, not rehosting, replatforming, or replacing with SaaS. But 72% of those same enterprises have modernized less than half of their application portfolio. Seven in 10 IT organizations are trying to layer AI onto a foundation that was never designed for it.
The gap isn’t about ambition. It’s about infrastructure and operating model readiness. The old model of sequential transformation no longer fits. Enterprises need a platform that supports both traditional and AI-enhanced and agentic workloads as first class citizens. That’s a current operational requirement, not a future architectural goal.
Platform Engineering 2.0
The distinction between Platform Engineering 1.0 and 2.0 comes down to whom the platform serves. Platform Engineering 1.0 focused on helping developers consume infrastructure through self-service experiences while embedding security and operational best practices. Platform Engineering 2.0 extends that same philosophy to autonomous software agents, requiring the platform to expose APIs, policy, identity, governance, and cost controls that both humans and machines can consume consistently.
That model from 1.0 is now mainstream: 80% of enterprises have a dedicated platform engineering team today. But a new kind of consumer is reshaping the discipline. AI-assisted development tools and autonomous agents now request infrastructure, open pull requests, and take actions at machine speed.
Four forces are driving this shift. When an autonomous agent can provision an environment in seconds, the platform must express its capabilities as APIs and enforce guardrails without a person in the loop. GPUs, models, MCP servers and gateways, vector and data services are now core platform primitives with cost and scaling behavior fundamentally different.
Autonomous workflows can consume resources non-linearly and incur unpredictable cost even when a run fails, so cost governance must move from after-the-fact reporting to a real-time constraint. And if both people and agents can act on the platform, every action must be authenticated, scoped, and auditable.
Principles remain the same
Platform Engineering 2.0 doesn’t discard the principles of 1.0. Paved roads, self-service, and the platform-as-a-product mindset remain foundational. What changes is the primary consumer: from presenting infrastructure to a human, to enforcing guardrails, proactive FinOps and policy, so that humans and machines can both act on the platform safely.
In the next article, we’ll examine the five pillars that define a platform built for the agentic era and how to audit your own platform against them.
SD Times Q&A
What is Platform Engineering 2.0?
Platform Engineering 2.0 extends the self-service, paved-road model of traditional platform engineering to support autonomous AI agents alongside human developers. It requires the platform to expose APIs, policy, identity, governance, and cost controls that both humans and machines can consume consistently. The core principles — paved roads, self-service, platform-as-a-product — remain the same; what changes is the primary consumer.
How do AI agents change platform engineering requirements?
When autonomous agents can provision environments, open pull requests, and consume resources at machine speed, platform teams must enforce guardrails without a human in the loop. This means real-time cost governance (not after-the-fact reporting), machine-readable APIs for all platform capabilities, and authentication and auditability for every agent action. New primitives like GPUs, model servers, MCP gateways, and vector databases also become core platform concerns.
What percentage of enterprises have a dedicated platform engineering team?
According to the article, 80% of enterprises now have a dedicated platform engineering team, indicating that the Platform Engineering 1.0 model is mainstream. The next challenge for those teams is extending their platforms to support agentic workloads alongside traditional developer workflows.
How should platform teams handle cost governance for agentic workloads?
Autonomous agent workflows can consume resources non-linearly and incur costs even when a run fails, making traditional after-the-fact FinOps reporting insufficient. Platform Engineering 2.0 requires cost governance to operate as a real-time constraint enforced at the API and policy layer, before or during resource consumption rather than only after.
What infrastructure do platform teams need to support AI agents?
Supporting agentic workloads requires treating GPUs, large language model servers, MCP (Model Context Protocol) servers and gateways, and vector/data services as first-class platform primitives. These have scaling and cost characteristics fundamentally different from traditional compute, and they must be governed, authenticated, and scoped the same way as any other platform resource.