Dora NodaIf you went looking for the CNCF Platform Engineering Maturity Model refresh expecting a project still in progress, you're a few months late — it already shipped. The Platform Engineering Technical Community Group kicked off the rewrite in Q1 2026, drafted it ahead of KubeCon + CloudNativeCon Europe, and released the updated model at Platform Engineering Day in Amsterdam on March 23, 2026. It's been live for four months.
That timing matters for anyone using this rubric to self-assess right now, because the useful question isn't "what's changing" — it's "what actually changed, and where does a real platform land on it." So here's both: a walkthrough of what the v2 rubric actually does differently from the 2023 original, and a concrete, un-flattering scorecard running a Cluster-API-managed, git-push self-hosted PaaS through all five of its aspects.
What the Refresh Actually Changed
The core structure didn't move. The model is still four maturity levels — Provisional, Operational, Scalable, Optimizing — scored across five aspects: Investment, Adoption, Interfaces, Operations, Measurement. If you assessed your platform against the 2023 version, the same axes still apply; nothing was renamed or dropped.
What changed is the content layered onto that structure, and the framing the community now reads it through:
| What shipped in v2 | What it means in practice |
|---|---|
| Real-world examples and scenarios added throughout | Each level per aspect now has concrete illustrations instead of abstract descriptions — easier to place your own platform without guessing |
| Language/terminology cleanup | Aligned wording across the Maturity Model and the companion Platform as a Product Whitepaper, which was refreshed on the same timeline |
| Explicit scope for "secure, governed integration of AI tools" into the SDLC | The rubric now expects platform teams to account for AI tooling as a first-class input, not a bolt-on afterthought |
| Released alongside a live community survey | CNCF is collecting self-assessment data through the rest of 2026 into 2027 to steer the next revision |
The bigger shift is conceptual rather than textual. At the same Platform Engineering Day, Netlify CEO Mathias Biilmann introduced "Agent Experience" (AX) — treating AI agents as primary platform consumers alongside humans, not an edge case retrofitted later. Syntasso's Abby Bangser made the sharper architectural point in her keynote: when platform engineering fails, "the problem is architectural, not about effort or tooling." One writeup of the conference summarized the whole moment as a move from portal-centric thinking — is there a nice UI on top of the platform — toward industrialized backend orchestration: does the system underneath actually hold up when a non-human caller starts hitting it at volume.
None of that shows up as a new row in the rubric. It shows up in how you're now expected to read the existing rows — particularly Interfaces, which is where an agent-callable API lives or doesn't.
The Five Aspects, As They Actually Read
Before scoring anything, here's the rubric itself, condensed to the question each aspect asks and what the top and bottom levels look like:
| Aspect | Question it asks | Provisional (L1) | Optimizing (L4) |
|---|---|---|---|
| Investment | How are staff and funds allocated to platform capabilities? | Voluntary, temporary assignments; no dedicated budget | Ecosystem enablement; specialists embedded across domains |
| Adoption | Why and how do users discover and use the platform? | Erratic, word-of-mouth discovery | Participatory; users contribute fixes and features back |
| Interfaces | How do users interact with and consume capabilities? | Manual processes, deep hand-holding required | Integrated, transparently embedded, automated provisioning |
| Operations | How is the platform planned, prioritized, and maintained? | Reactive, ad hoc, per-request | Managed services, automated lifecycle, clear shared responsibility |
| Measurement | How is feedback collected and turned into roadmap input? | Anecdotal, informal | Democratized data, leading indicators, cross-team collaboration |
Each aspect has two levels in between — Operational and Scalable — that the whitepaper describes as the shift from "a dedicated team exists" to "the platform behaves like a product with self-service and a roadmap." The model explicitly warns against chasing Optimizing everywhere: higher levels cost more in people and funding, and the right target depends on what your organization actually needs, not a scoreboard to max out.
The Scorecard: Running a Cluster-API Git-Push PaaS Through It
Here's the honest version — not every aspect lands at the same level, and it shouldn't. This is bex's platform (a self-hosted, Cluster-API-managed fleet with a Render-compatible git-push deploy flow) scored against each aspect as it stands today, not as roadmapped.
| Aspect | Level | Evidence |
|---|---|---|
| Investment | Operational | One team owns the platform full-time with a persistent budget line, but there's no separate product-management function yet — the gap to Scalable |
| Adoption | Scalable | Git-push is the default path teams reach for voluntarily once they've tried it once; nobody's mandated to use it, which is the Operational→Scalable line the rubric draws |
| Interfaces | Scalable, with an explicit Optimizing gap named | A Render-compatible REST/GraphQL API plus git push covers self-service for human callers with minimal maintainer support (Scalable). It does not yet cover the "integrated, transparently embedded" bar for agent callers — deploy-from-chat and an MCP server are roadmapped, not shipped, which is precisely the Interfaces gap the AX framing at KubeCon EU named for the whole industry, not just this platform |
| Operations | Scalable | Cluster API gives centrally orchestrated, standard-process provisioning across the fleet with continuous delivery pipelines — the Scalable bar. Optimizing's "clear shared responsibility model" with fully managed lifecycle across every tenant cluster isn't there yet |
| Measurement | Operational | Feedback is structured and channeled (issue tracker, direct user contact) but doesn't yet feed a formal strategic-insights loop — Scalable requires "crafted data collection yielding strategic insights," which is aspirational here, not current |
Average that out and the platform sits solidly in Scalable-leaning-Operational territory — which, per the model's own guidance, is a legitimate place for a team this size to be rather than a shortfall to apologize for. The one score worth dwelling on is Interfaces, because it's the aspect the community's own framing just re-centered: the rubric doesn't add a point for "has an API." It asks whether a non-human caller gets the same paved road a human does, and right now the honest answer for most self-hosted PaaS platforms — this one included — is "partially."
What Closing the Interfaces Gap Actually Requires
It's worth being specific about what moves Interfaces from Scalable to Optimizing, because "ship an MCP server" undersells the bar. The rubric's Optimizing description is "integrated services transparently embedded in existing workflows; automated provisioning" — for an agent caller, that means three concrete things, not one:
- Idempotent calls. An agent that retries a timed-out deploy request can't create a second service; the same call with the same intent needs to land on the same result every time, unsupervised.
- Machine-readable errors. A human reads "quota exceeded" and knows to file a ticket; an agent needs a structured error it can act on without a human in the loop, or the "self-service" claim quietly stops being true the first time something goes wrong.
- Cost and identity attribution per caller. Optimizing's Measurement aspect and Interfaces aspect meet here — an agent's spend has to be traceable back to the agent, not folded into whichever human's API key it borrowed, or the platform can't actually govern what it can't see.
None of those three ship as a side effect of standing up an MCP server; each is a separate design decision on top of it. That's the concrete reason this scorecard puts Interfaces at Scalable today rather than rounding up because a roadmap item exists.
What This Scorecard Doesn't Let You Do
Two things this exercise deliberately doesn't claim. First, it's not evidence the platform is "behind" — the whitepaper is explicit that reaching Optimizing across every aspect isn't the goal; over-investing in Measurement infrastructure a five-person team doesn't need is its own failure mode, not a virtue. Second, a self-assessment run once isn't a maturity program. CNCF's own survey exists because the model is meant to be reapplied as the platform and the org around it change — the useful output here isn't "we're a 2.6 out of 4," it's the specific, falsifiable claim that Interfaces has a named gap and a roadmap item that closes it, which is a claim you can go check again in six months.
Running This on Your Own Platform
The mechanics translate directly to any team self-hosting an internal developer platform, Cluster API-based or not:
- Pull the current model from CNCF's TAG App Delivery whitepaper page — it's the canonical source, not a summary.
- Score each of the five aspects independently. Resist averaging in your head first; a platform that's Scalable on Adoption and Operational on Measurement is a normal, specific shape, not a contradiction to resolve.
- For any aspect below Scalable on Interfaces specifically, ask the AX question directly: if the caller is an agent instead of a developer with a browser open, does the same self-service path still work unsupervised? If the honest answer is "no, that's on the roadmap," write down what closes it — that's the one line of this exercise worth revisiting.
Bex.co is the open-source, AI-native Render alternative — a Render-compatible deploy API on Cluster-API-managed machines you own, built with the agent-as-tenant question in mind from the start. Star the repo on GitHub or run the scorecard above against your own platform.
Sources
- A Living Blueprint: Evolving the Platform Engineering Whitepaper and Maturity Model — CNCF Cloud Native Platform Engineering Community
- Platform Engineering Maturity Model — CNCF TAG App Delivery
- KubeCon + CloudNativeCon Europe 2026: Returning to Amsterdam, 23–26 March — CNCF
- KubeCon EU 2026 Recap: Agents, Sovereignty, and the Rules of the Road — Kubermatic
- Evolving platform engineering for AI-native workloads — CNCF
