Same site, two readers

What agent-ready actually means

A person and a stylized autonomous agent reviewing a technical website checklist with green checkmark dials.

TL;DR: Most websites are built for humans with browsers. But a growing share of nuri.com traffic is not human: search agents, shopping agents, payment agents and the models that answer questions with links and purchases. Those readers cannot execute a JavaScript maze, click a hamburger menu or read a screenshot. If a site only works for humans, it is invisible to the machines that increasingly decide what gets recommended and bought. This post documents the scores we hold nuri.com to, what each one actually verifies, and the CI gate that fails our pull requests when any of them regress.

Author Emin Mahrt

7 minute read

This post is also available in English , Deutsch and Español .

Agents are visitors too

When we say Nuri is built for people and their agents, that is not a slogan about the future. It is a statement about traffic that already arrives: agents that fetch our pages to answer questions, agents that compare products, agents that check whether a service is payable before they recommend it.

These readers share one property: they do not click. They follow links, read what is actually in the response, and move on. A price hidden behind a click-through, a page that only renders after JavaScript, a fact that exists only inside an image — to a machine reader, those facts do not exist.

That reframes the problem. Agent-readiness is not SEO garnish on top of a human site. It is a second, parallel interface to the same product: one that serves HTML and beautiful design to humans, and machine-readable truth about the same product to everything else.

The uncomfortable part is that the machine audience keeps score. Public scanners now grade how well a site serves agents, other agents read those grades, and the grades are already part of how recommendations get made. So we treat the scores the way we treat Lighthouse: as a contract we either keep or lose in public.

isitagentready.com: Level 5, Agent-Native

isitagentready.com is a public scanner that grades a URL across five levels. nuri.com holds Level 5, "Agent-Native", with zero failed checks. The interesting part is what the checks actually verify, because they form a coherent picture of what a machine needs.

Discovery: robots.txt with explicit rules for AI bots (GPTBot, ClaudeBot, PerplexityBot and friends) plus Content Signals, a valid sitemap, agent-useful Link headers, and a DNS for AI Discovery record at _index._agents.nuri.com, validated with DNSSEC.

Content: markdown negotiation. Send Accept: text/markdown and nuri.com answers in markdown, page for page, including this blog. A machine does not have to parse our HTML to know what we said.

Identity and protocols: a Web Bot Auth directory with a valid JWKS so verified bots can prove who they are, an API catalog, OAuth and OpenID Connect discovery, an auth.md file describing how to authenticate, an MCP server card, an A2A agent card, an agent-skills index, WebMCP tools and an ARD capability manifest.

Commerce: x402, MPP, UCP, ACP and AP2 discovery. An agent can find out not just what Nuri is, but how to pay for things on it — before spending a cent.

One gotcha we learned the hard way: the scan is honest about where it runs. Branch previews on pages.dev fail the DNS-AID check because DNSSEC lives on nuri.com itself. That is correct behavior, not a bug. Only production scores a clean Level 5, so that is the only number we report.

agents.circle.com: 100 out of 100

Circle for Agents scores a domain on three dimensions: discovery, payment readiness, and how consumable the API is for an agent that has never seen it before.

Discovery (30/30): the OpenAPI 3.1 document at /openapi.json resolves, validates, and every operation declares a request schema with described fields. An agent can find out what exists without a human writing prose for it.

Payment (40/40): every paid operation carries x-payment-info with a price and currency, a declared protocol, and — the part we like most — a runtime-verified live 402. That last check is not paperwork: Circle actually makes an unpaid call and requires a valid Payment Required response. A spec that promises payment is worth little; a server that answers 402 with payment rails is worth something.

Agent consumability (30/30): concise x-guidance in plain language, a contact email, docs URLs, and multi-chain support so an agent funded on one network can still pay. Our x402 and MPP postcard services price in USDC and run across three networks.

The badge that falls out of this is "multiChain" and trust tier "strong". We do not chase badges. But when a payment company verifies that a real agent can discover and pay our API end to end, that is evidence we take seriously.

PageSpeed: four hundreds

The fourth score is the oldest one: Lighthouse. nuri.com holds 100/100/100/100 — performance, accessibility, best practices and SEO — on mobile and desktop. You can run the live check yourself at pagespeed.web.dev.

Speed is part of agent-readiness, not a separate hobby. Agents operate with timeouts and token budgets. A page that ships megabytes of JavaScript before it says anything is expensive for a human and often unreadable for a machine. Fast, static-first, semantic HTML serves both audiences with the same markup.

Our release gate treats this as a hard threshold: npm run verify:pagespeed with a minimum score of 100. Not 98 with an explanation — 100. Lab measurements can wobble a point under host load, and the answer to that is measuring again, not weakening the threshold.

The design constraint that makes it achievable is also what makes the site agent-friendly: server-rendered content first, progressive enhancement second, no client-side rendering gate in front of the facts.

The gate that keeps it green

Scores decay. Not because anyone breaks them on purpose, but because the web around them changes: scanners add checks, DNS records expire, protocols evolve, a refactor quietly drops a header. A grade checked once is a photograph; we needed a video.

So the repository now has an agent-ready gate. On every push to master, every pull request, every six hours, and on demand, a GitHub Actions workflow runs the isitagentready scan (must stay Level 5 with zero failed checks), the Circle score (must stay 100/100), and a smoke set: robots.txt, llms.txt, sitemap.xml, openapi.json and the agent card must all answer 200.

If anything regresses, the workflow opens a GitHub issue labeled agent-ready and regression, linking the exact failed run and check. A regression cannot hide; it files itself.

The scheduled runs matter more than they look. External dependencies change without our code changing — a scanner adds a check, a DNS record lapses, a protocol gets stricter. The gate catches the world moving, not just our own mistakes.

What we can and cannot promise

Standards evolve. Today Level 5 means twenty-odd checks across discovery, content, identity and commerce; tomorrow it may mean more. We cannot promise that no definition of agent-ready will ever change.

What we can promise is the process. The scores are not a one-time badge collected on launch day and quoted forever. They are checked continuously, automatically, against production, and a regression files itself as an issue within hours.

There is also a deeper reason we do this. Our product thesis is that agents will move real money. An agent choosing where a payment lands is a reader with consequences. The same honesty we owe human users — clear pricing, working endpoints, no dark patterns — has to be legible to machines, or agents will simply route around us.

Agent-readiness, in the end, is the same discipline as everything else we build: not a claim, but a check that keeps running.

Humans get a fast, honest site. Agents get a machine-readable one. Same money, same truth, two doors.

Emin Mahrt · Founder, Nuri