The Agent Web Is Being Built Right Now: WebMCP, Markdown Accept Headers, and the Protocol Layer

The highest-engagement AI agent story on Hacker News in the last 30 days was not a model release. It was a proposal about HTTP headers.

“Serve Markdown to AI Agents with Accept Headers” landed at 176 points and 108 comments. In the same week, WebMCP - a proposal for teaching websites to expose callable tools instead of pixels - drew 57 points and 59 comments, and AC2 Protocol pitched itself as the missing authorization layer for agent actions.

That cluster tells you where the conversation has moved. The model layer is settling. The interesting engineering is now in the protocol layer: how agents read the web, how sites expose capabilities to them, and how an agent proves what it is allowed to do.

Content negotiation, but for agents

The accept-header proposal is deliberately boring, which is why it got traction. Browsers already negotiate representation - they send Accept headers and servers respond with the best available format. The argument is that agents should be able to do the same, and that Markdown is the obvious thing to serve them.

The economics are hard to argue with. Extracting meaning from a rendered page costs tokens and loses structure. Serving Markdown directly removes a lossy, expensive parsing step from every single agent request.

The mechanism would look something like:

GET /docs/install/mac-mini/ HTTP/1.1
Host: openclawwiki.org
Accept: text/markdown, text/html;q=0.9

HTTP/1.1 200 OK
Content-Type: text/markdown
Vary: Accept

The Vary: Accept header is the part that matters operationally - without it, a shared cache may serve the Markdown version to a human visitor or vice versa.

The objection raised repeatedly in the thread: if you serve different content to agents than to humans, you have built a cloaking pipeline. Search engines have treated differential serving as a violation for two decades, for good reason - it is the standard mechanism for showing one thing to a crawler and another to a user.

The distinction is intent and verifiability. Serving the same content in a different representation is legitimate content negotiation. Serving different content is cloaking. That line is easy to state and genuinely hard to enforce, which is why the discussion did not resolve.

WebMCP: exposing tools instead of pixels

WebMCP approaches the same problem from the other direction. Rather than making pages easier to parse, it asks: why parse at all?

The idea is that a website declares a set of callable capabilities - search, filter, add to cart, book, query - with typed inputs and outputs, and an agent invokes those directly rather than driving a UI. It is the same argument that produced APIs, applied to agents.

This is where MCP (Model Context Protocol) enters. MCP has become the de facto way agents connect to tools and data sources, and WebMCP is essentially the question of whether the web should speak that language natively.

The appeal is real. An agent clicking through a paginated, JavaScript-rendered interface is slow, fragile, and expensive. An agent calling a declared search_products(query, filters) is none of those things.

The concerns are equally real:

• Who authorizes the action? A declared tool is an invitation to perform a side effect. Browsers solved some of this with CORS and same-origin policy; agents will need equivalents.
• What stops abuse? Any callable endpoint is a new surface for scraping, fraud, and denial of wallet.
• What about the long tail? Declaring tools is easy for a platform and unrealistic for the millions of sites that will never write a manifest. HTML parsing is not going away.

AC2: the authorization layer nobody has shipped

AC2 Protocol positions itself as the missing security layer for AI agents - the authorization and identity piece that the other two proposals assume but do not provide.

This is the correct gap to identify. Both Markdown serving and WebMCP answer “how does an agent read or call this?” Neither answers “should this agent be allowed to, and how does the site know who it is?”

The conversation on that thread was notably more skeptical than the other two, partly because agent identity is an unsolved problem. There is no widely deployed way for a site to distinguish a legitimate user’s assistant from an unauthorized scraper, and no standard for delegated authority that survives contact with the real web.

Which is worth saying plainly: the reading layer is converging, the action layer is contested, and the identity layer does not exist yet in any standardized form.

Evaluation is the other half of the story

While the protocol arguments played out, “Terminal-Bench-Science: Evaluating AI agents on scientific research workflows” pulled 117 points and 36 comments - the second-highest item in the window.

That pairing is not a coincidence. Every protocol proposal above is about giving agents better access. Better access without better evaluation just means faster failures at greater scale.

The evaluation gap is well documented at this point. tau-bench found frontier agents solved under 50% of retail tasks at pass^1 and under 25% at pass^8. Single-agent benchmarks do not predict multi-agent system behaviour at all. And the MAST taxonomy, built from 1,642 traces across seven frameworks, found that failures cluster into specification problems (41.77%), coordination failures (36.94%), and verification gaps (21.30%) - none of which are caught by per-agent unit tests.

Domain-specific benchmarks like Terminal-Bench-Science matter because generic agent benchmarks have become saturated and easy to overfit. Evaluating whether an agent can actually complete a real research workflow - literature search, data handling, analysis, reproducible output - is closer to what people deploy agents to do.

What this means if you run a website

Three concrete actions:

1. Make your content parseable without JavaScript. Regardless of which protocol wins, server-rendered HTML with semantic structure is the baseline every agent can read today.
2. Publish structured data. Schema.org markup, clean headings, and stable URLs do more for agent comprehension than any agent-specific format.
3. Consider content negotiation carefully. Serving Markdown alongside HTML is reasonable. Serving different content to agents is cloaking, and it is the kind of decision that is very expensive to reverse once a crawler has flagged you.

What this means if you build agents

1. Send honest identification. If you want sites to serve you well, identify yourself. The current default - pretending to be a browser - is why sites deploy increasingly aggressive blocking.
2. Prefer declared interfaces over scraping. When a tool or API exists, use it. Parsing is the fallback, not the strategy.
3. Budget for the failure modes. Every external tool call is a potential silent failure. Validate responses against schemas before they reach the model.
4. Log every call. If a site asks what your agent did, you should be able to answer from traces.

Why this cluster matters more than the next model release

Model capability is becoming a commodity. What differentiates agent systems now is the plumbing around them: what they can read, what they are allowed to do, how failures are caught, and whether any of it can be audited.

That is good news if you self-host. Protocol-layer decisions are architecture decisions you get to make yourself - which representation to request, which tools to expose, what policy sits between an agent’s intent and its action. You are not waiting on a vendor’s roadmap.

It is also a warning. The reading layer is being standardized by people who are still arguing about the cloaking question, the action layer has no agreed authorization model, and the identity layer is essentially unbuilt. Anything you deploy against these protocols today is deployed against a moving target.

Build accordingly: prefer reversible actions, keep policy in a layer you control, and assume the interfaces will change.

Related reading: Why AI Agents Fail in Production covers validating external tool responses, and OpenClaw 2.0 Release Analysis covers the permissions and tool-access changes in v2026.8.1.