Evolution, Not Reset: Prepare Platform Engineering 2.0 for Autonomous Agents

AI-driven coding acceleration has shifted the software bottleneck from writing code to deploying it, as developers rely on AI to generate up to ten times more code. As autonomous agents emerge as active platform users, Platform engineering must provide the evolutionary framework needed to manage and secure this new persona. Platform Engineering 2.0 is what is required.

Platform engineering was built for containerized, human-paced workflows, but AI requires fast experimentation, fast feedback, and fast success, which requires tremendous flexibility as everyone is still learning. A platform that simply offers a few fixed templates cannot meaningfully address these issues. Platform Engineering 2.0 needs to be much more than a rebranding exercise or a reset. 

Platform Engineering 2.0 is a business-aligned evolution that aims to unlock, rather than constrain, high-velocity technical innovation. The emphasis throughout is that 2.0 builds on the foundation of platform-as-product, golden paths, and self-service IDPs, rather than tearing them down. The primary principles of platform engineering remain the essential foundation. 

The ‘Golden Path’ Becomes the Bottleneck 

Platform engineering popularized the concept of “golden paths.” While arguably used as a marketing buzzword, in the real world this represents standardized infrastructure, CI/CD, and observability routes that mean developers don’t have to reinvent deployment architectures every time they start a service. 

Golden paths remain viable for the vast majority of applications. Those ideas carried into enterprises as internal developer platforms (IDPs) and dedicated platform teams that promised to reduce developer cognitive load, abstract away the sharp edges of cloud-native computing, and convert ticket-driven operations into click-driven self-service. For standard, predictable workloads, this worked really well. 

However, for AI and agentic workloads, traditional golden paths have become a bottleneck. Evolving regulatory and compliance needs also demand a lot of flexibility. Standard predefined templates risk becoming rigid mandates where deviating becomes bureaucratically painful. Experimentation slows because trying a new database, runtime, or deployment model means “going off platform”. So golden paths transform into golden cages—well-constructed, comfortable, but ultimately confining for emerging workloads.

Agentic workflows do not fit neatly into the notion of “a service with a REST endpoint,” and AI-generated code shifts the bottleneck to safe, compliant code delivery. Platform Engineering 1.0 was great for optimizing developer productivity in a world of predictable workloads. But Platform Engineering 2.0 must enable collaborative development between humans and autonomous agents while enforcing bounded autonomy.

Meeting both these needs demands the evolution of the IDP into what is increasingly called the Agentic Development Platform, built and operated by the platform engineering team. In order to do that, the platform must be treated as a product. The concept of a platform as a product to accommodate different stakeholders has already successfully been put into practice with Platform Engineering 1.0 before AI agents became an additional and momentous persona to manage. 

The product has customers—developers, data scientists, ML engineers, security and compliance officers, FinOps, and increasingly, AI agents themselves. They consume APIs rather than interfaces, requiring scoped permissions, non-human identity, audit logging, budget controls, and egress controls. Unlike human developers who interact through GUIs or single command lines, the AI agent persona can execute thousands of tool and process calls simultaneously. 

Agentic Friendly Infrastructure 

As AI agents become embedded in enterprise operations, the platform must provide the infrastructure these agents require. Agentic workloads need bounded autonomy. Agents must act within defined limits, must request approval beyond those limits, and every action must be auditable. The key infrastructure components include Model Context Protocol (MCP) compatible APIs for agent discovery and invocation, policy guardrails constraining agent actions to pre-approved patterns, audit logging capturing the full decision chain, and escalation mechanisms routing uncertain decisions to human reviewers. Defining all seven concerns—identity, context, capability, execution, evaluation, security, and observability—as Agent Infrastructure as Code (AIaC) brings the recoverability, auditability, and reproducibility of IaC to agent operations. 

Yes to Composability 

In contrast to Platform Engineering 1.0’s reliance on rigid templates for services, pipelines, and environments, Platform Engineering 2.0 is all about composability. Rather than a few monolithic templates, the platform offers modular, API-exposed building blocks. The goal isn’t to maximize choice for its own sake; it’s to allow high-velocity experimentation within a safe framework. Teams can try a new framework or runtime while still relying on approved building blocks for networking, identity, logging, and governance, turning the golden cage into a set of golden Lego bricks. Because the architecture is composable, platform teams can incorporate new AI infrastructure without rewriting every path or forcing developers off-platform into bespoke stacks. 

A composable platform should provide five independently evolvable layers: experience layer; orchestration layer; capabilities layer; integration layer; and infrastructure layer. Modularity by design means every capability is a discrete, versioned building block. 

API-first contracts give those blocks standard interfaces that decouple producers from consumers. Humans and AI agents consume the same APIs, which means MCP gateways built around standard APIs give agents the same access surface that human tooling uses. Plug and play lets teams swap implementations without disrupting dependencies, while progressive migration lets teams opt in at their own pace guided by comparative DORA telemetry to benchmark real-time improvements in deployment frequency and lead time for changes. 

Immutable Infrastructure: Immutable infrastructure completes the picture. Environments are rebuilt from versioned images rather than patched in place, eliminating configuration drift and snowflake systems. A declarative state in Git means every component—infrastructure, policies, pipelines, AI configurations—is versioned, auditable, and rollback-ready. For AI workloads, specifically, model versions, prompts, and RAG indices become immutable artifacts with full lineage tracking, which is essential for private AI auditability and regulatory compliance. 

Critical Yet Within Reach 

Infrastructure is what makes this evolution tangible. Every golden path, every self-service portal, every agentic workflow ultimately resolves to a provisioned resource, a container, a GPU instance, a VM, a network boundary, or a storage volume. As platform engineering enters the AI era, the infrastructure layer must scale with it: Provisioned dynamically, governed continuously, and optimized across every workload class and persona.

It needs to move from developer-centric provisioning to a dynamic, AI-ready foundation that serves every persona, enforces policy at runtime, and scales on demand. Infrastructure is not just the plumbing behind the platform; it is the platform’s most strategic layer, and the primary determinant of how far any platform evolution can go.

For organizations that have invested in Platform Engineering 1.0, shifting to a Platform is an evolution, not a reset. Existing IDPs and golden paths set the foundation for what comes next. Platform engineering became universal precisely because it solved a real problem and then coasted. Platform Engineering 2.0 is an opportunity to make platforms what they should be in the AI era: Engines of safe innovation for tomorrow, rather than polished cages for yesterday’s workloads.