This is the second article in a series on the evolution of platform engineering.

In the first article, we examined why platform engineering must evolve for the agentic era. Now let’s look at what Platform Engineering 2.0 looks like in practice.

It’s a deliberate extension of what 1.0 established, structured around five pillars. The first is load-bearing; the other four depend on it. Together, they give platform teams a framework to audit their own evolution.

The first pillar is an AI-native platform. The IDP becomes an Agentic Development Platform (ADP). AI workloads and agents stop being something the platform tolerates and become something the platform is built for. The center of gravity shifts from a catalog optimized for human browsing to a real-time, API-accessible graph of services, dependencies, ownership, policy, and cost. In practice, this means an agent can discover available services, check their cost implications, and provision them through an API call rather than a human clicking through a catalog. Platforms expose capabilities as machine-callable interfaces with first-class agent identity so every automated consumer is authenticated, scoped, and attributable.

The second pillar is multi-persona experience. Every persona, including humans and AI agents, gets purpose-built tools and abstractions from a common platform foundation. Developers, security teams, FinOps leaders, operators, and ML engineers work through role-specific dashboards from a shared system of record.

The third pillar is embedded FinOps. FinOps moves out of monthly updated dashboards and into pre-provisioning cost visibility and gates. Instead of discovering at month-end that a GPU cluster cost far more than expected, the platform surfaces the projected cost before the provisioning request is approved. Infrastructure including GPUs, models, vector and data services, and the unit economics of inference become core building blocks. Every developer becomes a FinOps practitioner by design, through platform design that surfaces cost at the point of decision.

The fourth pillar is security shifts down. Guardrails for security, compliance, cost, and operational boundaries are enforced whether the actor is a person or an agent. Platform Engineering 1.0 shifted security left, into the pipeline and onto developers. Platform Engineering 2.0 keeps shift-left and adds shift-down into the infrastructure substrate itself. Instead of relying on a developer to remember to scan a container image, the infrastructure enforces the scan as a condition of deployment. Shadow AI sprawl, prompt injection, model poisoning, and inference data leaks require infrastructure-level controls, not just application-layer ones.

The fifth pillar is composable by design. Platform capabilities are delivered as modular, independently deployable building blocks connected through well-defined contracts: policy, SLAs, APIs. This lets you swap in new tools or repave the platform quickly as AI requirements evolve, with CNCF-conformant or certified options where possible. The value is flexibility and choice: teams can adopt new capabilities without rebuilding the platform from scratch.

Audit your platform against these five pillars. Most teams have elements of each already in place. But few have integrated them into a coherent operating model for both human and agentic consumers.

The next article covers how to operationalize these changes, starting with the collaboration gap between platform engineering and IT infrastructure teams.