Agent as producer, agent as product: two platforms, one word

In an earlier post, I laid out a map: seven layers, two cross-cutting concerns, enough to place each term and know which layer your next problem belongs to. A homemade map. The question is whether it holds up against what the ecosystem describes on its own side.

The short answer: it converges with the CNCF and platform engineering on almost every boundary, it diverges on one point I stand by — and it runs up against a distinction few people make explicitly, even though it decides everything: the agent you produce is not the agent that produces. That is the thesis of this post. The rest is the supporting case.

The convergence: nobody draws the same layers, everybody describes the same tensions

The first surprise when confronting the map with the sources: layered models abound, but none is authoritative in the strict sense.

The documents that do carry authority don't draw layers. The CNCF Platforms White Paper lists capabilities, not strata. Gartner reasons in terms of supervision planes and goes so far as to write that static reference models are useless against agents that move at nanosecond speed — a position flatly opposed to the cartographic exercise. The authority exists, but it refuses to draw the map.

The models that do draw layers aren't authoritative: they come from independent analysts and vendor blogs. AIMultiple also proposes seven layers, with a moat/commoditization reading close to my buy-chart — but stacks governance as layer 7 instead of treating it as cross-cutting. The Letta/a16z stack, picked up by O'Reilly, holds in five layers oriented toward building an agent. Only Catio shares my stance: separating the components (perception, reasoning, memory, action) from the cross-cutting planes (orchestration, observability, security, governance).

So the exact breakdown varies from one map to another. What doesn't vary are the tensions described: model access to centralize, protocols to standardize, state to manage, cost to bound, governance to make omnipresent. My map discovers nothing; it files these tensions in a defensible order.

Platform engineering names the assumption that breaks

The most useful shift comes from an older discipline. The Platforms White Paper sets out two principles that apply to my map without alteration: the internal platform is a product, and you build the thinnest possible layer on top of managed implementations. Translated: layers 1, 2, and 5 are bought, 3 is built, the rest must stay replaceable.

Then, in "Platform engineering for the agentic enterprise" (July 2026), the CNCF names the implicit assumption of ten years of Internal Developer Platforms: the platform's consumer is a human developer. The agent breaks that assumption. It provisions, deploys, investigates incidents, triggers workflows. It becomes a consumer in its own right, with one additional requirement: its own identity, restricted permissions, an audit trail. The conclusion is explicit — not a separate platform for AI, but an extension of the existing platform.

Two consequences for my map:

• Layer 7 is broader than I had said. Portal, CLI, GitOps, and MCP server are four surfaces of the same platform. If they don't share the same governance model, you don't have one platform with four surfaces — you have two.
• Context becomes a capability, not an accessory. Topology, ownership, dependencies, deployment history: the agent diagnosing a failure needs to know who owns what, not just to retrieve a document. That is more demanding than layer 5's RAG.

The standards are hardening, in the direction of the map

On the standardization side, three dated signals confirm the trends the map announced:

• Layer 1 — conformance is arriving. The Kubernetes AI Conformance Program, launched in November 2025, defines a minimal baseline for running AI workloads. The March 2026 revision hardened the requirements (codified as Kubernetes AI Requirements) and took certified platforms from 18 to 31. A layer that gets certified is a layer that becomes commoditized: my "high" maturity rating is confirmed, and the risk shifts there toward the gateway rather than the runtime.
• Layers 4 and 6 — protocol governance changes the lock-in calculus. MCP was donated to the Agentic AI Foundation under the Linux Foundation in December 2025, joined by A2A in August 2026. My "low if standard protocol" is no longer a bet: both protocols are under neutral governance. What remains open is layer 6 itself — no standard yet describes how to orchestrate agents, only how they talk to each other.
• Cross-cutting planes A and B — the work is already framed. The Cloud native agentic standards document (CNCF AI TCG, March 2026) opens four workstreams: communication, observability, governance, security. Two points to keep as-is. The agent's identity is not the user's: the moment an agent acts outside a session or beyond its principal's perimeter, it needs its own workload identity (SPIFFE/SPIRE, scoped service accounts, short-lived tokens), otherwise the audit means nothing. And agentic observability is not application observability: tokens, inference cost, execution time, trajectories — OpenTelemetry's GenAI semantic conventions already provide enough to instrument.

The divergence I stand by: wall, not foundational layer

On one point, I don't follow the CNCF. It reasons from Kubernetes and treats governance as a mandatory foundational layer — without it, nothing starts. My map makes it a cross-cutting wall.

The nuance isn't cosmetic. A foundational layer is underneath: you lay it down, then you stack. A wall runs the full height: it applies to every layer, from inference to the interface. Treating governance as a base risks believing that once laid, it's secured. Treating it as a wall is a reminder that a permission governs the tool call (layer 4) just as much as the interface surface (layer 7), and that no layer is exempt from it.

Their framing is stricter than mine — "nothing starts without governance" is a good rule. But it's born of a Kubernetes context where the base is literal. Outside that context, the wall describes reality better: governance isn't a step, it's a permanent requirement.

The vendor framework: Platform Engineering 2.0

A third body of work is circulating, and it calls for a reading precaution. Platform Engineering 2.0 (June 2026) is a directional framework commissioned by Broadcom, co-written with VMware. Neither standard nor certification: Moor Insights puts it bluntly, it's a vendor argument, partly forward-looking, whose proposed implementation happens to sell infrastructure. Its five pillars remain largely product-independent — but you don't read them as a neutral foundational document.

They are, moreover, pillars, not layers. The versions that present them stacked up as a stack have rebuilt the model. Two of these pillars correct my map:

• Embedded FinOps. In my previous post, "the bill blows up" was attributed to the absence of per-call metering at layer 1. That's true but incomplete. Current cost tooling is retrospective: it tells you what you spent afterward. The pillar proposes surfacing cost at provisioning time, with its alternatives. Measuring isn't enough; you have to decide beforehand. Layer 1 was only half the answer.
• "Shift-down" security. Shift-left hasn't failed, but the agentic attack surface — prompt injection, inference leakage, unreviewed execution — is a runtime problem a pipeline scan doesn't see. Hence isolation pushed down into the substrate: microVM and sandbox (Firecracker, gVisor, Kata Containers) rather than a shared container, the moment layer 4 runs code nobody has read.

The distinction nobody makes: producing an agent, producing with an agent

This is where the confrontation becomes genuinely useful. Alongside PE 2.0, the category of agentic development platforms (ADP) has settled in, to which Forrester has devoted a vendor landscape since the third quarter of 2026: platforms where humans and agents develop side by side.

That is not what my map is about. And yet both carry the same adjective — "agentic." Two different platforms, one word:

• The agent as producer (ADP, PE 2.0): the agent writes the software. The bottleneck shifts from writing to shipping — PE 2.0 cites code volumes multiplied by two to ten. The platform has to absorb a throughput of PRs, reviews, and ephemeral environments it never had to handle.
• The agent as product (my map): the agent is the delivered software. What matters becomes memory, recovery after compaction, coordination.

The two share their base — layers 1 and 2 — and their two walls, then diverge sharply. No high-throughput delivery layer appears in my map, and that is deliberate: it belongs to the producer world. Symmetrically, layer 5 (memory, knowledge) is nearly absent from ADP models, and that's consistent — an agent that produces code doesn't need persistent memory; an agent you put in production does.

This distinction explains half the meeting-room misunderstandings. "We're going to put an agent on this" doesn't point to the same platform depending on who's speaking: one is thinking of a copilot that speeds up the team, the other of an autonomous service in production. Same words, different budgets, risks, and owners.

What the confrontation will have served

My map comes out neither invalidated nor sanctified. It converges with the ecosystem where it matters, diverges on governance-as-wall for good reasons, and gains two useful corrections — the cost decided beforehand, the security that descends into the substrate.

But the real gain is the producer/product distinction. It appears on none of the neighboring maps, and it's the one that decides whether your next "agent" needs a layer 5 or a high-throughput delivery layer. Before choosing a platform, ask yourself which of the two agents you're building. The word won't tell you.