Your Platform Has a New User Class, and It Does Not Use the UI
The tools you buy have already rebuilt their primary interfaces for a reader that is not a person. Vercel shipped a language whose compiler output targets an agent, and Meta shipped a design system whose API, docs and CLI are designed together so a person and an assistant build the same way. Internal platforms are still assuming a human at a keyboard, and that assumption is what makes them legacy.

Vercel Labs has an experimental systems language called Zero. The premise, as InfoQ described it, is that “the primary reader of compiler output is no longer a human but an AI agent.”
That is a design decision with consequences all the way down. Every subcommand of the zero binary shares a --json flag and one diagnostic schema, so errors come back with stable codes like NAM003 and typed repair metadata rather than as prose. zero fix --plan --json returns a machine readable repair plan the agent can accept, edit or reject, instead of applying a fix blind. In v0.3.0 the compiler input became a binary graph store, and .0 source files were demoted to “human readable projections” of it.
The human’s format became the projection, which is the whole argument in one release note.
Zero is at v0.3.4 and I am not suggesting anyone adopt it. I am pointing at it because it is the most honest version of a change that is already happening in tools people do run, and once you have seen it stated that plainly you start noticing the softer versions everywhere.
The vendors have already worked this out#
Meta open-sourced Astryx, the design system behind a reported 13,000+ internal apps. The README calls it “built for how we build now: by people and the agents working alongside them,” which on its own is the kind of sentence I skim past. The next one is a constraint on the team that built it:
the API, docs, and CLI are designed together so a person and an AI assistant build the same way
Three surfaces held to one shape, because one of the readers is not a person. It is at 12.2k stars.
A design system is a strange place for this to surface, and it did not surface there once. Google Labs published design.md, described as “a format specification for describing a visual identity to coding agents,” pairing YAML tokens with markdown prose so that, in the README’s words, it “gives agents a persistent, structured understanding of a design system.” A separate project called impeccable shipped a design language you hand your coding agent within two days of it. When two specs for the same idea collide in the same week, the idea is not early.
The pattern is not confined to design. The Chrome DevTools team maintains chrome-devtools-mcp, which hands agents console messages with source-mapped stack traces, network request inspection, and performance traces with extracted insights. It has 49.5k stars. Chrome’s debugging surface was the panel for as long as there has been a panel, and the team that owns it has now published a second front door where the panel is not involved.
Figma wrote a first-class guide for the agent path into its own product. Vercel shipped a v0 API that generates, iterates, previews and deploys with no browser anywhere in the path. Cloudflare put out an entire platform, Cloudflare OS, with agents as a first-class user, and it took 486 points and 250 comments on the front page.
None of these teams is confused about who their users are. They have concluded they have two kinds, and the second one never opens the UI.
What that does to an internal platform#
Here is the part that matters if you run a developer platform rather than sell one. The paved road at most companies encodes assumptions that were free for twenty years and are now expensive.
It prompts. Interactive login, a device-code flow, a confirmation before the destructive step. All of those are good design for a person and a hang for anything else.
It answers in prose. The failure mode of a CLI written for a human is a sentence explaining what went wrong, which is fine to read and terrible to branch on. Zero’s stable error codes exist because the reader needs to dispatch on the failure, not understand it.
It puts the real capability in the admin panel. There is an API, and it covers seventy percent of what the panel does, and the remaining thirty percent is where the interesting operations live.
It has no discovery surface. A person learns the platform from a wiki page and a colleague. Nothing else can.
Each of those is individually small. Together they mean the agent that a team is now running against your platform is driving it through a browser automation harness, or through whatever REST endpoints happen to exist, or not at all.
What it looks like when you take it seriously#
ShipMore is the multi-tenant product I run, and the access model is written down as three levels rather than one:
| Level | Interface | Who uses it ||-------|-----------|-------------|| 1 — Agent | MCP plugin (primary), REST (secondary) | Claude Code, OpenClaw, any MCP-compatible client || 2 — Admin | Payload CMS admin panel | Humans reviewing, approving, auditing || 3 — Code | Next.js (full access) | Custom blocks, bespoke integrations |The ordering is the position. The admin panel is level 2, and its job in that table is review and approval rather than authoring. I did not arrive at that by conviction; I arrived at it because the authoring work was already happening through the agent and the panel kept being where I went to check it.
The CLI treats interactivity as something to detect and switch off, not as the default mode:
export function isInteractive(): boolean { if (!process.stdin.isTTY || !process.stdout.isTTY) return false if (process.env.CI === 'true' || process.env.CI === '1') return false if (process.env.GITHUB_ACTIONS) return false if (process.env.TERM === 'dumb') return false return true}Seven lines, and everything downstream of them changes. Non-interactive means JSON on stdout, errors as {"error":{"message":"…","code":"…"}} on stderr, no prompting for a missing flag, and auth from SHIPMORE_API_KEY with no interactive login path at all. There is also a shipmore commands subcommand whose only job is dumping the full command tree with flags and error codes as JSON, which is the discovery surface a colleague would otherwise have been.
The detail I did not anticipate is that this user class has a resource constraint the browser never had. Context is finite, so a generic endpoint that returns a whole document can fail a task outright by exhausting the caller’s budget:
pages: { description: 'Use custom tools page_list, page_get, page_get_block, and page_* mutators — generic collection find returns oversized documents.', enabled: { /** Prefer `page_list` / `page_get` — full-page find blows MCP context. */ find: false, create: true, update: true, delete: true, },},Turning off find for one collection is a capacity decision about the caller. No human-facing API design process would produce it, because no human-facing client has a budget that a large response can exhaust mid-task.
The harder half is what the interface is allowed to do. ShipMore’s rule is that agents create drafts and humans publish, written into the tool descriptions themselves so it holds at the surface rather than in a doc nobody reads:
name: 'page_create',description: 'Create a new page for a tenant. Pages are created as drafts by default. Returns the created page document.',That is the useful reframing of “level 2 is for humans.” The admin panel did not lose its purpose when authoring moved. It became the approval gate, which is a more valuable thing for it to be.
Where this loses#
Three real objections, and the first one is the one I keep arguing with myself about.
The protocol is converging back on plain HTTP. The MCP 2026-07-28 spec removed protocol sessions entirely, dropping the initialize exchange and the Mcp-Session-Id header that pinned a client to one instance, and added two mandatory headers, Mcp-Method and Mcp-Name. The reason is sound: gateways can now route on headers “using the same primitives it already applies to every other API” without parsing JSON bodies. But the InfoQ headline says the quiet part, which is that developers are asking whether that just makes it an API again. If the answer is yes, then a platform with a complete REST API, a non-interactive CLI and machine-readable errors has already done the work, and the agent-native framing is a rebrand of good API hygiene. I think that reading is about sixty percent right, and the remaining forty percent is the context budget and the approval model, neither of which falls out of REST.
You cannot see this user class. The team behind Armature put it precisely when they described why they built product analytics for MCP servers: “the conversation lived in our users’ AI client.” You get infrastructure observability, latency and errors and traces. You do not get intent, or the agent’s reasoning, or whether the run succeeded at what the person actually wanted, because those never touch your server. Building a primary interface for a population you cannot measure is a genuinely bad position, and the workaround on offer is asking agents to volunteer telemetry fields with their tool calls, which is not a measurement regime anyone should be pleased with.
Some of this is vendors selling a platform shift. The Cloudflare OS thread is instructive here. The top comment in it, at 186 points, called the announcement post “vague to the point of meaning nothing,” and another objected to the whole thing being Cloudflare-specific rather than built by a neutral party. A vendor with agents as a first-class user has a strong commercial reason to declare that everyone needs to rebuild, and 49.5k stars on a devtools MCP server measures interest rather than sustained production use.
Where I land is that the surface work is cheap and the framing is what I would defend. Non-interactive by default, machine-readable errors, a discovery command, and an explicit decision about which operations an agent may complete alone. If MCP does collapse into HTTP, all four of those still stand.
The takeaway#
The specific protocol is not the interesting question, and I would not bet on today’s answer to it. What I would bet on is that the ratio of machine callers to human clickers on internal platforms only moves one direction, and platform teams are still writing roadmaps as though the browser is where the work happens.
The cheapest way to find out where you actually stand is to spend an afternoon trying to drive your own platform without a browser. Every place you reach for the admin panel because the API cannot do it, every prompt that hangs, every error you have to read rather than parse: that list is your backlog, and it was written by a user class you have not been counting.
I build and run these systems rather than commentate on them, and if this is the kind of platform work your team is hiring for, here is what I do.