The AI Agent Protocol Stack: After Six Layers, the Bottom One Just Reached the Physical World

One diagram, and the box at the bottom of it

I spent a while putting this together. It answers a simple question: when I say “get this done for me,” which protocols does that sentence pass through before it becomes something that actually happens in the world?

Six layers, top to bottom. It starts at human intent and lands on robot arms, sensors, and PLCs. Every layer in between has a name, a responsibility, and a spec taking shape.

And the box at the bottom — MHS, the Model Hardware Standard — scores ★★☆☆☆ in the maturity table, the lowest in the entire diagram.

I saved it for last, but not because it matters least. Quite the opposite: the five layers above it all describe how AI interoperates inside the world of information. Only the bottom one describes how it leaves the screen. And that layer only got its first serious candidate spec at the end of August.

This post has two halves. The first walks the diagram. The second is only about that bottom box.

Part one: what the diagram says

Six protocol layers, top to bottom

AG-UI / A2UI — Human / UI Layer (Agent ↔ Human)

The layer closest to people, and it is really two things. AG-UI handles visibility into the process: real-time streaming, events, state updates — so that when an agent runs a long task, you can see where it is, what it is reasoning about, and where it got stuck. A2UI handles the interface itself: letting the agent describe the UI components, forms, and actions to render, instead of returning a wall of text.

One is “let me see what it’s doing.” The other is “let it decide what I see.” The first is a trust problem; the second is an expressiveness problem.

Agent Core — the brain

Strictly speaking this is not a protocol layer; it is the thing the protocols surround. The diagram splits it into six: reasoning, planning, memory, knowledge, skills, goals.

Worth reading one at a time, because these get conflated constantly. Knowledge is the facts and rules it holds; memory is what it remembers about this run and past ones — not the same thing. Skills are the actions it can execute; planning decides which skills, in what order — also not the same thing. What hurts in practice is usually cramming several of these into one abstraction.

A2A — Agent Coordination Layer (Agent ↔ Agent)

Agents discovering each other, delegating tasks, syncing state, exchanging results. This layer solves an organizational problem more than a technical one: when you have a hundred agents, who knows who exists? Who is allowed to task whom? Where does the result go?

Off to the side sits an optional directory / discovery service. Every layer in the diagram has one of these grey optional registries hanging off it — that design choice comes back below.

WebMCP — Web Interaction Layer (Agent ↔ Web)

Websites exposing machine-actionable interfaces to agents: declarative APIs, structured actions, an agent runtime in the browser.

The existence of this layer is itself a statement. The entire web was designed for human eyes, so agents can only use it by scraping DOM, guessing at buttons, and simulating clicks — brittle and expensive. Rather than have agents keep pretending to be people, let the site say directly: here are the actions you can call.

MCP — Tool & Data Layer (Agent ↔ Tools / Data)

The most mature layer today (★★★★☆), and the one I use most. Standard tool access, data operations, context management, universal connectors.

MCP won because the problem it solves is narrow enough: it says nothing about how the agent thinks, only what the interface looks like when the agent reaches for something. Protocols with clean responsibility boundaries spread faster than anything else.

UCP / AP2 — Commerce Layer (Agent ↔ Commerce)

Payments, transaction status, refunds and disputes, reconciliation and settlement. For an agent to actually finish something on your behalf, money usually changes hands somewhere. This sits at ★★★☆☆, and what’s blocking it is mostly not technical — it’s liability. An agent makes a charge you didn’t want. Whose fault is that?

MHS — Physical World Layer (Agent ↔ Hardware)

Device discovery and identity, safety limits and envelopes, natural-language instruction, safety-first abstraction. The whole second half is about this one.

The brain, and a loop that’s easy to skim past

Below Agent Core there’s a dashed box: the Experience Feedback Loop.

Execution results → Memory → Knowledge → Better Capabilities

It’s easy to read as decoration, but it is the only arrow in the entire diagram that points back up. Everything else flows downward; this is the one line that carries results from the furthest downstream back to the furthest upstream.

Without it, the diagram describes a very long pipe — intent goes in the top, action comes out the bottom, end of story. With it, it describes a system that gets better. I wrote about the same thing in AI-HIL, though I put it differently then: “every successful bug fix gets recorded as knowledge.” The value of closing the loop isn’t automation. It’s accumulation.

The five bars on the left, and why they’re vertical

Down the left side: Identity & Auth, Authorization & Policy, Security & Trust, Audit & Observability, Safety & Human Oversight. The header reads “Cross-Cutting Foundations (Apply to All Layers).”

They’re drawn as one column running the full height, rather than as a layer in the stack. That is the most important structural decision in the diagram.

Because not one of these can be solved at a single layer. “Who authorized this agent?” is one question at A2A (how do agents trust each other), a different one at UCP (who can charge this card), and a completely different one at MHS (who can make this arm move). You cannot do identity once at some layer and declare everything below it safe.

Likewise, “human approval” is a UI component at the interaction layer and a safety mechanism at the physical world layer — same concept, an order of magnitude apart in weight.

Drawing them vertically says: you have to do all five, once per layer.

The table in the bottom right, where the point of this post is hiding

The summary table lines up all six layers by maturity:

Five layers sit between ★★★ and ★★★★. Only MHS lands at ★★.

That gap is what the diagram is actually about. On the information side, the protocols are largely laid: agents can find tools, task each other, read the web, settle a payment. But ask one to turn a valve, swap a wafer, or focus a microscope — that side is almost empty.

And the box that had been empty for a long time just got its first piece at the end of August.

Part two: MHS and Physical AI

What MHS is: two verbs and a file

On August 27, 2026, Anthropic previewed the Model Hardware Standard (MHS) — a shared specification for AI agents to safely operate physical devices.

The design is severely restrained. Restrained enough that your first reaction is “that’s it?”:

Two primitives. read gets a value off the device (“get temperature”), write sets a parameter (“set temperature”). That’s the set.

One reference file. One per device, generated automatically from a natural-language description of the hardware, telling the agent three things:

1. what the machine can measure
2. what the machine can change
3. which safety limits it must respect — the kind the system actually enforces

And it isn’t tied to a model. MHS is model-agnostic; any agent harness can reach it over standard protocols, including MCP. So it isn’t a competitor to MCP, it’s an extension of it: MCP standardized software tools; MHS wants to do the same for physical machines.

The stated number is integration time dropping from weeks to hours. It’s currently a limited research preview, with partners spanning biotech (Genentech), academic research (University of Washington, Carnegie Mellon, HHMI Janelia), quantum computing (QuEra), and automated biology (Tetsuwan); on the hardware side, Universal Robots, Doosan Robotics, Tecan, QIAGEN, Danaher, Automata, MBF Bioscience, and AWS. Anthropic says it will open source the full specification after working through safety evaluations and best practices with the launch cohort.

Why this registers as an event to me

At first glance it looks too thin. Two verbs — how much can that express?

That’s exactly why it might work. Look back at why MCP won: not expressiveness, but a narrow enough remit. A protocol spreads not by covering every case, but by getting ten thousand different implementations willing to plug in. read / write plus a declared safety envelope is narrow enough that a PLC from 1979 and a six-axis arm from 2026 can be described through the same interface.

The real weight is in the reference file. It takes knowledge that previously lived only in engineers’ heads and PDF datasheets — what this machine can do, what it can’t, and which line you don’t cross — and turns it into something machine-readable that gets enforced at execution time.

That’s the fundamental difference between the physical world and software: software errors roll back; hardware errors crash, burn, and injure. A protocol reaching into the physical world that doesn’t make safety limits a first-class citizen doesn’t deserve to exist. MHS writes safety limits into the most basic device description. I think that ordering is correct.

I’m biased about this, and I know where the bias comes from

Honest disclosure: my enthusiasm for MHS is not neutral.

I spent fourteen years on edge products at Ubiquiti — on-device AI in UniFi cameras, thirty million managed devices. I wrote something in Why I’m Building the Edge Intelligence Stack that now reads like I was waiting for this:

Tools that let AI agents interact directly with hardware. Not “write a mountain of glue code to stitch things together,” but clean protocol interfaces that let AI flash firmware, start debuggers, and read sensors.

That was the third of three core needs I listed. And AI-HIL (ai-hil-mcp) is that layer, hand-carved for my own use: five MCP servers — JTAG, serial, vision, audio, build-flash — so Claude Code can read its own logs, measure its own current draw, flash its own firmware, and verify its own fix.

So MHS isn’t unfamiliar news to me. It’s someone standardizing the layer I’ve been building by hand for six months.

There are two ways to react to that. One is “my thing just got obsoleted.” The other is “my bet just got validated, and now there’s a foundation under it.” I’m firmly the second — because the biggest frustration in building AI-HIL was never technical. It was rewriting glue code for every new device. That isn’t a problem effort can solve. That’s a symptom of a missing standard.

Taking ★★☆☆☆ seriously

I scored it ★★ and I meant it. The unsolved problems in this layer are hard:

How do you validate the safety envelope? The reference file declares limits, but declaring isn’t being correct. Who guarantees that the boundary written in that file is the same as this machine’s actual physical limit? A wrongly declared limit is more dangerous than no limit at all, because the system trusts it. Software has a much gentler version of this problem (a bad type annotation crashes, at worst). The physical world has no gentle version.

Failure handling. Network drops, agent dies, command lands halfway — where does the arm stop? read / write are stateless verbs; physical devices are stateful. Somebody has to fill that gap.

Latency. Many physical control loops tolerate milliseconds; LLM inference takes seconds. MHS belongs to “decide what to do,” not “close the control loop in the moment.” These two must stay separate, or people get hurt. It’s also one of the reasons I keep arguing intelligence has to move to the edge.

Liability. An agent follows a correctly specified reference file, issues a legal command, and a production run is scrapped. Who’s responsible? Regulation hasn’t caught up, and it will move slower than the technology.

The long tail. The launch partners are lab equipment and advanced manufacturing — high-value, well-standardized, funded for integration. But most of the physical world is a 2009 PLC in the corner of a factory, documentation lost, vendor defunct, and one veteran technician who knows how to tune it. That tail is the real problem.

★★ is an accurate description. But the distance between ★★ and nothing isn’t two stars — it’s whether there’s a starting point at all.

After All in AI: go down, not sideways

For the past two years my answer was All in AI. That was an answer about whether to commit. That question is settled now, so it becomes a different one: committed to what, in which direction?

My answer is down, not sideways.

Sideways means wiring up a few more SaaS tools, writing a few more agents, copying the same information-world capability into the next scenario. The marginal return there is falling fast, because everyone is paving, and paving the same ground.

Down means connecting AI to the places software hasn’t eaten yet: production lines, labs, farms, fleets, grids, warehouses. These share one trait — the bottleneck was never model intelligence. It’s that data can’t get in and commands can’t get out. Sensor signals sit on an industrial PC with no network. The veteran’s know-how sits in his head. The equipment’s operating envelope sits in a paper manual.

Something like MHS solves the “commands can’t get out” half. And once that half is through, the value of the other half finally cashes out — because you can finally close the loop. Read plus write is a feedback loop. Read alone is a report.

Thinking about the next decade, where every industry runs the “connect physical process to intelligence” project once, and the first shared spec has only just landed — that’s a lot more interesting than one more chatbot.

What I’m going to read and build next

No timeline, but the direction is specific:

Read. The MHS research preview announcement and the full spec when it opens, focused on three things: what the reference file schema actually looks like; how safety limits get enforced (declarative checks, or runtime interception); and where the boundary with MCP is drawn.

Build. Take the three existing servers in ai-hil-mcp — JTAG, serial, vision — and rewrite a version against the three MHS ideas:

1. Can my current tool interfaces collapse into read / write? What refuses to collapse? Whatever refuses is where the real boundary of this abstraction lies.
2. Write a reference file per device — what it measures, what it changes, what the limits are. My guess is that taking the third one seriously will surface a pile of things I never actually thought through.
3. Test the envelope on a real device: deliberately issue an out-of-bounds command and see which layer stops it. If nothing stops it, the whole thing is just a claim.

Number 3 is the one I most want to run. The first two are paperwork; only the third tells me whether the abstraction has teeth.

It’s still a long road. But compared to six months ago, carving glue code alone, there’s at least a line on the ground now.

References

• Previewing the Model Hardware Standard — Anthropic (2026-08-27)
• Anthropic pushes into physical world with new standard to help AI agents operate machines — CNBC
• Model Context Protocol
• On this site: AI-HIL: Giving Hardware Eyes and Hands, Why I’m Building the Edge Intelligence Stack, AI-HIL MCP project