Agent readiness is not a vibe
Deepanshu PalA store does not feel agent-ready. It scores agent-ready. How a scorecard turns agent readiness into checks that can be repeated and evidence that can be inspected.
A feeling is not a measurement
Ask a store whether it is ready for AI shopping agents and the answer is usually a feeling. The site looks clean. The checkout seems simple. Nothing has complained. None of that tells you whether a machine customer can finish a purchase.
What a scorecard contains
A store does not feel agent-ready. It scores agent-ready. A scorecard has three parts: a score out of 100, a letter grade, and a list of checks that shows what passed, what failed and why.
Each check is a task a machine customer must be able to complete, from reading a price to finishing a checkout.
- Read a pricePassedTrace of the read
- Choose a variantFailedStep and page state where it stopped
- Keep a cartPassedTrace of the cart
- Finish checkoutFailedStep and page state where it stopped
Two rules that keep it honest
First, every check is reproducible. Another run, on the same store under the same conditions, gives the same result within tolerance. A check that cannot be repeated is not a measurement.
Second, every failure comes with evidence: the trace, the step, and the state the agent could not get past. A store owner should never have to take anyone's word for it.
Why scores need checks underneath
A single number is easy to read and easy to misuse. A score of 72 tells a store owner nothing about what to do next. The checks under the score do. Each check names a task, says whether the agent finished it, and shows where it stopped if it did not.
That is why a scorecard here is a list first and a number second. The number is a summary for a quick read. The list is what a team works from.
Reading a failed check
Take the sample layout above. The check "Choose a variant" is marked failed, with the step and page state where the run stopped. A failed check like that is a to-do item with a location attached.
The owner can open the trace, see the page the agent was on, and see what it was trying to do. The fix might be a selector that exposes its state, or a size that is only shown on hover. The trace shows which.
This is also where a shared vocabulary helps. Each failed check can carry a code from the failure taxonomy, so that two teams reading the same trace agree on what went wrong.
What a score cannot tell you
A scorecard measures whether an agent could complete tasks on a store. It does not measure whether the product is good, whether the price is fair or whether a shopper would like the brand. It also covers only the tasks it checks, so a passing score means those tasks passed, not that every possible purchase will work.
We think that limit is a feature. A claim that stays inside what was tested is a claim a store owner can rely on.
What happens when a store changes
If a store fixes a failure, rerunning the same checks changes the score. If a rerun disagrees with the earlier result, find out why before trusting either one.
Questions to ask of any score
Can I rerun it myself?
A result you cannot reproduce is a claim, not a measurement. Ask for the checks, the conditions and the traces.
What did it test?
A score is about the tasks it covers. Ask which tasks, on which pages, and with what kind of agent.
Is the sample labeled?
A scorecard shown only to explain the layout should say it is a sample. If it does not, treat the numbers with care.
What is a sample
Any scorecard shown on this site that is not a real result is labeled as a sample. A sample shows the format, not a result about a real store.
A failure taxonomy for machine-mediated shopping.
Seven classes of failure a shopping agent can meet in a store. The taxonomy is versioned and open.
Read the taxonomy