Headless MCP vs. Agents: Ben Hylak's "Double Standard" Product Philosophy

Product people want others' products headless for Agent use but insist their own keep a UI, reflecting the tug-of-war between standardization and experience in the AI application layer.
Starting from a tweet by Ben Hylak, the article dissects a sharp contradiction in the AI application layer: people want every product they use to become a headless MCP feeding capabilities to an Agent, yet firmly believe their own product must keep a polished UI. The author notes this "double standard" reveals the divide between tool-type and experience-type products — the former's core value can be abstracted into APIs, making the UI a redundant middleman, while the latter's UI is itself the value proposition and moat. The resistance to going headless lies not at the protocol layer but at the business layer: pipes carry no brand premium, and when an Agent errs there's no UI as a fallback. The article draws three lessons: adopting MCP doesn't mean removing the UI; users' love for the UI is conditional; and the Agent ecosystem is more likely a layered structure of a general-purpose Agent orchestrating and vertical products providing capabilities.

After Simon Willison's blog quoted a rant from Ben Hylak on Twitter, it sparked a fair amount of discussion. On the surface, the passage reads like product-manager self-deprecation, but in reality it hits on a rather sharp contradiction in today's AI application layer: we expect the products others provide to become headless MCPs, yet we firmly believe our own products must retain a polished UI.
Behind the "Double Standard": The Battle Between Standardized Entry Points and Experience Moats
Hylak's original words were:
every product i use should just be a headless mcp, that feeds into an agent, where i never have to think about anything underneath.
except for our product, of course.
in our product, customers love the ui and love us very much.
Translated: every product I use should just be a headless MCP that feeds its capabilities into an Agent, so I never have to care about what's happening underneath — except, of course, our own product. In our product, users love our UI and love us very much; we're special in this regard.
This kind of "double standard" is not uncommon in tech circles — you could even call it a product person's instinctive reaction. But placed in the context of the rapid evolution of MCP (Model Context Protocol) and the Agent ecosystem, it reveals a reality at two levels:
- For tool-type products, going headless and protocol-driven really is the trend. When a product's core value can be abstracted into a set of APIs or MCP tools and handed to an Agent to orchestrate, the UI becomes a redundant middleman.
- For experience-type products, the UI itself is the value proposition. Users may choose you precisely because of the sense of certainty and delight that the interaction brings, not because there's a replaceable capability interface underneath.
What's candid about Hylak is that he doesn't pretend to stand on moral high ground; he directly acknowledges the rationality of this asymmetry — we demand others go headless because we only want to consume their capabilities; we insist on having a head ourselves because we want users to consume our experience.
MCP (Model Context Protocol) is a protocol proposed and open-sourced by Anthropic at the end of 2024, aiming to unify how large language models connect to external tools and data sources. Before MCP, every AI application that wanted to integrate external capabilities often had to write separate adapter code for each tool; MCP abstracts these interfaces into three standardized primitives — "tools," "resources," and "prompts" — so a model can discover and invoke them simply by following the protocol description. The term "headless MCP" refers to a product fully exposing its capabilities as MCP tools, no longer relying on a graphical interface as the entry point, so users (or Agents) consume capabilities directly through the protocol. The key point of this concept is that MCP decouples "product" from "interface," allowing capabilities to be orchestrated by any Agent and turning the product from a destination that users visit directly into callable infrastructure.
The Ideal and Reality of Headless MCP
The ideal state Hylak describes is: all products become headless MCPs, uniformly fed into a single Agent, and users no longer need to open a dozen apps or remember a dozen sets of interaction logic. Technically, this vision is not far off — the MCP protocol lets models call external tools in a standardized way, while the Agent handles planning and execution.
But the real resistance is often not at the protocol layer but at the business layer.
On one hand, going headless means the product shifts from a "destination" to a "pipe." Pipes carry no brand premium; users don't remember pipes, nor do they develop loyalty to them. No product company of any scale is likely to voluntarily downgrade itself into a tool call for someone else's Agent.
On the other hand, Agent reliability still depends on context quality. A headless MCP provides a capability interface, but what users really care about is whether a task gets done correctly. When the Agent makes a mistake, there's no UI to fall back on, and the user's frustration lands directly on the party providing the MCP. This is also why many teams, while opening up MCP interfaces, still keep a full interaction UI as a safety net.
Agent here refers to an AI system capable of autonomous planning, tool invocation, and multi-step task execution. Unlike single-turn Q&A, an Agent decomposes goals, selects tools, observes results, and iterates — and MCP is precisely its standard interface for acquiring external capabilities. Agent reliability depends heavily on context quality: it needs an accurate task description, a list of available tools, and correct return of each step's execution result. When an Agent errs in a UI-less pipeline, users often can't see the intermediate process and have trouble locating the problem, so frustration gets attributed directly to the MCP party providing the capability. This is exactly why many teams keep a full interface while opening up MCP — the interface is not only a vehicle for experience but also a place for error fallback and trust building.
Three Takeaways for AI Product Design
The fact that Simon Willison included this tweet in his blog itself shows it's worth treating as a sample viewpoint. From it we can distill several judgments of practical reference value for building AI products:
First, adopting MCP does not equal removing the UI. Opening an MCP interface and keeping a UI are not contradictory. The former expands the possibility of the product being called by Agents, while the latter holds the front line of direct user experience. Setting the two in opposition is a mistaken either-or reading.
Second, users' "love" for the UI is conditional. Hylak says users love their UI, but that rests on the UI genuinely providing value that an Agent cannot replace. If the UI is merely packaging for capabilities, then users switching to an Agent is only a matter of time. Product teams need to ask themselves honestly: if you remove the UI, what do users lose?
Third, the endgame of the Agent ecosystem may not be "one Agent to rule them all." More likely is a layered structure: a general-purpose Agent handles orchestration, while vertical products provide capabilities in the form of MCP, while retaining their own interaction entry points in key scenarios. Hylak's "double standard" is less a contradiction than an intuitive description of this layered structure.
Conclusion
Hylak's passage spread because it voices, in an almost joking way, what many people genuinely think. At a time when AI is reshaping software interaction, every product team plays two roles at once: on one hand hoping others' products become parts of one's own Agent, and on the other hoping one's own product becomes an interface users can't live without. This tension won't disappear; it is itself part of product competition.
What's truly worth pondering is not whether this "double standard" is hypocritical, but rather: as headless MCP becomes increasingly widespread, on what grounds will your product still make users willing to use it "headfully"?
Related articles

T3 Code: The Open-Source AI Coding Assistant's Comeback Story
T3 Code is an open-source AI coding assistant that unifies subscriptions like Codex and Claude, with powerful remote control and parallel task management.

Never Elected, Yet Ruled New York for 30 Years: The Ultimate Case Study in the Mechanics of Power
Robert Caro's biographies reveal how unelected Robert Moses ruled New York for 30 years through legal drafting and public authorities, and how Lyndon Johnson built leverage as a "powerless" Senate Majority Leader. Unpacking the underlying logic of accumulating and sustaining power.

The CPython 3.10 Recursion Trap and Synthetic Recovery in TokenGuard, an LLM Circuit Breaker
TokenGuard's author recounts a recursion crash caused by OrderedDict.pop in CPython 3.10 and introduces v0.3.0's Loop Nudge synthetic recovery, inline DLP scanning, and other new LLM agent circuit-breaker capabilities.