That is the primary of a three-part sequence on the evolution of platform engineering.
AI isn’t altering the objectives of platform engineering. It’s altering who consumes the platform.
As soon as software program brokers grow to be platform customers alongside builders, the platform should expose APIs, coverage, identification, governance, and value controls otherwise. This sequence examines why that shift is occurring and what it means for platform groups.
Your group needs AI. That’s a reality. Based on VMware by Broadcom’s Personal Cloud Outlook 2026 research, 57% of enterprise IT organizations say their prime modernization technique is including AI capabilities to present functions, not rehosting, replatforming, or changing with SaaS. However 72% of those self same enterprises have modernized lower than half of their utility portfolio. Seven in 10 IT organizations try to layer AI onto a basis that was by no means designed for it.
The hole isn’t about ambition. It’s about infrastructure and working mannequin readiness. The outdated mannequin of sequential transformation now not matches. Enterprises want a platform that helps each conventional and AI-enhanced and agentic workloads as firstclass residents. That’s a present operational requirement, not a future architectural objective.
Platform Engineering 2.0
The excellence between Platform Engineering 1.0 and a pair of.0 comes right down to whom the platform serves. Platform Engineering 1.0 targeted on serving to builders eat infrastructure by way of self-service experiences whereas embedding safety and operational finest practices. Platform Engineering 2.0 extends that very same philosophy to autonomous software program brokers, requiring the platform to show APIs, coverage, identification, governance, and value controls that each people and machines can eat persistently.
That mannequin from 1.0 is now mainstream: 80% of enterprises have a devoted platform engineering group right now. However a brand new type of client is reshaping the self-discipline. AI-assisted improvement instruments and autonomous brokers now request infrastructure, open pull requests, and take actions at machine pace.
4 forces are driving this shift. When an autonomous agent can provision an atmosphere in seconds, the platform should specific its capabilities as APIs and implement guardrails with out a particular person within the loop. GPUs, fashions, MCP servers and gateways, vector and information companies at the moment are core platform primitives with value and scaling conduct essentially completely different.
Autonomous workflows can eat assets non-linearly and incur unpredictable value even when a run fails, so value governance should transfer from after-the-fact reporting to a real-time constraint. And if each individuals and brokers can act on the platform, each motion should be authenticated, scoped, and auditable.
Rules stay the identical
Platform Engineering 2.0 doesn’t discard the ideas of 1.0. Paved roads, self-service, and the platform-as-a-product mindset stay foundational. What modifications is the first client: from presenting infrastructure to a human, to implementing guardrails, proactive FinOps and coverage, in order that people and machines can each act on the platform safely.
Within the subsequent article, we’ll look at the 5 pillars that outline a platform constructed for the agentic period and the way to audit your individual platform towards them.
SD Occasions Q&A
What’s Platform Engineering 2.0?
Platform Engineering 2.0 extends the self-service, paved-road mannequin of conventional platform engineering to assist autonomous AI brokers alongside human builders. It requires the platform to show APIs, coverage, identification, governance, and value controls that each people and machines can eat persistently. The core ideas — paved roads, self-service, platform-as-a-product — stay the identical; what modifications is the first client.
How do AI brokers change platform engineering necessities?
When autonomous brokers can provision environments, open pull requests, and eat assets at machine pace, platform groups should implement guardrails with out a human within the loop. This implies real-time value governance (not after-the-fact reporting), machine-readable APIs for all platform capabilities, and authentication and auditability for each agent motion. New primitives like GPUs, mannequin servers, MCP gateways, and vector databases additionally grow to be core platform considerations.
What proportion of enterprises have a devoted platform engineering group?
Based on the article, 80% of enterprises now have a devoted platform engineering group, indicating that the Platform Engineering 1.0 mannequin is mainstream. The following problem for these groups is extending their platforms to assist agentic workloads alongside conventional developer workflows.
How ought to platform groups deal with value governance for agentic workloads?
Autonomous agent workflows can eat assets non-linearly and incur prices even when a run fails, making conventional after-the-fact FinOps reporting inadequate. Platform Engineering 2.0 requires value governance to function as a real-time constraint enforced on the API and coverage layer, earlier than or throughout useful resource consumption somewhat than solely after.
What infrastructure do platform groups have to assist AI brokers?
Supporting agentic workloads requires treating GPUs, giant language mannequin servers, MCP (Mannequin Context Protocol) servers and gateways, and vector/information companies as first-class platform primitives. These have scaling and value traits essentially completely different from conventional compute, they usually should be ruled, authenticated, and scoped the identical means as another platform useful resource.
