Platform Engineering 1.0 had a good run. Between 2019 and 2025 it systematised DevOps into golden paths, self-service internal developer platforms and platform-as-product thinking, cutting the cognitive load of shipping software.
Then a new platform user showed up: an AI agent that calls APIs instead of clicking through your portal. A platform built around curated click-paths starts to throttle it.
Platform Engineering 2.0 keeps the internal developer platform (IDP) but rebuilds it around composable, API-first contracts, so humans and agents can assemble capabilities at machine speed. Here is a sceptical, vendor-neutral read of what changed and whether 2.0 is a real evolution or rebranded 1.0. The wider agent-era rebuild is mapped here.
What is Platform Engineering 2.0 and how does it differ from Platform Engineering 1.0?
Platform Engineering 2.0 is the same internal developer platform, rebuilt around machine-readable, API-first contracts. Platform Engineering 1.0 optimised golden paths and self-service for human developers. 2.0 reorients that same platform for AI agents moving at machine speed, serving both personas from one foundation.
In its 1.0 era, the platform was an agreement between a platform team and developers: follow these golden paths and we’ll give you a faster, safer way to ship. It worked well enough that 90 per cent of organisations now run some form of platform and 76 per cent run a dedicated platform team.
2.0 keeps the IDP but changes the contract underneath it, expanding from the developer problem to the enterprise problem: AI, cost, security and multiple personas. PlatformEngineering.com frames it as an evolution, not a reset, an extension of the same IDP.
The framework behind the 2.0 label is co-authored by VMware and PlatformEngineering.org: one definition, not an industry mandate or a vendor endorsement. 1.0’s success was real, but optimised for a fixed set of human workflows.
Why do golden paths become “golden cages” for AI and agentic workloads?
A golden path becomes a golden cage the moment it encodes a human-in-the-loop assumption an agent cannot honour. Golden paths assume someone will click through the portal. An agent needs machine-readable contracts and scoped non-human identity, and it bypasses the blessed route when it can’t get them.
A golden path is an opinionated, well-documented way of building and deploying software. That’s fine for humans. It fails when the path assumes a human at every step: a UI-first flow, an approval gate, or an opinionated template.
An agent doesn’t work that way. It fires off many tool and process calls in parallel and consumes APIs rather than interfaces. PlatformEngineering.com’s analysis makes the point: the agent wants the same API surface a human tool uses, not a prettier portal.
The golden cage is what happens when an IDP is designed for control rather than consumption. PlatformEngineering.org calls it golden cage syndrome: abstractions become mandatory and restrictive, and developers bypass the paved road. When a developer wants to tweak a Helm chart parameter and the platform says “No, just click this button”, the paved road becomes a cage.
That workaround creates drift the platform can’t see, and an agent improvising without context turns missing guardrails into expensive risk. Golden paths stay useful. Agents don’t fit human click-paths, and non-human identity is what machine-readable access really needs. What breaks golden paths is the fixed, human-shaped template that cannot be composed or repaved.
What does composability mean in Platform Engineering 2.0 and why does it replace rigid templates?
Composability means delivering platform capabilities as modular, independently deployable, versioned, API-exposed building blocks that your team combines. Contracts replace templates because machine-readable, API-first contracts let humans and agents both discover, invoke and combine the same capabilities without any curated route.
Think of 1.0’s golden path as a single blessed route. Composability swaps it for golden LEGO bricks: networking, identity, logging and governance become discrete, versioned, API-first blocks. Your team can try a new framework or runtime while still using approved blocks for the boring parts.
Templates are human-shaped and opaque to an agent. The CNCF community describes composable platforms as the ones that can absorb AI without structural debt, built to be composed from day one.
Composability also forces a rethink of an inherited 1.0 assumption: long-lived, versioned, immutable environments rebuilt from images. Agents spawn short-lived, mutable environments by the handful, each needing a scoped identity, a declared lifespan and an automated teardown.
The operational payoff is repaving. When a CI/CD tool or observability stack sits behind a contract, you can swap a CNCF-compliant component without cascading changes. VMware’s framework puts it this way: platform engineering becomes a question of composition over build-versus-buy.
Once capabilities are composable, the question becomes what an agent-native platform actually does with them. Agent-native architecture answers that next, and the broader agent-era rebuild shows where composability sits.
Platform Engineering 1.0’s golden paths were real wins for human developers. They only break when agents arrive as a persona that cannot honour the human-in-the-loop assumption.
2.0 answers with composability: contracts plus swappable building blocks that let you and your agents assemble the capability you need, repaving your platform one block at a time.
The sceptic’s test is simple: if a vendor’s “2.0” hasn’t changed the core contract from golden path to a machine-readable, API-first one, it’s still 1.0 wearing new branding. That testable change is what makes 2.0 an evolution. For the wider picture, see the full Platform Engineering 2.0 map.
Frequently Asked Questions
Do AI agents replace human developers in Platform Engineering 2.0?
No. Agents are an additional persona on the platform, not a replacement for human developers. Platform Engineering 2.0 is multi-persona by design: humans keep golden paths and self-service IDPs, while agents consume the same capabilities through machine-readable, API-first contracts. The platform’s job expands from solving the developer problem to serving humans, agents and other workloads at once, which is why a single blessed path stops being enough.
What is non-human identity and why do AI agents need it?
Non-human identity is a scoped credential that lets an agent, service or workload authenticate and act without borrowing a human’s login. Agents need it because they run continuously and independently, so they require predictable, least-privilege access tied to the workload rather than a person’s role. Prompts are not a security boundary; identity and scoped permissions are the actual control point for agent-speed work.
Where can I find the Platform Engineering 2.0 framework or whitepaper?
The framework is co-authored by VMware and PlatformEngineering.org, and it is one definition rather than an industry mandate or a vendor endorsement. You can find it through PlatformEngineering.org’s community resources and VMware’s published framework page. Treat it as a reference point for what 2.0 is trying to solve, then test any specific platform claim against the contract-layer change rather than the marketing.
Is composability just microservices for platforms?
Not exactly. Microservices decompose an application into independently deployable services; composability decomposes the platform itself into modular, versioned, API-exposed building blocks. The shared idea is swappability, a team can replace a CNCF-compliant component without cascading changes. The difference is the contract layer: those blocks are machine-readable and discoverable, so both humans and agents can combine them rather than being locked to one route.
What does it mean to repave a platform rather than replace it?
It means you change the building blocks without tearing down the whole platform. When capabilities are composable and contract-governed, you can swap a CNCF-compliant component without cascading changes while the contract layer stays stable. The platform evolves incrementally, one block at a time, instead of forcing a rip-and-replace project. That is the operational payoff of composability in Platform Engineering 2.0.
How do I tell if a vendor’s Platform Engineering 2.0 is real?
Apply one sceptic’s test: did the platform change its core contract from human-paced templates to composable, API-first contracts? If the “2.0” is the same golden path with an AI chatbot bolted on, it is still 1.0 wearing new branding. A genuine shift shows up in machine-readable interfaces, scoped non-human identity and swappable building blocks, not in the pitch deck or the product name.
Are golden paths dead in Platform Engineering 2.0?
No. Golden paths remain valuable for human developers, so 2.0 does not discard them. The problem is fixed, human-shaped templates that cannot be composed or repaved, because they throttle agents and push them into shadow workarounds. In 2.0, golden paths become one option among many: humans keep a curated experience, while agents get machine-readable contracts for the same capabilities.
Do I need Kubernetes or CNCF tooling to adopt Platform Engineering 2.0?
No. Kubernetes and the CNCF ecosystem are a common substrate, not a prerequisite. The defining change is architectural: composable, API-first contracts that humans and agents can assemble. CNCF components help because they swap without cascading changes, which makes the platform repaveable, but any stack that exposes machine-readable, contract-governed capabilities can deliver the 2.0 shift.
How do you govern short-lived agent environments?
Govern them through the same contracts that created them. Each environment gets a scoped identity, a declared lifespan, resource limits and an automated teardown path, so the platform can see and revoke what it spawns. This differs from 1.0’s long-lived immutable environments: agents churn environments too quickly for manual approval, so governance must be machine-enforced rather than human-reviewed.
What should platform teams do first when moving to Platform Engineering 2.0?
Start by exposing your most-used capabilities as machine-readable, API-first contracts, then make them composable building blocks. Do not rip out golden paths or rebuild the IDP. Pick one high-frequency workflow, give it a contract and scoped non-human identity, and let an agent consume it. That single change shows whether your platform has moved from human-paced templates to agent-speed contracts.
