THE AGENTIC WEB IS SPLITTING INTO TWO BETS: IDENTITY AND CAPABILITY

The protocol layer of the agentic web is splitting into two bets, and most websites have already placed one of them without knowing it. The first bet is about identity: a file called llms.txt that tells AI models who you are and what your content covers. The second is about capability: a browser standard called WebMCP that tells an agent what it can actually do on your website once it arrives. They sound like the same idea. They answer opposite questions. And the difference decides where your effort should go over the next year, because one of these bets is being switched on for you by default while the other, the one that actually lets an agent finish a task, takes deliberate work.

Contents

• Two files, two questions
• The identity bet: llms.txt
• The capability bet: WebMCP
• Why the two bets are not interchangeable
• I placed both bets on my own website, deliberately
• What this means for your website
• What is still unsettled

Two files, two questions

An agent that lands on your website has two things it might want to know. The first is what this place is and what it covers. The second is, now that it is here, how it completes the task its user sent it to do. Identity, then capability. The agentic web is building a separate answer for each, and the two answers come from two different files backed by two different camps.

The identity answer is llms.txt, a plain-text file you publish at the root of your domain. It is a curated map: here is who I am, here are my most important pages, here is what each one is about. The capability answer is WebMCP, a browser standard that lets your website expose callable tools to an agent, so the agent can search, filter, price, or book by invoking a function instead of guessing at your interface.

llms.txt and WebMCP get lumped together as two flavors of the same thing, agent-readiness. They answer two different questions. Identity is a brochure. Capability is the cash register. And right now the industry is pushing every website toward the brochure, the bet with the weaker evidence behind it, while the cash register, the bet that actually moves a transaction forward, is left to the few teams willing to build it.

The identity bet: llms.txt

llms.txt is a markdown file that lives at yourdomain.com/llms.txt. It was proposed by Jeremy Howard, co-founder of Answer.AI, on September 3, 2024, as a way to hand language models a clean, human-curated index of your content instead of making them crawl and reconstruct it from HTML cluttered with navigation, ads, and scripts. The pitch is reasonable on its face. Models work better with structure, so give them structure.

The problem is that the evidence it does anything is thin. Answering people on Reddit in June 2026, Google's John Mueller called llms.txt "purely speculative for now (the file has existed for years, yet none of the AI systems use it)" (reported by Search Engine Journal). That is a Google Search advocate saying the quiet part out loud. A file that has been around for over a year. A file no major AI system has confirmed it reads. A file that asks you to keep a second copy of your own content in sync.

Even with evidence this thin, llms.txt is being switched on for websites by default. AIOSEO, a plugin used on more than three million WordPress websites, generates an llms.txt by default. A very large number of website owners are now publishing an llms.txt they never decided to publish, describing their website in a file they have never read.

To be clear, I am not against the file. A well-maintained llms.txt is a fine content index. The problem is the default. The identity bet is winning on adoption not because it works, but because a plugin checkbox shipped set to on. A file you did not write, that no AI system is confirmed to read, that drifts out of sync with the website it claims to describe the moment you forget it exists, is a strange thing to have at the center of an agent strategy. But that is where a lot of websites now sit, by default rather than by choice.

The capability bet: WebMCP

WebMCP, short for Web Model Context Protocol, is a browser standard that lets your website register callable tools an agent can invoke through a navigator.modelContext API. It starts from a different question than the identity file: not who you are, but, given that an agent is already on your website, how it properly completes the task it came to do. That is close to how Mueller framed his own preference in the same conversation. He said he likes the WebMCP approach and the commerce integrations because "they have clear goals & processes."

Instead of an agent screenshotting your page and guessing where to click, your website tells it directly: here are the actions I support, here are the inputs each one needs, here is what you get back. The control inverts. The website declares its capabilities rather than forcing the agent to reverse-engineer them.

The standard is being written through the W3C Web Machine Learning Community Group by engineers from Google and Microsoft, and it was published as a draft on February 10, 2026. It is now in a public origin trial that runs from Chrome 149 through Chrome 156. An origin trial is how Chrome lets a website turn on an experimental feature for its real visitors for a limited window, by registering for a token, instead of hiding it behind a developer-only flag. So you can run WebMCP tools on live traffic now, not just on your own machine. The agent consuming those tools in Chrome today is Gemini.

WebMCP is the stronger bet because it has a clear job. An identity file describes you and hopes someone reads it. A capability tool gets invoked, returns structured data, and moves a task one step closer to done. The brochure waits to be read. The cash register rings.

Why the two bets are not interchangeable

The cleanest way to hold the difference is through the two design constraints I keep coming back to in Machine-First Architecture: identity and interaction. Identity is making your brand and your content unambiguously machine-readable. Interaction is letting an agent complete an action with a predictable result. llms.txt is a play at the identity layer. WebMCP is a play at the interaction layer. They are tools for two different jobs, and a website can need both, one, or neither depending on what it wants agents to do.

This matters more now that agents are not a rounding error in your traffic. Cloudflare's chief executive Matthew Prince said in June 2026 that automated traffic had passed human traffic for the first time, at 57.3% of requests to web pages against 42.7% from people, a crossover he had projected at SXSW would not arrive until 2027. When most of the requests hitting your website are machines acting for people, whether the agent knew who you are stops being the interesting question. Whether the agent could actually do what your customer asked becomes the whole game. Identity without capability is a machine reading your sign and then standing at a door it cannot open.

That is the inversion the default-on adoption gets backwards. The file being switched on for everyone answers the question that matters least once the agent has arrived. The standard that answers the question that matters most is the one almost nobody has turned on.

I placed both bets on my own website, deliberately

I run both on No Hacks, and the contrast between how much each one cost to place is the whole argument in miniature.

For identity, I keep an llms.txt, and I generate it from the website's own content each time I update the site rather than leaving a plugin to write one I never read. That is the deliberate part. Because I rebuild it whenever the site changes, it stays in step with what is actually here, and if an AI system ever does start reading llms.txt, mine will be ready when that day comes. I am not betting on it. I am keeping it current and cheap and not mistaking it for a strategy.

For capability, I implemented WebMCP. When a WebMCP-capable browser loads the website, it registers four callable tools through navigator.modelContext. Two cover the glossary: one lists every term so an agent can discover what is defined, and one returns the canonical definition of a term with its source link. Two cover my running landscape of agentic browsers and agent products: one enumerates every tracked product by category, and one returns the full detail on a single product by name. An agent does not have to scrape my pages to answer what I mean by the capability bet or which agentic browsers I track. It calls a tool and gets a clean, structured answer.

The detail that matters most is where the tools read from. Each one pulls from the same data that powers the human-facing page. The glossary tools read the glossary. The product tools read the product list. So the agent answer and the human answer can never disagree, because one source feeds both. That is the difference between exposing a capability and maintaining a separate description of yourself, and it is why the capability bet, built this way, has no separate copy to keep in sync.

So I hold both files. One took an afternoon and does real work. The other I regenerate from my own content and treat as a hedge, not a plan.

What this means for your website

First, find out what you already published. Open yourdomain.com/llms.txt in a browser. If something loads, your stack put it there, possibly a plugin default you never set. Read it. Ask whether it actually describes your website, because if an AI system ever does start reading llms.txt, an inaccurate one is worse than none at all. This costs five minutes and most website owners have never done it. If you want to keep one, generate it from your own content so it cannot drift.

Second, decide whether the capability layer is worth placing for you. If agents have any reason to complete a task on your website, search inventory, check a price, start a booking, begin a return, then WebMCP is the bet that pays, and the origin trial means you can run it on real visitors now rather than waiting for it to ship. If your website is purely something agents read rather than act on, the capability layer can wait, and your effort belongs in clean, server-rendered content that any agent can extract.

What you should not do is assume the file your plugin switched on is your agent strategy. It is an identity claim no AI system is confirmed to read, and it says nothing about what an agent can do once it arrives.

What is still unsettled

The honest uncertainty: the identity bet is not dead, it is unproven. If a major AI system announces tomorrow that it reads llms.txt and weights it, the calculus shifts and the file everyone defaulted into suddenly earns its place. I am watching for exactly that signal and have not seen it yet.

WebMCP has its own open questions. It is a Community Group draft, not a ratified standard. Gemini in Chrome is the main agent consuming it so far. And cross-browser support is thinner than the secondary coverage suggests. Microsoft co-authored the standard, but I could not find WebMCP in Microsoft Edge's official release notes as of version 147, so I would treat any claim that Edge ships it natively as unconfirmed for now.

Until that signal arrives, my bet is clear: by the end of 2026, capability is the bet that matters and identity fades to a hedge. The file that hopes to be read loses to the tool that gets invoked, because agents are measured on whether they finished the task, not on whether they read your sign first. Place the capability bet deliberately. Generate the identity file from your own content, if you keep it at all. And read the one your plugin already wrote before it speaks for you.