Eleven years ago, I resigned. Not out of weariness: out of clarity. I could see DevOps, the twelve-factor app, the cloud and containerization dissolving the very problem I was paid to solve. Distance was becoming cheap to cross. Proximity — co-located squads, you build it you run it, the product owner in the room — was winning the war. My job, the guy you send to rebuild connection across the boundary, was becoming a relic. I was right to leave. I'm starting to think I was wrong to believe the muscle had died with it.

Covid was the first reminder. Overnight, entire organizations went back to managing opaque, distant, instrument-governed teams — and I felt the old reflex switch back on, before most people grasped what was happening. The distance agile thought it had killed wasn't dead. It had just been hidden by the shared office.

Agents are the second reminder, and the harsher one. Deploying a fleet of agents means reinstating the exact distance I spent my career crossing — except there's no one on the other side to visit anymore. You don't grab a coffee with an agent. You don't align a fleet over a team dinner. The thesis of this post, stated bluntly: agile won the proximity war so completely that it destroyed the muscle that managed distance — and we are now redeploying distance without the tool that used to close it. You can't deploy cohesion.

Forget the offshore you think you know​

Before we go further, I have to kill a lazy reading, because it's the one that will make you tune out. When I write "offshore," you probably hear "cheap labor, far away, to drive costs down." That's the decorative version. It isn't the useful one here, and it isn't even the one that made delivery centers live or die.

What offshore actually produced was a social machinery: the whole set of rituals, templates and gestures we invented to collaborate across an opaque boundary with someone we couldn't watch work. The real problem was never the hourly rate. That was the line in the business case. The real problem — the one that sank a twenty-million-dollar center while another ran fine — was trust, alignment and knowledge transfer across a distance. Cost was the sales pitch; distance was the job.

And that's precisely the distinction agile blurred by winning. By removing the physical distance — co-located squads, embedded QA, continuous delivery — it made the social machinery invisible, then superfluous, then forgotten. We didn't decide that managing distance was pointless. We simply stopped having any distance to manage. The skill didn't expire: it lost its training ground. For a decade, nobody needed to board a plane to rebuild connection, because everyone was already in the same room — or one video call away from it.

Deploying agents reopens that ground. You suddenly inherit an industrialized, opaque workforce "on the other side" — and you discover that the gestures to manage it have been unlearned. Worse: some of them don't replay at all. That's where the inventory begins — what transfers, what has to be reinvented, and the one reflex that will betray you.

What transfers​

Two offshore disciplines replay almost unchanged on a fleet of agents.

Trust across opacity. I never watched an offshore developer code. I built rituals to manufacture a trust I couldn't observe directly: acceptance criteria, milestone reviews, quality gates, reporting. Exactly what you're rebuilding today around an agent — eval gates, human review, the approval ritual. The problem is identical: producing trust without seeing the work. The offshore reflex transfers with no retrofit, and it arrives pre-trained.

Knowledge transfer into the box. The SOW we wrote until it hurt, the runbook, the spec "so detailed it stings" — that's your context, your prompt, your agent spec, reincarnated. Same discipline, and above all same failure mode: under-specify, and the box produces something plausible and wrong, exactly the way the offshore center delivered a badly written instruction to the letter. Anyone who suffered through a sloppy SOW already knows why your agent goes off the rails — and knows the answer isn't "a better model," it's "a better instruction."

What has to be reinvented​

Here the transfer stops cold, and this is the heart of what I have to say.

The part of my job that had nothing to do with steering was cohesion: the travel, the team dinner, the physical presence that made two teams six thousand kilometers apart feel like they belonged to the same project. That gesture has no agent equivalent. You don't fly out to align a fleet. There's no one to shake hands with, no one to put at ease, no one whose cultural deference hides a disagreement a good dinner would draw out.

Which means cohesion, on the agent side, doesn't transfer: it gets reinvented, and it moves. It no longer lives between you and the box — there's nothing in the box to align. It lives between the humans in contact with the box. Your developers, your QA, your operators who each prompt, correct and approve a little differently. The drift I used to fight — twelve onshore principals, twelve subtly different instructions to a single center — replays in full, but entirely on the onshore side. The cultural boundary is no longer between here and there. It's between you and your colleague next to you, mediated by an agent that amplifies your divergences instead of absorbing them. The muscle to reinvent isn't "govern the agent." It's govern the coherence of the humans holding it — without the tool that used to work, proximity, since it's already there and solved nothing.

What betrays you​

That leaves one reflex, a single one, and it's the most dangerous because it's just close enough to seem transferable.

Offshore trained me for dilated time. The correction loop was expensive and slow: time-zone gaps, overnight round-trips, loss of real-time feedback. Hence the reflex: over-specify up front, batch the feedback, because a late correction is prohibitively costly. Twenty years of distributed delivery carved that reflex into a generation of managers.

The agent inverts all of it. The loop is collapsed: correction is free and instant. The manager who replays the offshore reflex will over-specify and under-iterate — write the giant SOW, launch, wait, inspect — exactly where the agent's economics reward the opposite: thin spec, fast loop, correct in the moment. And the irony closes: collapsed time is precisely the reflex agile sold me eleven years ago. The one I resigned for. The synthesis nobody holds yet is offshore-style trust governance running at agile cadence — the muscle of distance, but wired onto the short loop. Neither the offshore veteran nor the pure agilist has it: the first has the governance but the wrong tempo, the second has the tempo but forgot the governance.

The role we deleted​

Look at your org chart. The platform team owns the plumbing. The data team owns the models. Who owns the coherence of the humans in contact with the box — the drift across ten operators, the alignment of instructions, the trust you can't observe? Nobody. The box is empty.

It wasn't always empty. It had a name: the delivery manager, the service transition lead, the person you sent to rebuild connection across the boundary. Agile deleted that role because it had deleted the boundary — and it was right, as long as the boundary stayed deleted. Except we've just reopened it. We erased the role exactly as it became load-bearing again, and today we hand the hardest part — coordinating opacity — to the team least trained for it, convinced it's a tooling problem.

So here's the bet, dated, that you can throw back in my face in eighteen months: the teams that succeed at agent deployment at scale won't be the ones with the best platform, but the ones that rebuilt the muscle of distance — and they'll go find it among the very people agile declared obsolete. Not for their platform. For their scar tissue.

I left eleven years ago certain this job was finished. I'm starting to put my certainties away. You can deploy a fleet in an afternoon; you can't deploy the trust that holds it together. That one you still have to go and get — and there's no plane to catch anymore. You can't deploy cohesion. That's the whole problem, and it's yours now.

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.

Same meeting: for one person, it's an LLM call with a system prompt. For another, it's a multi-agent orchestrator with persistent memory and an execution sandbox. Nobody flinches. Everybody nods.

LLM, agent, agentic, long- / medium- / short-term memory, MCP, RAG, A2A… how do you file all of this, and what should I prioritize: buy, build, host, rent, distribute, centralize?

Hence this map: seven layers, two cross-cutting concerns. No ranking, no vendor to recommend to you — just enough to place each term and understand which layer your next problem is coming from.

Be warned, this is not a neutral model. Two biases run through it — treating security and observability as walls rather than as layers, and reading the same map in two opposite ways — and I own both further down. Other maps exist; this one has a point of view.

The map​

Let's go back to the shelf. Seven levels stacked up, one for each kind of toy: a spot on each shelf, and the rule that holds everywhere — nothing gets left lying on the floor. Tidying up isn't shoving things in at random; it's knowing which shelf each thing belongs on.

Seven stacked slabs, then, and two walls running their full height alongside them: the cross-cutting concerns. Each slab carries its typical components painted on the floor, color-coded by their nature — a differentiating brick to build, a managed service, infrastructure, an open standard, a user-facing surface, or a still-emerging component.

Why are security and observability cross-cutting rather than layers of their own? Because they don't slip in between two strata: they apply to each one. A permission governs the tool call (layer 4) just as much as the interface surface (layer 7); a trace instruments inference (layer 1) just as much as multi-agent coordination (layer 6). Filing them into a layer demotes them to the rank of a mere module — and you realize too late that they should have been everywhere. The "nothing gets left lying on the floor" rule doesn't live on one shelf: it holds for all of them.

The seven layers​

Where it breaks​

The map becomes genuinely useful when you use it as a diagnostic grid. A tidy shelf messes itself up the moment nobody knows which shelf anything belongs on anymore — each symptom below is a toy put back on the wrong level, or left on the floor.

If several rows ring true, there's a good chance they don't point to the same owner in your organization. And that, often, is the real problem.

Two readings of the same map​

If you own the architecture​

What you're trying to optimize: coherence, managed debt, legible dependencies.

• Layer 1 — the gateway is the only point that lasts. Centralizing model access behind a single interface decouples everything else from the vendor. Three days of work that save you thirty.
• Layer 3 — this is where the product is decided. What differentiates you isn't the orchestration framework, it's state management: recovery after compaction, step idempotency. The framework, you can swap out; a poorly thought-out state, you pay for.
• Layer 4 — MCP turns "N agents × M tools" into "N + M". And sandboxing stops being negotiable the moment the agent executes code.
• Layer 7 — this is your maturity test. If the agentic logic knows which surface it's running on, every new channel becomes a rewrite. Decoupling the runtime from the surface is exactly what separates a real platform from a demo.
• Cross-cutting — reframe the question. Not "is the agent safe?" but "what's its worst possible action, and who approves it?".

If you own the buying decision​

What you're trying to optimize: risk, total cost, dependency, maturity.

Five questions to ask before signing anything:

• Does model access go through a standard gateway?
• Do tools go through an open protocol (MCP)?
• Is memory exportable — and in what format?
• Do traces and costs export to the observability you already have in place?
• Are security and audit native, or sold later as an add-on?

A fuzzy answer on one of the five is fine. Two is a pattern.

What this map doesn't say​

What it gives you is modest, but useful: a shared vocabulary. The day the architect says "that's a layer 3 problem" and the buyer understands why it won't be fixed by switching vendors, the map has done its job. The room is never tidied once and for all — but at least everyone finally knows which shelf anything belongs on.

A word on standards, while we're at it. Beneath layer 2, an ISO standard already exists: ISO/IEC 23053 breaks down the anatomy of a machine learning system — model, training, inference, task. It's the normative dictionary for your layer 2, and the edge of layer 1. But it stops at the model: the agentic loop, MCP, multi-agent coordination, the surfaces (layers 3 through 7) have no ISO equivalent. As for the two walls, they fall under other standards in the same family (SC 42) — 42001 for governance, 23894 for risk — not 23053. In other words: the bottom half of the shelf has an official dictionary, the agentic half doesn't yet. That's not a hole in the map, it's why it's useful.

One question it doesn't settle remains: does it hold up against what the CNCF, platform engineering, and the analysts describe on their side? It converges with them on most of the boundaries, diverges on two points that I own — and stumbles on a distinction nobody really makes: the one between the agent you produce and the agent that produces. That's exactly the subject of a second post.