---
title: "What Platform Engineering says about where to bet in 2026"
description: "Fournier and Nowland's pillars hold in 2026: fund the platform as a product, drop the portal project, and build the golden paths so agents can walk them too."
url: "https://michael.zazon.us/notes/what-platform-engineering-says-about-where-to-bet-in-2026"
published: "2026-08-30T12:00:00-04:00"
kind: "book-notes"
subject: "operations"
tags: ["devops","agents"]
---
If I were making a 2026 platform bet for a bank or a Fortune 500 company, I'd fund the internal platform to run as a product (with an owner and users to win over) and drop the portal project. I'm basing this on ten years working with large financial institutions and Fortune 500 companies, now as a principal cloud architect. [Platform Engineering](https://www.oreilly.com/library/view/-/9781098153632/) by Camille Fournier and Ian Nowland (O'Reilly, 2024) supports this framing; both authors have led platform organizations, including in finance.

The book's diagnosis: an over-general swamp. Cloud and open source gave us unlimited building blocks, but teams chose differently, so a year on, the estate is mostly glue code, each service with its own pipeline and monitoring conventions. The explosion of choice coincided with rising demands: uptime, security, compliance, cost.

The book's remedy: a curated product built on real software abstractions, serving a broad base of ordinary application developers and operated reliably enough for the business to depend on it. Without these four pillars, the authors argue, you're not managing complexity, you're just shifting it. A developer portal isn't a platform, in my view.. it's the front door that still opens into the swamp. In fact, I'd argue that a portal-first platform program is the single most common way to burn a year or more with zero adoption.

Timing matters, and AI is why. DORA's [2025 research on platform engineering](https://dora.dev/capabilities/platform-engineering/) shows that nearly 90% of organizations now have some form of internal platform. But the more interesting finding was about quality: high-quality platforms turn AI adoption into a significant positive for organizational performance, while low-quality ones make it barely register.

The way I see it, in a regulated enterprise, the platform carries the security and compliance controls so teams don't have to reinvent them. Bounded freedom, speed within paths that already contain what the risk function and change board would demand. Better than twenty teams each building a flawed cloud setup in shared accounts. It makes the platform a prerequisite for any AI productivity case, not a side project.

The new kind of platform user is agents.. they request environments and open pull requests at machine speed, walking the same golden paths developers do. Datadog's post on [golden paths for AI agents](https://datadoghq.com/blog/golden-paths-for-ai-agents) describes making capabilities machine-readable (typed schemas, parseable errors). The controls live outside the agent (approvals, policy checks, CI gates, scoped credentials, an audit trail for every run).

I'd build a single golden path for people and agents, with guardrails inside the path instead of bolted on per-agent. Eventually a regulator will ask who approved a given change, and "the agent did it" won't fly with any risk function. If the approval is on the path, it doesn't matter if a developer or an agent made the change.. the answer is the same. I talked about agents as platform users in [my Team Topologies post](https://michael.zazon.us/notes/team-topologies-is-an-ai-agent-a-teammate-or-a-platform), but this is the practical follow-up.

[Diagram: Developer and agent on one golden path from template through deploy to audit trail](https://michael.zazon.us/notes/what-platform-engineering-says-about-where-to-bet-in-2026)

The strongest objection is that platform engineering is just layoffs rebranded. The platform team becomes a ticket queue, blocking other teams for weeks when something breaks.. a cost center that can't prove its worth.

My answer is that this is an unfunded platform. You usually can't prove value because leadership funded a team, not a product, so there's no roadmap owner and no measurement of outcomes. Put a product owner in place and give teams outcome measures they can feel.. time to first deploy, change failure rate, recovery time, audit evidence on demand. Leadership must budget time for application teams to migrate (the book warns that migrations routinely cost two to three times the estimate).

If I were advising a CIO on next year's platform budget, I'd make three calls. Fund the platform team as a product team, with an owner and a roadmap driven by developer needs. Stop funding portal projects as a goal, and bespoke pipelines that serve one team's pet stack. Put agents on the roadmap this year as a platform user, with a path that goes through the same controls.

The book talks about how a well-loved platform can fade into the background, and how being called boring is the highest compliment. I'd like to apply that measure to the agent persona: the platform is working when the agent's change passes the same approval and lands in the same audit trail as the developer's change. Nobody in risk or compliance needs to ask how it got there.