Platform Engineering 2.0: Evolve the Substrate for AI and Agents

Al has blindsided cloud native infrastructure management, rendering established platform engineering woefully inadequate. Original platform engineering often suffers from a developer-only focus, but a platform that serves only one persona in a multi-persona organization ultimately delivers a shrinking fraction of its potential enterprise value.

Autonomous agents are already beginning to write, review, test, and deploy code or fixes with or without human intervention. This shifts the primary organizational bottleneck from writing code to delivering it safely and quickly.  The gap requires a new model: Platform Engineering 2.0.

Platform Engineering 2.0 is an evolution rather than a complete architecture reset, where the core foundations remain essential, but what fundamentally changes is who the platform serves, what it must do, and how it must be built. It also should not require a complete upending of existing internal developer platforms (IDPs).

This transition to Platform Engineering 2.0 represents the structural evolution of the traditional internal developer platform into an agentic development platform (ADP) built to enable collaborative software development between human developers and autonomous AI agents. To achieve this, Platform Engineering 2.0 structurally expands its scope across five fundamental pillars: an AI-native platform, a multi-persona experience, embedded FinOps, security shifting down, and a composable architecture.

Platform 1.0's Ceiling and Limitations

Platform engineering was originally built for mostly containerized workloads. It has no first-class, native support for AI workloads. Capabilities like GPU and TPU provisioning, model serving, versioned model registries, Model Context Protocol (MCP) gateways, or AI-specific governance are not natively supported. When a data science team needs a self-service GPU environment, or when an autonomous agent needs a bounded scope, the traditional platform has no native answer. 

Original platforms often suffer from a developer-only focus. Current platform engineering serves that one persona well, but many environments treat security teams, data engineers, ML practitioners, FinOps analysts, and business users as second-class citizens or exclude them entirely. A platform that serves only one persona in a multi-persona organization ultimately delivers a shrinking fraction of its potential enterprise value.

This architectural design creates a posture that is reactive, not proactive. Platform teams designed mostly for developer experience perpetually feel behind because there is no cost-aware provisioning, no proactive drift detection, and limited defense in depth. The platform responds to problems after the fact rather than preventing them. In an era where AI workloads generate massive cost spikes overnight, and security threats evolve continuously, a reactive posture is no longer viable.

Standard predefined templates and “Golden Paths” — once praised for reducing friction for developers and accelerating deployments — are increasingly viewed as “golden cages” in the age of AI. While they excel at standardizing traditional workloads, these rigid IDP patterns now actively constrain the rapid experimentation, custom GPU configurations, and flexible orchestration that modern AI agents and inference workloads demand. Teams working on novel AI architectures become blocked by the very guardrails designed to help them.  Evolving regulations hit edge constraints, and minor variations require manual platform team interventions. Finally, compliance remains a rigid, point-in-time snapshot rather than a continuous guarantee. 

With AI, this operational strain is accelerating exponentially. The majority of developers already use AI coding copilots such as Claude and Cursor. While these tools meaningfully increase individual productivity, the resulting explosion in code volume has created severe code review bottlenecks. According to recent surveys, 38% of developers say it takes longer to review AI-generated code than human-written code. Much of this AI-generated code consists of so-called “AI slop” — pull requests containing subtle bugs that AI often misses, missing architectural nuances, and code of generally lower long-term value.

This is becoming a significant burden on open source projects — especially those with limited maintainer support — and is turning into one of the primary organizational bottlenecks from writing code to delivering it safely.

Furthermore, autonomous agents are already beginning to write, review, test, and deploy code or fixes without human intervention via the Model Context Protocol (MCP). While agents do not inherently introduce more dangerous code than humans do, their sheer speed means they must be constrained by automated loops and active monitoring. When working with AI agents, automated policy-as-code enforcement for compliance and security, as well as strict environment isolation with VM-based sandboxing to reduce the blast radius, becomes essential. In other words, Platform Engineering 2.0 means that the Internal Developer Platform (IDP) must accommodate and protect the organization against the mistakes of autonomous agents just as robustly as it does for humans.

Evolve the Substrate

Platform Engineering 2.0 is an evolution rather than a complete architecture reset. The core foundations of platform engineering — developer productivity focus, platform as product, opinionated processes, shift-left security, and self-service IDPs — remain essential. What fundamentally changes is who the platform serves, what it must do, and how it must be built.

Pillar 1: The AI-Native Platform 

An AI-native platform must support two new realities simultaneously: AI workloads must run as first-class citizens, and AI agents must be natively supported as a new class of non-human user. Meeting both criteria represents the structural evolution of the traditional IDP into an agentic development platform (ADP) built to enable collaborative software development between human developers and autonomous AI agents. This evolution plays out across three time horizons.

The platform must dynamically provision, manage, and govern AI workloads natively alongside other applications through a single, self-service interface. This requires GPU and TPU provisioning with dynamic allocation policies, model-serving networks, versioned model registries, and MCP server infrastructure. 

Merging containers, VMs, and AI workloads on a single unified substrate closes the current utilization gap, where environments run at a wasteful baseline across compute resources.

As autonomous agents embed into enterprise workflows, the platform must enforce bounded autonomy. Agents must operate within strict, defined limits, request human approval beyond those boundaries, and log every decision path in an unalterable audit trail. 

Platform teams must organize these rules into seven key operational concerns: identity, context, capability (including tool registries), execution, evaluation, security, and observability. Defining these concerns as Agent Infrastructure as Code (AIaC) brings the recoverability and reproducibility of GitOps to agent operations.

The long-term destination is a self-sustaining platform that self-heals, self-optimizes, self-scales, and self-secures through autonomous control loops and telemetry working in concert.

Pillar 2: Multi-Persona Experience

Platform engineering 2.0 structurally expands its scope to serve six distinct first-class personas: application developers, platform engineers, engineering and business leaders, security and compliance teams, data scientists and ML engineers, and AI agents. High-performing platforms provide specialized experience layers — distinct portals, CLIs, and APIs — tailored to each persona's unique needs, while keeping the underlying backend APIs completely shared to avoid fragmented governance.

Pillar 3: Embedded FinOps

The platform executes an embedded FinOps strategy that monitors AI-related costs and enforces real-time, preset spending caps on AI tokens and other costs to prevent budget-busting spending. Embedded FinOps shifts cost intelligence directly onto provisioning-time decision-making. The architecture delivers five core capabilities to make cost a first-class platform signal: self-service FinOps with real-time showback and chargeback; real-time cost attribution; predeployment cost gates; token attribution; and autonomous janitor agents.

Pillar 4: Security Shifts Down

Platform engineering 2.0 embeds security directly into the immutable platform substrate and runtime layers. Shifting “security down” embeds least-privilege networking, service-to-service mutual TLS (mTLS), microsegmentation, and automated secrets rotation directly into the infrastructure layer, making compliance continuous and completely invisible to developers. Security shifts down complements Shift Left, instead of replacing it. 

Pillar 5: Composable by Design

To maintain absolute agility against these rapid change cycles, the platform must be composable by design. The future of platform engineering is not build versus buy: it is compose. Composable architecture provides modular, interchangeable, and independently deployable building blocks connected by well-defined API contracts. This allows engineers to select the “best of breed” tools for their requirements with faster and more confident repeatability.

What Now

The personas that need to be accommodated are no longer just developers and platform engineers. The elephant in the room that CTOs and DevOps teams are increasingly aware of is the emergence of the AI persona. This manifests as active agents autonomously building, creating, and deploying code without human intervention, just as a human does.

At the same time, while accommodating a FinOps stakeholder, the risk is that AI token costs can run awry and become prohibitively expensive. Additionally, humans will invariably introduce terrible things to the infrastructure, whether on their own or because rogue code and hallucinations from AI tools like Cursor and Claude Code are copied directly into the substrates.

All this must be taken into account by platform engineering 2.0. However, systems should not be locked down to the extent that "golden cages" are created. The platform must preserve the freedom to run sandbox projects without restrictive and inflexible boundaries. Platform engineering is no longer just about the developer experience; it must serve multiple stakeholders, especially the AI agent persona that previous frameworks failed to accommodate.