Dora NodaOn July 21, 2026, CNCF published the sharpest statement yet of where platform engineering is headed: WSO2's Lakmal Warusawithana arguing that internal developer platforms were built on one load-bearing assumption — the primary consumer of the platform is a human developer — and that AI agents, now provisioning infrastructure, deploying apps, and investigating incidents alongside humans, break that assumption completely. The essay, "Platform engineering for the agentic enterprise", doesn't ask for a chatbot on the dashboard. It asks for a checklist: distinct identity, scoped permissions, a clear audit trail, machine-readable APIs, a shared context model, and reusable skills — enforced identically whether the caller is a developer in a portal, an SRE in a CLI, or an agent invoking an MCP server.
That checklist is concrete enough to score. So here is the verdict up front, grading each of the essay's seven requirements against what a self-hosted, Render-compatible PaaS actually ships today:
| # | Essay requirement | Bex surface | Verdict |
|---|---|---|---|
| 1 | Machine-readable APIs for every consumer | Render-compatible REST + GraphQL, graded OpenAPI contract | Shipped |
| 2 | An agent-native interface (agents consume via MCP) | api.bex.co/mcp: Streamable HTTP, OAuth 2.1, scoped tools | Shipped |
| 3 | Distinct identity per actor | OAuth client identity + workspace roles per caller | Shipped |
| 4 | Scoped permissions | bex.read / bex.write / bex.sensitive, per-workspace auth, human-only credential minting | Shipped |
| 5 | A clear audit trail | Workspace audit logs (who requested what, on which resource) | Shipped |
| 6 | A shared context model ("context is the new foundation") | llms.txt, raw-markdown docs, graded API catalog — but no unified ownership/topology graph | Partial |
| 7 | Reusable skills and built-in agents | Nothing shipped | Missing |
Five shipped, one partial, one missing. The rest of this post shows the evidence behind every cell, names the enterprise-IDP baggage a self-hosted team can safely skip, and orders the remaining homework.
What the essay actually demands
Three claims carry the whole argument. First, the platform's managed assets expand from one to three: applications remain central, resources (databases, storage, models, secrets, identity providers) become first-class objects with their own lifecycle and governance, and AI agents become first-class software actors that reason over context and operate the other two. Second, the platform's consumers double: humans and agents, each through interfaces suited to them — portals, CLIs, and GitOps for people, MCP for agents — but all "governed through consistent security controls, policy boundaries, and operational guardrails." Third, and most original: context becomes a first-class platform capability. An agent debugging a failed deploy needs what a senior engineer reaches for — ownership, topology, dependency history, applicable policies, past incidents — as one coherent model, not scattered dashboards.
Two accuracy notes before we score. This is a CNCF-published member essay, not an official CNCF report or conformance bar — treat it as the best-articulated version of an industry direction, which the corroborating signals below suggest it is. And its worked example, OpenChoreo, is a CNCF Sandbox project: promising and shipping real MCP servers, but Sandbox maturity means "still proving itself," not a production-grade reference.
The direction itself is well corroborated. KubeCon North America 2026 added a dedicated AI Inference + Agentic track; PlatformEngineering.org's State of Platform Engineering Report (Volume 4, 518 practitioners) frames 2026 as a dual mandate of augmenting platforms with AI while serving AI workloads; Gartner projects 40% of enterprise applications will embed task-specific AI agents by end of 2026. The counterweight sharpens the essay's point rather than dulling it: Gartner also predicts over 40% of agentic AI projects will be canceled by end of 2027 over cost, unclear value, or inadequate risk controls. Governance for non-human callers isn't enterprise theater — it's what keeps agent projects alive.
Row-by-row: the evidence
1. Machine-readable APIs — shipped. The essay requires every consumer to operate the same platform through interfaces fit for them. Bex exposes REST (api.bex.co/v1), GraphQL (api.bex.co/graphql), and MCP from one set of core operations, and its REST surface is a pinned, graded Render-compatible OpenAPI contract — an agent can read the machine-checked catalog instead of scraping docs. The API reference grades each operation against implemented backend routes, so "advertised" and "works" stay in sync.
2. Agent-native MCP interface — shipped. The essay names MCP as the agent's door into the platform. Bex runs one MCP server at https://api.bex.co/mcp over stateless Streamable HTTP, with OAuth 2.1 discovery (RFC 9728/8414 documents included) or API-key exchange for headless clients, and tool families covering services, deploys, logs, Postgres, env vars, jobs, sandboxes, and workspaces. The MCP server doc and connect-an-agent guide walk from claude mcp add to a first deploy-from-chat.
3. Distinct identity — shipped. "Giving each actor a distinct identity" is the essay's first governance demand, and the industry has converged on it independently: Descope's Agentic Identity Hub 2.0 manages agents as first-class identities with OAuth 2.1 and tool-level scopes, and the OASIS agentic-IAM work says agents must be identities distinct from both human users and service accounts. Bex authorizes every MCP and API call against the caller's OAuth identity with workspace roles enforced server-side — there is no shared god-token path where agent actions blur into human ones.
4. Scoped permissions — shipped. Three scopes (bex.read, bex.write, bex.sensitive) separate reads from mutations from secrets access, every workspace-scoped tool checks the caller's access to that workspace, and — the sharpest detail — durable API-key creation requires an authorized direct human caller, so a machine key or third-party agent cannot mint itself new credentials. Least privilege for agents is enforced by the platform, not requested in a prompt.
5. Audit trail — shipped, with one caveat. Workspace audit logs record who requested each operation and which resource it concerned — exactly the essay's "clear audit trail." The caveat is honest scoping, not a gap in the model: audit reads need workspace-management access (machine keys hold the developer role and can't read history), and the store depends on configured control-plane storage. An agent can be fully audited; it just can't audit itself.
6. Shared context model — partial. This is the essay's signature demand and the weakest shipped row. What exists is genuinely useful: llms.txt plus raw-markdown docs give agents a stable, crawlable picture of the platform, and the graded API catalog is machine-readable state. What's missing is the unified graph the essay describes — ownership, topology, dependency history, and past incidents as one queryable model rather than separate tools (list_services, list_logs, get_metrics) the agent must join itself. Reads work; reasoning over joined context is still the agent's homework.
7. Skills and built-in agents — missing. The essay's reusable skills (SRE, security, compliance, FinOps task packs any consumer can invoke) have no bex equivalent yet. The platform gives agents tools and guardrails but no packaged expertise — every deploy-investigate-remediate loop is hand-rolled per tenant. This is roadmap, not architecture: the identity, scope, and audit rows above are the prerequisites, and they're done.
The enterprise parts a self-hosted team can skip
The essay's requirements survive contact with a self-hosted PaaS remarkably well — but its enterprise-IDP framing carries three assumptions a git-push platform should decline.
Backstage-style catalogs. The enterprise telling centers a service catalog engineers browse. A self-hosted PaaS tenant doesn't browse services; they push a repo and get a URL. The catalog's real job — a queryable inventory with ownership — matters, but its enterprise shape (a portal team curating entities) doesn't. A render.yaml Blueprint plus list_services is the same inventory in a form a two-person team maintains by accident.
Multi-step approval workflows. Enterprise IDPs route agent actions through human approval chains because fifty teams share one platform and one blast radius. On a self-hosted PaaS, the tenant is the team: the workspace boundary, the scope ladder, and human-only credential minting already contain the blast radius. What survives the translation isn't an approval workflow — it's a much smaller primitive, approve-before-mutate on destructive tools, which belongs in the homework list below, not in a ticketing queue.
A dedicated platform team. This is the deepest assumption: someone staffs the golden paths. Gartner forecasts 80% of large software organizations will run dedicated platform teams by end of 2026 — a headcount an enterprise IDP presupposes and a self-hosted tenant will never have. The whole point of scoring bex's surfaces above is that the tenant inherits identity, scope, and audit from the platform instead of building them.
As Forrester's Devin Dickerson put it on Red Hat's agent push: agentic development is the next productivity unlock, "but the path there doesn't require customers to re-platform." For the self-hosted reader the sharper version is: it doesn't require hiring a platform team either. A 2026 IDP buyer's guide landed in the same place from the other direction — the defining shift is that a platform must now be AI-operable, not just developer-operable — and AI-operable is a property of the interface, not the org chart.
The homework, in order
Three builds, sequenced by dependency:
- The unified context graph (fixes row 6). Join ownership, topology, deploy history, and incidents behind one queryable surface so agents stop hand-joining tool outputs. This is the essay's core thesis and the highest-leverage missing piece.
- Approve-before-mutate on destructive tools (hardens rows 4–5). Scopes contain which tools an agent may call; a confirmation gate on
rollback_deploy,failover_postgres, and secret writes contains when. Small primitive, large trust payoff. - A reusable skill pack (fixes row 7). Package deploy, investigate, and remediate flows as versioned skills any tenant's agent can invoke — the essay's skill layer, minus the enterprise catalog it was imagined living in.
None of the three requires re-platforming. Each composes onto the shipped rows: identity tells you who, scopes tell you what, audit tells you what happened, and the homework adds what it all means and what good looks like.
The platform is the product — for agents too
The essay's lasting line is that the future isn't "building platforms for AI" but evolving the platform into "the trusted operational foundation where applications, resources, and AI agents can work together." Scored honestly, a self-hosted PaaS is closer to that foundation than the enterprise framing suggests: five of seven requirements ship, the sixth is half-built, and the seventh is sequenced work, not a rethink. The gap was never headcount or catalog software. It was treating the agent as a user with an identity, a scope, and a paper trail — and that, it turns out, a small team can inherit from its platform instead of building itself.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Its MCP server and Render-compatible API treat your deploy agent as a first-class consumer: distinct identity, scoped permissions, and an audit trail from the first call. Star the repo on GitHub or deploy your first app today.
