Agent Readiness Score vs. Journey Success: Why Passing Standards Does Not Prove the Job Gets Done

Google's agent-ready web tooling describes a new agentic-browsing category in Lighthouse and a deterministic testing framework for properties that help agents use websites. That is an important step because it gives developers repeatable checks inside familiar browser tooling. Deterministic checks are especially useful for regression gates: the same build can be inspected for the same markup, accessibility, runtime, and browser-facing conditions. They do not, by themselves, show that an autonomous product agent interpreted a user's request correctly, chose the intended product, handled authentication, respected an approval boundary, or returned the right receipt. A category score is therefore evidence about tested conditions, not a universal completion probability.^{1, 2}

Cloudflare's Agent Readiness surface likewise evaluates a particular set of web signals, including robots configuration, agent-oriented Markdown delivery, and content signals. It is useful evidence from the delivery edge, but its denominator is not identical to Lighthouse's denominator or AgentReady's denominator. A score of 80 from one system cannot be subtracted from a score of 90 from another as though both measured the same population. Before comparing any scores, record the tool version, checks included, conditions excluded, observation time, and treatment of missing evidence. Otherwise a neat number hides a category error.³

As reviewed on August 30, 2026, AgentReady's current public scan evaluates a public URL through stable checks covering discovery files, semantic HTML, accessible controls, content structure, browser behavior, safety signals, legal and trust surfaces, and conditional API, MCP, repository, and commerce evidence. It reports a score and a separate coverage value so an unobservable condition is not silently treated as a pass or an ordinary failure. The enhanced browser pass can try bounded navigation, fill a safe form without submitting it, find public contact or documentation information, and inspect a declared sandbox. Those observations are useful for triage and for generating a Fix Pack, but they are not a completed customer journey.⁴

The current enhanced runner is designed to avoid consequential mutations: it uses a fresh anonymous browser context, does not receive target-site credentials, fills selected public forms without submitting them, limits checkout or cart navigation to declared or suspected sandboxes, and aborts observed non-GET and non-HEAD requests. That network-method guard cannot guarantee safety on a misimplemented server that changes state on GET. The runner does not currently create accounts, sign in to customer systems, submit leads, or make payments. Its three derived journey summaries group public checks into discovery, understanding and navigation, and safe action; they are not user-authored goal contracts. The public score can identify conditions that commonly affect those outcomes, but it cannot prove that a selected agent completed them.⁴

The readiness ledger should contain deterministic or tightly bounded observations. Each row needs a stable check identifier, surface, status, evidence, applicability reason, observation method, and scanner version. Its numerator is earned credit across observed applicable checks; its denominator is the weighted set of applicable checks that the scanner could evaluate. Coverage should remain separate because low coverage weakens the strength of any headline. This ledger answers: what conditions did the site expose, and which concrete defects should an implementation team inspect? It supports regression tests and prioritized fixes without pretending to model every agent.^{5, 6, 1}

The journey ledger begins with a task contract, not a score. It names the user goal, agent product and version, account tier, browser surface, starting URL, fixture data, authentication state, allowed actions, prohibited actions, safe stopping point, success assertions, retry policy, region, and observation time. Its primary result is completed, partial, blocked, refused, unsafe, or unobservable. Supporting measures can include intervention count, retries, elapsed steps, first blocking state, assertion coverage, and whether the agent requested approval at the right moment. This ledger answers: what happened when this particular system attempted this particular job under these particular constraints?

Imagine a booking site with excellent server-rendered content, semantic headings, labeled controls, current policies, a valid sitemap, and stable browser runtime. Those properties can legitimately produce strong readiness evidence. The selected agent may still fail because the desired appointment requires a location choice hidden behind session state, the calendar announces availability visually but not programmatically, or the final confirmation returns no durable booking identifier. The readiness score did not lie; it described the checks in its contract. The journey failed at a state the public diagnostic did not execute. The correct response is to add a journey assertion and, when generalizable, propose a new deterministic check rather than retroactively redefining the original score.^{5, 6}

The opposite case is equally instructive. An agent might successfully navigate one familiar checkout because its model recognizes the visual pattern, while the site remains inaccessible to other agents, fragile under a minor redesign, blocked for crawlers, or unsafe around destructive controls. One success is evidence for that run, not proof of broad compatibility. This is why the cross-harness website test blueprint should report each harness separately, and why the Lighthouse agentic browsing audit guide should be treated as a deterministic baseline rather than a replacement for task evidence.^{1, 2}

A credible benchmark should publish its task contracts before publishing any ranking. Start with narrow, repeatable journeys such as find an eligible plan and cite its constraints, prepare a signup until the consent boundary, locate an appointment and stop before confirmation, or assemble a cart and stop before payment. For authenticated work, use the controls in how to test AI agents after login safely. Each contract should define what counts as success and which conditions force a refusal or human handoff. Changing the prompt, account state, or safe stopping point after seeing results invalidates comparison unless the new version is reported separately.

Sampling also needs discipline. A leaderboard cohort should share a category, observation window, scanner version, journey type, and minimum sample size. Missing browser access must lower evidence coverage rather than becoming a zero. Company-specific publication should preserve correction and removal routes and avoid implying endorsement. AgentReady's proposed opt-in leaderboards already describe the consent and methodology boundary, while the Agentic Customer Journey Index demonstrates how to publish exact tasks, safe stops, dates, coverage, strengths, and gaps without claiming an unconsented numeric ranking. This article proposes how to extend that pattern; it does not claim those cross-agent runs have been completed.

The available AgentReady public scanner can serve as the readiness ledger today: run the URL, inspect coverage, open the evidence, and export the Fix Pack. The available Journey Contract Builder turns a business goal into a versioned JSON contract with authorization scope, allowed and prohibited actions, a safe stop, assertions, and an authoritative readback requirement. It exports a planned TestRun and an explicit not-run receipt; it does not execute the journey. A separate Evidence Diff remains proposed. That comparison should align a before-and-after readiness scan with two executed journey receipts while refusing to call a score increase a successful outcome unless the journey assertions also pass.

Structured site tools may eventually reduce some browser ambiguity. The WebMCP implementation guide explains how proposed browser-facing tools can expose named operations, while the authenticated-testing guide covers the security boundary when those tools operate inside a user session. Even then, a tool's existence is a readiness condition; successful selection, authorization, execution, and receipt validation belong in the journey ledger. Measurement stays useful only when the layers remain separate.²