AgentReady // The open standard for agent readiness

Open the original

Short summary

AgentReady is an open specification laying out what a website should do so AI agents can find, read, and act on it. The research behind it, drawn from over 250,000 agent runs, suggests that sites agents can't read get answered from other people's pages instead.

  • Sites agents couldn't read were 3.7 times as likely to produce answers missing the facts the user asked for, and agent-ready businesses were clearly recommended about 1.9 times as often.
  • In the traced runs, 82% of final answers traced back to a page the agent fetched, and docs pages were the most common source at 47%.
  • Blocking is the big failure: not-agent-ready sites blocked agents 2.1 times as often, and a WAF returning a 403 or challenge page stops agents regardless of robots.txt.

Full summary

AgentReady is an open spec describing what a website needs so AI agents can use it, covering three steps: find, read, and act. The authors say two changes broke agents in their studies: putting the answer behind JavaScript, and blocking access outright. Find and read are essentials for any site; act only matters if the product should complete tasks, which requires an MCP server or CLI. Each practice carries an identifier like AR-FIND-01 and a strength rating (MUST, SHOULD, or MAY), and the guidance is revised as agent behavior changes. The strongest evidence comes from ora.ai research covering 37,927 agent journeys across 1,056 business sites. When an agent could not read a business's site, it answered from web search and other people's pages instead, and those answers were 3.7 times as likely to miss every fact the user asked for (25% of answers versus 7% for sites that were readable). Agent-ready businesses were clearly recommended 1.9 times as often. In traces where the agent hit a dead end on the site, it answered anyway about 99% of the time. Among the traced answers that did come from a page the agent fetched, docs pages were the most common source at 47%. The practical advice follows: publish the answer on a single canonical, current docs page, and write one crawl rule for all agents rather than an allowlist of named bots. Robots.txt is only half the gate, since a WAF or bot manager returning 403s or challenge pages blocks agents regardless of the file. The authors also suggest separating crawler jobs (training, search indexing, user fetches), since each obeys its own robots.txt rule, so you can opt out of training without vanishing from agent answers, though a specific group like User-agent: GPTBot overrides a wildcard and existing rules need auditing. The rest is more tentative. An optional AI Catalog at /.well-known/ai-catalog.json would list your agent-facing resources, but the study didn't measure its effect, so treat it as a MAY-level experiment. The sitemap, while standard for search engines, was fetched directly in only 4% of runs. The article's own scanner found that in a roughly 50,000-site scan, 88% had a robots.txt and 80% stayed reachable to major AI crawlers, while about one in ten blocked them outright. The piece ends with a short test: fetch your page with an agent user-agent string and confirm a 200 response (redirects are fine) containing the actual answer text, not an empty app shell.

Ask about this article