Platform engineering solved the last era’s problem: golden paths, self-service portals and internal developer platforms let human developers ship without re-deciding infrastructure for every service. That era is ending.
Today 84% of developers use or plan to use AI coding tools, but only 29% trust the output. The change those tools generate is arriving faster than most platforms can verify it. Organisations average 109 machine identities for every human identity, 79 of them already AI agents, and only 5% have a complete inventory of those identities.
A platform already costs roughly $7.5 million a year and a 60-person team to run, and 42% of companies abandoned most of their AI initiatives in 2025.
Put those numbers together and this stops being a line item. Platforms built for human-paced, human-authored work are structurally incompatible with agent-speed demands. The rebuild decides whether AI spend compounds into capability or leaks away.
This series is your map through that rebuild: what actually changes, what an agent-native platform must become, why trust and identity are the new foundations, and how to decide whether and how to rebuild. Start wherever your current decision sits; each article stands alone, and together they form a reference you can return to as the rebuild progresses.
In This Series
- What Platform Engineering 2.0 Changes From the 1.0 Era — The evolution from golden paths to composable, API-first contracts.
- Treating AI Agents as First-Class Users of the Agent-Native Platform — Agent-native architecture and why MCP turns the developer portal into a machine-accessible control plane.
- The AI Verification Tax and the DORA Data Behind the Trust Gap — The evidence for why faster output is not the same as better delivery.
- Machine Identity and Why Prompts Are Not an Agent Security Boundary — Per-agent identity, the 109:1 inventory crisis, and enforcement outside the model.
- Assessing Platform Readiness and ROI Before Rebuilding for the Agent Era — Readiness, ROI, and the build-versus-buy-versus-compose decision.
What is Platform Engineering 2.0, and how does it actually differ from the 1.0 era?
Platform Engineering 1.0 standardised developer experience through golden paths on an internal developer platform, cutting cognitive load for human authors. Platform Engineering 2.0 keeps the IDP but rebuilds it for machine-speed, agent-driven work: composable, API-first contracts replace rigid, human-shaped templates, and identity, cost and security become first-class concerns. The difference is not a new tool — it is a change in who and what the platform serves, and how quickly it must respond.
Platform Engineering 1.0 earned its place by solving a real problem: every team was reinventing infrastructure, CI/CD and observability. Golden paths and self-service portals removed that repetition, and success was measured in reduced cognitive load. The community framing from PlatformEngineering.org captures it well: standardise the common case, keep humans moving.
Platform Engineering 2.0 does not throw that away. It rebuilds the same IDP for a different clock speed. VMware’s whitepaper is a useful reference map, worth reading vendor-neutrally. The framework organises the change into five pillars: an AI-native platform, a multi-persona experience, embedded FinOps, security shifted into the platform, and architecture that is composable by design. Use those pillars as an audit lens.
That evolution is best understood through what actually changes from 1.0, and it raises the follow-up: if golden paths worked so well for humans, what happens when an agent shows up at the door?
Where to go next: What Platform Engineering 2.0 Changes From the 1.0 Era
Why do golden paths become golden cages once agentic workloads arrive?
Golden paths work by assuming a human at each step: a developer who follows a curated route, makes a judgement call, and stops when something looks wrong. Agents do not follow curated click-paths; they need machine-readable contracts they can discover and call directly. When the platform’s one blessed path cannot accommodate that, agents route around it, producing shadow workarounds, drift and ungoverned infrastructure. The path that once reduced risk becomes the cage that concentrates it.
Golden paths are good at what they were built for. For predictable, human-authored workloads, the path standardises the common case and lets developers ship without re-deciding everything. That is why the mechanism spread quickly.
The failure appears when the workload stops being predictable and human-paced. Agents want a contract they can call, and if the blessed path cannot serve them, they go around it.
There is a deeper assumption too. Many 1.0 platforms leaned on immutable infrastructure, environments rebuilt from versioned images so nothing drifts. Agents spawn short-lived, mutable environments that do not fit that model.
The resolution is composability: API-first building blocks that humans and agents can assemble, instead of one blessed route. Where a golden path is a corridor, a composable platform is a set of Lego bricks. That is the core of what actually changes from 1.0. It sets up the next question: if agents are going to consume those bricks, what does it mean to treat them as proper users?
Where to go next: What Platform Engineering 2.0 Changes From the 1.0 Era
What does it mean to treat AI agents as first-class platform users?
A first-class user has identity, entitlements, rate limits, an audit trail and observable behaviour, and so must an agent. Treating agents as first-class means provisioning, scoping and revoking their access the way you would a human’s, but at machine-scale churn and without a human to confirm each step. The distinction that matters is using the platform versus calling it through a governed gateway. Agents need the latter, with bounded autonomy and traceable action.
Many platforms still treat an agent the way they would treat a forgotten script: hand it a key and hope. First-class means the platform knows who the agent is, what it can touch, how fast it can move, and what it did afterwards.
The churn is the hard part. A human gets provisioned once or twice a year; agents appear and disappear by the task. Provisioning, scoping and revocation have to happen at agent speed, not ticket speed, without waiting for an approval chain.
A governed gateway that enforces scope, budget and audit on every request is the heart of agent-native architecture and MCP.
Before the architecture, there is a maturity ladder to understand, and AI-native is not the same as agent-native.
Where to go next: Treating AI Agents as First-Class Users of the Agent-Native Platform
What is agent-native architecture, and how does it differ from AI-native?
The ladder runs AI-enabled to AI-native to agent-native. AI-enabled bolts a copilot onto existing tools; AI-native embeds models inside a product. Agent-native goes further: agents become a primary workload with their own runtime, identity and contracts, not an add-on. The practical difference is architectural — the platform must be designed around machine-speed churn, short-lived execution and delegated action, rather than a human interface with an AI feature.
Walk the ladder. AI-enabled is GitHub Copilot sitting beside your developer: the tool exists, the human drives. AI-native means the model is inside the product itself. Agent-native is the step that is easy to skip: agents become a primary workload the platform must host.
What makes a workload agent-native is runtime, identity and contracts: somewhere to execute, a way to be identified and scoped, and a machine-readable contract to call. Those three are the architecture. If you want examples, the open-source templates from Builder.io and agent-native.com are worth a look.
It is tempting to stop at AI-native. Shipping a model inside your product is different from designing your platform for thousands of short-lived, autonomous callers. That is the shift agent-native architecture and MCP explains.
The connective tissue that makes this tractable is MCP.
Where to go next: Treating AI Agents as First-Class Users of the Agent-Native Platform
How does the Model Context Protocol (MCP) change what a developer portal is for?
MCP standardises how agents discover and call tools and context, which turns a developer portal from a human-only interface into a machine-accessible control plane. Instead of a catalogue your developers read, the portal becomes a catalogue agents can query, with authentication, rate limits and policy applied at a gateway. That shifts the portal’s job from documentation and click-paths to governed, discoverable capability, which is a fundamentally different product.
A developer portal, whether Backstage, Red Hat Developer Hub or another, was built for humans: a place to read docs, find services and follow golden paths. MCP changes its centre of gravity. Once agents can discover and call tools through a standard protocol, the same portal becomes a machine-readable catalogue, with a gateway in front applying authentication, rate limits, policy and observability.
That gateway is the part worth getting right. The criteria are simple to name and hard to build: server federation, authentication and authorisation, horizontal scaling, and slicing tool lists so each agent only sees what it is allowed to use. Red Hat’s gateway is one implementation of that pattern. For the authorisation depth, agent-native architecture and MCP covers it.
The shift in the portal’s job matters because of the trust gap the next section quantifies. Faster output means nothing if you cannot verify it.
Where to go next: Treating AI Agents as First-Class Users of the Agent-Native Platform
What is the “verification tax” in AI-assisted software development?
The verification tax is the review, testing and correction effort required to trust AI-generated code — the work that eats the raw speed gain. Time saved writing code is re-spent auditing, prompting and hardening it, and the overhead compounds with tool sprawl and ungoverned change. The 29% trust figure is the symptom: if most output cannot be accepted as-is, the real cost is not generation speed but the verification loop you never planned for.
The writing speed gets the attention; fewer people count what happens next. The 2025 DORA State of AI-assisted Software Development report is the evidence: time saved writing is often re-spent auditing.
The 29% trust figure puts a number on it. When most AI output cannot be accepted as-is, someone has to review, test and harden it. Tool sprawl makes it worse, because every disconnected AI tool adds a decision about which one to trust.
The overhead is easy to miss because authoring speeds up while verification stays manual. It does not land evenly either: juniors gain more from assistance, while seniors gain less and absorb more of the review. The tax is only visible if you measure the right things, which is what the verification tax and trust gap unpacks.
Where to go next: The AI Verification Tax and the DORA Data Behind the Trust Gap
Why does higher AI adoption raise both delivery throughput and delivery instability?
AI compresses the inner loop — writing code — far faster than the outer loop of review, testing and integration can absorb. Change arrives in larger, faster bursts, so throughput rises while the verification that stabilises delivery lags behind. The 2025 DORA data captures this: adoption lifts output and instability together because the bottleneck has moved from authoring to absorbing change. Speed without commensurate verification is instability in disguise.
The paradox is counterintuitive but consistent. The 2025 DORA report states it directly: higher AI adoption increases both delivery throughput and delivery instability.
The mechanism is simple. AI makes writing fast, so more change arrives faster than the outer loop can absorb it. Instability is what you get when absorption falls behind.
It does not land evenly either. Juniors gain speed and a safety net; seniors absorb the review burden. The team’s average looks fine while senior engineers become a verification queue.
The platform’s response sits in three places: small batches, review adapted to AI output, and observability that shows the whole loop. Measure throughput and instability together. One without the other tells you very little. The verification tax and trust gap details how to read them.
Where to go next: The AI Verification Tax and the DORA Data Behind the Trust Gap
Why do production AI agents need their own identity instead of shared API keys?
A shared API key collapses attribution, revocation and least privilege into a single blob: you cannot tell which agent did what, cannot revoke one without breaking the rest, and cannot scope permissions. Per-agent identity restores all three — scoped entitlements, an audit trail, rotation and a kill switch. At 109 machine identities per human, with 79 of them already AI agents, keys stop being a credential and become an unmanageable liability.
A shared key is the convenient default and a poor fit at scale. If one agent misbehaves, you either break every agent that shares the key or do nothing.
The scale is what forces the issue. Organisations now average 109 machine identities for every human identity, and 79 of those are already AI agents, while only 5% have a complete inventory. You cannot govern what you cannot see.
The model that replaces the key is workload and zero-trust service identity, with least privilege enforced as policy and policy defined as code. The market is moving this way. Okta is acquiring Permiso to address the identity crisis, Docker launched Sandboxes as dedicated agent execution infrastructure, and the Open Secure AI Alliance formed in August 2026 around identity, permissions, isolation and guardrails.
That is the context for machine identity and agent security. The next question follows naturally: if you cannot trust the key, can you at least trust the prompt?
Where to go next: Machine Identity and Why Prompts Are Not an Agent Security Boundary
Why are prompts not a security boundary for AI agents?
Prompts are instructions to a model, not enforcement. Prompt injection can override them, and a model can misread, hallucinate or be socially engineered at machine speed. A boundary only works if it is deterministic and enforced outside the model: policy-as-code guardrails, sandboxed execution and approval gates for high-risk actions. Treating natural-language rules as a security control is the equivalent of asking politely and hoping.
It is an easy mistake to make: prompts look like policy. You write “do not delete anything without approval” and it feels like a control. A prompt advises a non-deterministic system; it constrains nothing.
The underlying principle is that policy has to be enforced outside the model. The PocketOS incident is one widely-reported example of what happens when it is not. A coding agent deleted a production database and its backups in nine seconds because it found a token with too much permission and the rules lived only in the prompt.
Policy-as-code guardrails constrain actions to pre-approved patterns. Sandboxed execution and workload isolation contain the blast radius. Approval gates or automated policy checks catch high-risk actions. Shadow AI, agent use that happens outside the platform through personal accounts and ungoverned keys, is what you get when prompts are the only control, because no SAST or DAST scan was built to catch prompt injection.
This connects back to the AI verification tax. Prompts cannot verify code any more than they can secure it. The cost of getting identity and isolation right is part of the readiness and ROI decision ahead.
Where to go next: Machine Identity and Why Prompts Are Not an Agent Security Boundary
How do you evaluate whether your internal developer platform is ready for AI agents?
Readiness is a capability test, not a feature checklist. Can your platform provision machine identities, enforce policy at machine speed, observe agent activity and isolate workloads? If any of those is missing, agents will route around the platform, and the shadow AI that follows is the real cost of inaction. Assess those four capabilities first. The tooling decision comes after you know which one you are actually missing.
The useful question is what the platform can actually do right now.
Shadow AI is your readiness signal. If your developers are already running agents through personal accounts and ungoverned keys, that is the answer written in spend and risk. The citizen developer and the autonomous agent are arriving whether or not the platform is ready. The choice is whether they operate inside guardrails or around them.
Work through the five pillars, starting with whichever capability causes the most friction today, because that is where sponsorship and measurable return already exist. Connect the gaps to agent-native architecture and MCP for what ready looks like.
Once you know the gap, the next question is what it costs to close it.
Where to go next: Assessing Platform Readiness and ROI Before Rebuilding for the Agent Era
How do you weigh the ROI and build-versus-buy decision for an agent-ready platform?
Judge ROI against the $7.5 million annual platform benchmark and the shadow AI cost you are already paying invisibly. The build-versus-buy question is really build-versus-buy-versus-compose: agent requirements shift monthly, so a fixed purchase and a fully bespoke build are equally risky. The decision turns on in-house capacity, identity and security depth, and embedded FinOps tooling — not on a vendor’s roadmap.
Start from the real baseline. A platform already costs roughly $7.5 million a year and a 60-person team to run, before agents multiply identities, spend and failure modes. Develeap’s breakdown is where that number comes from, and Accenture, The Next Platform and Syntasso triangulate around the same order of magnitude. On top sits the shadow AI cost you are carrying without a line item.
A fixed purchase and a fully bespoke build are both bets against agent requirements that shift monthly, and model pricing and capability move with them — the release cadence of models like Anthropic Claude makes that plain. Compose instead: assemble from parts you can swap.
Embedded FinOps matters more than most realise. Retrospective FinOps reports spend after the fact, which is too late for agent-speed token consumption. You need cost surfaced at provisioning time, tied to the workload.
Readiness, ROI and build versus buy folds all of this into a benchmark you can actually use.
Where to go next: Assessing Platform Readiness and ROI Before Rebuilding for the Agent Era
Resource Hub: Platform Engineering 2.0 Deep Dives
Start with the articles that explain the shift, then move to the architecture, then to the decision — or jump straight to whichever matches your current stage.
Understanding the Shift
- What Platform Engineering 2.0 Changes From the 1.0 Era — How golden paths became golden cages, and why composable, API-first contracts replace rigid templates.
- The AI Verification Tax and the DORA Data Behind the Trust Gap — The DORA evidence for why higher adoption lifts both throughput and instability, and how to measure real AI impact.
Rebuilding the Platform
- Treating AI Agents as First-Class Users of the Agent-Native Platform — What agent-native architecture means and how MCP turns the developer portal into a machine-accessible control plane.
- Machine Identity and Why Prompts Are Not an Agent Security Boundary — Per-agent identity, the 109:1 inventory crisis, and why enforcement must live outside the model.
The Decision
- Assessing Platform Readiness and ROI Before Rebuilding for the Agent Era — Readiness assessment, ROI against the $7.5M benchmark, and the build-versus-buy-versus-compose choice.
Frequently Asked Questions
What are the five pillars of the Platform Engineering 2.0 framework?
The framework extends platform engineering across five areas: an AI-native platform, a multi-persona experience, embedded FinOps, security shifted into the platform, and composable-by-design architecture. Platform-as-product, golden paths and self-service stay as the foundation. Use the pillars as an audit lens; the VMware whitepaper is a useful reference, but vendor-neutral framing matters. See the evolution from 1.0 for the full context.
How do you measure whether AI is actually improving delivery performance rather than just inflating output?
Track throughput and stability together, plus change failure rate, rework or verification time, and mean time to restore. Observability and tracing are the prerequisite. Without them you can only count output, not outcomes. The metrics that separate real AI impact from inflated output are detailed in the verification tax and trust gap.
How do you evaluate agent identity and security tooling without getting caught in vendor hype?
Start from a threat model, not a feature matrix. Does the option give you per-agent attribution, granular revocation, policy-as-code enforcement and workload isolation? Microsoft Entra Agent ID, Google Cloud Agent Identity and AWS Bedrock AgentCore are worth comparing, but NIST and the Open Secure AI Alliance provide the neutral baseline. The machine identity article walks through the evaluation criteria.
What does it actually cost to build and run an internal developer platform once agents are in the picture?
A platform already costs roughly $7.5 million a year and a 60-person team to run, before agents multiply identities, spend and failure modes. The cost that matters most is the invisible shadow AI spend and verification overhead you are already carrying. The agent-era ROI article folds these into a benchmark you can use.
Retrospective FinOps versus embedded FinOps — what changes when cost is enforced at provisioning time?
Retrospective FinOps reports spend after the fact, which is too late for agent-speed token consumption. Embedded FinOps surfaces cost at provisioning time and ties it to the workload, so you govern spend before it happens. The economics article connects this to AI cost governance and the FinOps Foundation.
Container isolation versus microVM sandboxes — which boundary is strong enough for running agents?
Containers share a kernel, so they are a weak boundary for autonomous, prompt-injectable workloads. MicroVM sandboxes add a hardware-backed isolation layer while preserving familiar tooling, which is why they are becoming the default for agent execution. The identity and security article explains where isolation fits in the broader guardrail stack.
Where can you find the 2025 DORA report and the Platform Engineering 2.0 whitepaper?
The 2025 DORA State of AI-assisted Software Development report is published by Google’s DORA program and cited throughout the trust gap article. The Platform Engineering 2.0 framework originates from a VMware-published whitepaper, referenced vendor-neutrally in the evolution article. Both are linked inline where their data is used.
