Agents are a new class of user, and there is still no shared definition of what it takes to be ready for them. Today we are launching AgentReady.org, an open standard for what a product should implement so agents can use it, together with four companies that build the surfaces agents touch every day: Vercel, Mintlify, Auth0, and Stripe.
MCP, WebMCP, A2A, x402, llms.txt, Web Bot Auth. The agentic web has more protocols every quarter, and most readiness checklists simply list them. A list says what exists. It cannot say what matters, because nobody measured it. So our research lab ran agents on real tasks more than 250,000 times, and ran a controlled experiment that changed one thing at a time. AgentReady is built from that evidence. Here is what it showed.
finding 01
Two changes broke an agent
To separate what helps from what decides, we served one docs site under 19 configurations and asked two clients to pull a planted answer from it: a plain fetch, like most agent tools, and a client that runs JavaScript. Almost nothing changed the outcome. Hiding the answer behind JavaScript did, and so did blocking agents.
| Site configuration | Plain fetch | Runs JS |
|---|---|---|
Answer only in JavaScript 1 configuration | 0/5failed | 5/5retrieved |
403 to agent user agents 2 configurations | 0/5failed | 0/5failed |
Every other configuration 16 configurations, including llms.txt, JSON-LD, sitemaps, and markdown mirrors | 5/5retrieved | 5/5retrieved |
finding 02
Agents read the same pages people do
Agents went where human visitors go: the homepage first, then the docs. Files built only for machines were reached far less often. Agents asked for markdown on about 65% of fetches, but markdown mirrors and content negotiation never changed whether they succeeded.
docs pages
83%homepage
69%then a cliff.well-known/*
23%openapi.json
on sites that ship one
21%sitemap.xml
4%
finding 03
Links beat guessed paths
When agents did open a file like llms.txt, they almost always got there by following a link from a page they had already read, not by guessing the path.
openapi.json
97%.well-known/*
93%llms.txt
86%
finding 04
When agents cannot read you, they answer without you
An agent that cannot read a site still answers, from search results and other people’s pages. Across 1,056 business sites, those answers were 3.7× as likely to miss every fact the user asked for, and agents clearly recommended agent-ready businesses almost twice as often.
Clearly recommends the business
- agent-ready20%
- not agent-ready11%
Contains none of the facts asked for
- read from the site7%
- from the web25%
From findings to essentials
Each finding sets a strength. MUST marks what an agent fails without: the two changes that broke an agent in our experiment, and, when agents should finish a task, an MCP server or a CLI to act through. SHOULD covers practices that changed where agents went, and the surfaces that make acting reliable, like a public API and WebMCP on the pages agents act through. MAY covers conventions that are emerging but not yet proven, like agent payments, where early numbers are strong: agents paying through Link got 92.3% of test checkouts right. The spec lists them in the order agents meet a site: find, read, act.
find
every site
- MUSTAllow agents in robots.txt and bot protection
- SHOULDPublish the answer as first-party docs
- SHOULDList pages in a sitemap.xml
- MAYPublish an AI Catalog
read
every site
- MUSTPut the answer in the initial HTML
- MUSTReturn real HTTP status codes
- SHOULDLink llms.txt, JSON-LD, and OpenAPI
- SHOULDFence and language-tag code
act
when agents should finish a task
- MUSTAn MCP server or a CLI, at least one
- SHOULDAuth an agent can finish
- SHOULDA public API with OpenAPI
- SHOULDWebMCP on pages agents act through
- MAYAgent payments and NLWeb
What it is not
AgentReady names what to implement. It does not score anyone. There are no weights, thresholds, or badges in the spec, and that is why companies that compete elsewhere can maintain it together. It is vendor neutral, MIT licensed, and developed in the open.
Scoring is left to implementations, and three public rankers already read the same spec for different jobs. is-agentic.com (which we built with Vercel) scores the essentials for sites whose job is content. Our own ranker, ora.ai, covers products agents transact with, across APIs, MCP, auth, and payments. mintlify.com/score grades documentation. Their checks and weights can change without changing the spec.
How the standard evolves
The agentic web changes every month, so the spec has to change with it. New conventions usually enter as MAY. They move to SHOULD or MUST only when our studies show they change what agents do, and they move back down when they stop mattering. Every requirement has a stable identifier, such as AR-FIND-01, every number in the spec names its source, and every change is recorded in a public changelog.
Each committee member reviews the part of the agent journey they know best:
- Ora (us), research. We run the studies behind every requirement and keep the data public.
- Vercel, infrastructure and web essentials. Whether agents can reach a page and read the answer in it.
- Mintlify, docs. How to build docs that agents read and cite.
- Auth0, auth. How agents sign in and act on a user’s behalf.
- Stripe, payments. What to build so agents can pay you.
Get involved
Read the spec at agentready.org, or give it to your agent through agentready.org/llms.txt. For a hands-on version, Vercel’s guide Make your site readable by AI agents walks through each essential with code. The source and the discussion live on GitHub. If you maintain a protocol, run agent infrastructure, or have agent runs that contradict a requirement, open an issue. The spec changes when the evidence does.