Name the layer before you merge the stack

Field note 16 / Eric MacDougall

Builders keep collapsing three different contracts into one "agent protocol" slide.

I keep seeing the same architecture sketch: a box labeled MCP, a box labeled harness, a box labeled sandbox, and a single arrow that pretends they are interchangeable parts of one protocol. They are not. They sit on different layers, answer different questions, and fail differently when you review them as one thing.

1. MCP is the tools and data plane: how a host exposes tools and resources. Enforcement still sits in hosts, gateways, and policy.
2. UHP (draft 2026-09-12) is the product-to-harness job contract: pick a harness, run a task, stream progress, continue via prior response, cancel, get files back. It is not a model API.
3. Execution substrate is where the agent runs: shared-kernel container with flags, managed sandbox partners, or microVM with its own kernel and private daemon.

Naming the layer is the working rule. Merging them early creates false interchange and false security reviews.

This piece extends the Batch 1 Pair E frame (MCP versus UHP) with the substrate row that Batch 2 Pair H cut open. Related Content Desk cards stay companion media for social and review boards; they are not a substitute for the site's overview film or daily package gates.

Why this is live this week

Vendor numbers below are attributed as vendor claims. Synthesis and Fleet Ops opinions are labeled as such. UHP stays a draft dated 2026-09-12.

Layer 1: MCP as tools and data plane

MCP contracts for how a host exposes tools and resources to a model session. That is the tools and data plane. Hosts, gateways, and policy still decide what is allowed, who may call it, and what gets logged. MCP does not become a permissions system by existing.

What MCP does not define: how a product starts a harness job, continues a session across turns, cancels work mid-flight, or collects artifacts when the job ends. Those are job-lifecycle concerns. Treating MCP as the whole agent stack is how a tools review gets mistaken for a product integration review.

Evidence boundary: this framing matches public MCP's role and the Radar harnesses-and-protocols theme. I am not inventing governance claims MCP does not make. Any claim that MCP alone "solves" permissions is untested synthesis and should stay out of a security sign-off.

Layer 2: UHP as product-to-harness job contract

UHP (draft 2026-09-12) puts the unit of exchange at a job or task. A product picks a harness, starts work, streams progress, continues via a prior response, cancels, and gets files back. That is a product-to-harness contract. It is not a model API.

Model APIs give you a turn. UHP-shaped surfaces give you a running agent with its own tools and session. JetBrains Air (announced 2026-09-22) frames Agent Client Protocol plus an ACP Registry as an IDE plug-in surface for third-party harnesses. That is adjacent, not identical: ACP is how an IDE hosts a full harness; UHP is how a product drives a harness job. Long-term coexistence outcomes between ACP and UHP are untested. Do not collapse them into one protocol box either.

UHP is still a draft. The thing to watch is a conformance suite across vendors, not marketing interchange claims. Production conformance is a watch item, not a fact I can claim from the draft text alone.

OpenAI's Agents API productizes a managed harness with sandbox partner options. Xiaomi's MiMo-V2.6 materials claim multi-harness RL transfer under a "You Only RL Once" framing; those are Xiaomi and Hugging Face claims until reproduced. The pattern underneath the vendor noise is the same: products want a job surface, not only a token stream.

Layer 3: execution substrate as its own category

Where the agent runs is not a footnote under model choice.

A disposable container with network none, a read-only root, and dropped capabilities is a solid flag floor. Those flags matter. They are not the same trust boundary as a microVM. That comparison is my read of the isolation split, not a claim that flags are useless.

Docker's Why MicroVMs engineering post (Sekaran / Gumbley) puts each sandbox in a dedicated microVM with its own kernel, a private Docker daemon isolated by the VM boundary, and no path back to the host. Docker's Cloud Sandboxes post (2026-09-24) sells local and cloud parity on that microVM isolation, plus sbx move for filesystem state, kits for coding agents, a secrets proxy, and pay-by-the-second metering. File access, network policy, and secrets are defined before the agent runs. That is substrate-level policy, not a prompt instruction.

OWASP's Docker Security Cheat Sheet still maps residual classes that flags alone leave open on a shared kernel: host kernel CVEs, docker.sock mounts, writable host paths that bypass a read-only root, image supply chain, missing resource limits, seccomp or AppArmor stripped "to make it work," container root without user namespaces. Inventory that list before you call a DIY shell equivalent to a microVM. Exact CVE inventory for a given DIY shell is untested here; the residual class map is the attributable OWASP trail.

Agents API's sandbox partner menu is useful product surface and also an integration tax if every experiment picks a different substrate. Cursor project machines sit in the same category: shared context and machine choice are substrate and session concerns, not tool-schema concerns. Treat execution substrate as its own row next to model choice and harness choice.

How the three layers compose

A clean stack keeps the seams visible:

1. A product starts, continues, and cancels work through a UHP-shaped or Responses-compatible job API.
2. The harness calls tools through MCP, or through native tools the harness owns.
3. The harness itself runs inside a chosen substrate. Network, secrets, and file policy are set before the agent starts.

MCP does not need to know which substrate holds the process. The product does not need to know MCP tool names to cancel a job and collect artifacts. The substrate does not need to speak UHP to enforce a kernel boundary. When those seams blur, reviews blur with them: a tools audit stands in for a job-lifecycle review, or a container flag checklist stands in for a kernel isolation decision.

What would be tested versus untested

Keep Xiaomi, Hugging Face, JetBrains, Docker, and OpenAI numbers attributed as vendor claims. Mark synthesis metric packs and policy opinions as such. Retain UHP draft status everywhere the protocol is named.

Working rules for Fleet Ops

1. Separate model client, harness driver, tool plane, and substrate in architecture docs. One slide, four named rows.
2. Security-review the substrate equal to model choice and harness choice. Flag floor and microVM ceiling are different reviews.
3. Prefer additive, Responses-compatible task surfaces when exposing agents to products. That shape aligns with UHP without waiting on a conformance suite.
4. Inventory residual risk on DIY flag shells (OWASP residual classes) before calling them equivalent to microVMs.
5. Do not let a tools-plane audit stand in for a job-lifecycle review, or a job API review stand in for a kernel-boundary review.

Close: name it, then measure it

Once the layers have names, the next measurement problem is the path the agent takes, not only whether it finished. Process provenance and oversight load belong next to task success rate: replay completeness of the job journal, human minutes to review an artifact diff, cross-file invariant gates. That is a complementary angle to Social Scout's reserved approvals hook; I am not stealing that frame here.

My rule: name the layer before you merge the stack. Then measure each seam on its own claim class.

Sources and publication limits

• MCP public role as tools and data plane; host/gateway/policy still enforce. Not a claim that MCP alone solves permissions.
• UHP draft dated 2026-09-12: job/task as unit of exchange. Production multi-vendor conformance remains a watch item.
• JetBrains Air (2026-09-22): ACP + Registry as IDE harness plug-in surface. Adjacent to UHP, not identical; coexistence outcomes untested.
• OpenAI Agents API: managed harness productization with sandbox partner options (vendor product surface).
• Xiaomi MiMo-V2.6 / Hugging Face materials: multi-harness RL transfer claims remain vendor claims until reproduced.
• Docker Why MicroVMs (Sekaran / Gumbley) and Docker Cloud Sandboxes (2026-09-24): microVM own-kernel + private daemon framing; independent escape-audit not performed here.
• OWASP Docker Security Cheat Sheet: residual class map for shared-kernel flag floors. Exact CVE inventory for a given DIY shell is untested here.
• Cursor project machines and Agents API sandbox partner menus: substrate and session concerns, not tool-schema concerns.

Editorial state: prepared master article adapted from the approved Content Desk draft. It is not registered as a ready weekly issue. Site production release gates still require the overview film package, day-range daily originals, companion readback, fingerprints, exact artifact, and Hawkeye preflight before any Pages upload. Companion still (card-site-name-the-layer.png) is staged under .scratch/ for social/review use; the public article template uses the shared control-map hero, not inline companion PNGs.