Commerce Execution in the Age of AI Agents

1. Executive summary

Ecommerce is acquiring a new kind of buyer. Autonomous agents now perform the steps a person used to perform: locating a product, choosing a variant, adding it to a cart, reaching a checkout.

Most preparation for this treats it as a discoverability problem — better markup, cleaner feeds, machine-readable surfaces. That work is necessary. It is also insufficient, and the gap it leaves is not small.

The argument of this paper is in one sentence: reaching checkout is not success if the wrong product got there. A journey can complete flawlessly and deliver the wrong variant, and every measure oriented around completion will record it as a pass.

We set out why this failure mode is newly dangerous, why an agent's own report cannot settle it, what evidence a defensible finding requires, and what a method for establishing it looks like.

2. From human ecommerce to agentic commerce

Storefronts have always depended on an unspecified component: a buyer who checks the work. Ask any shopper what they do when a cart shows the wrong size and they will describe fixing it without considering it noteworthy.

That behaviour has been silently absorbing a class of defect for as long as ecommerce has existed. The defects were never measured because they were never allowed to complete.

An autonomous buyer does not check the work. It proceeds. What was previously a corrected annoyance becomes a shipped order.

3. Being discoverable and being executable

Discoverability asks whether your product can be found and understood. Execution asks whether the buying journey then delivers that exact product.

They are independent. Structured data describes a product page; it says nothing about what the add-to-cart control does, which variant the cart receives, or what the checkout carries. A store can publish immaculate markup and substitute a variant three steps later.

Perfect discoverability followed by a wrong cart is arguably worse than not being found, because it spends the buyer's trust as well as their time.

4. Why HTTP success is not commercial success

Consider a cart endpoint returning HTTP 200, well-formed, every field present and correctly typed — describing a different variant than the one requested. Every conformance check passes. The protocol works. The shop does not.

This forces a distinction that is easy to lose. The transport result answers whether the interface was reachable and its answer usable. The commercial result answers whether the thing described was the thing requested. Collapsing them produces two errors: unreachable channels read as merchant defects, and correct-looking responses read as correct outcomes.

A response our own code cannot parse is a defect in our code. It must be attributed to the inspector, never to the store.

5. Product and variant identity as commercial truth

If execution correctness is the question, something must define what "correct" means. That something is identity: a typed description of which exact thing a surface is describing — product id, SKU, variant id, canonical reference, quantity, and an open set of option axes.

Two rules make identity usable as truth. Representation may be normalized; commercial meaning may not. And a disagreement on a strong identifier is decisive — a matching page title cannot rescue a mismatched SKU.

The identity chain carries this from the request through to checkout, under a rule that resists the most tempting error in assurance reporting: no downstream success may erase an upstream violation. A reachable checkout carrying the wrong item is a violation with a reachable checkout.

6. Browser truth and machine-readable channel truth

Merchants increasingly expose more than one commerce interface. A storefront and the merchant's own cart API can disagree about what is in the cart, and an agentic buyer using one of them will experience whatever it says.

Two constraints matter. First, comparison is only meaningful within one seller: two sellers are not two channels of one thing, and a price difference between them is a market. Second, the browser is not the definition of correct — the request is. Comparing everything to the browser would report a merchant whose storefront substitutes a variant, while their API returns the right one, exactly backwards.

7. Why an AI agent cannot be its own oracle

The most economical way to test agentic commerce would be to ask an agent to buy something and record whether it said it succeeded. This does not work, and the reason is structural rather than a matter of model quality.

An agent's report is a claim about the agent. It is generated by the same process whose correctness is in question, from the same possibly-misread page. When an agent reports success on a journey that put the wrong variant in the cart, the report is not a lie — it is an accurate account of what the agent believed.

Assurance therefore requires an independent observation of what the surfaces actually contained, and a deterministic comparison against what was requested. The agent's account is retained as evidence about the agent, and has no path into the verdict.

An illustrative case, which we ship as a reference artifact so it can be examined rather than assumed: an executor reports SUCCESS; the cart evidence shows a different SKU; the canonical verdict follows the evidence. Both facts are retained, because the disagreement is itself informative.

8. Evidence and provenance

A finding is only as good as what it can be checked against. That means retaining what each surface said, when, and where it came from — enough that a reviewer can re-derive the conclusion without re-running the journey and without trusting the tool that produced it.

Two design choices carry most of the weight. Evidence is bound by a deterministic integrity manifest, so alteration is detectable. And for machine-readable channels, the retained projection is built by allowlist rather than by redaction: a denylist over an arbitrary merchant document is a bet that every sensitive key was anticipated, and when that bet fails it fails by leaking. When an allowlist fails, it fails by dropping a field.

9. Reproducibility and deterministic controls

A single run establishes less than it appears to. Storefronts are variable — inventory changes, experiments run, sessions differ — so an outcome observed once may not be a property of the store.

Two mechanisms address this. Repetition classifies an outcome as reproducible, intermittent or insufficiently observed, without turning it into a score. And a deterministic control runs the same mission without an autonomous agent, which is what separates "the store is broken" from "the agent failed". Where the control completes and the agent does not, no merchant defect is established.

10. Reinspection and regression

Assurance that cannot be repeated is a snapshot. The valuable question is comparative: did this change break something, and did that remediation actually work?

Answering it safely needs two rules that pull in opposite directions. A fix requires positive evidence that the invariant now holds — absence is not remediation, because a cart that could not be read produces the same silence as a cart that is now correct. And a finding visible only because the tool improved is not a regression — nobody should acquire a defect because the instrument got better.

A comparison also has a premise. Two inspections of different products, or different sellers, are not a history, and a comparison whose premise is invalid should produce nothing rather than something readable.

11. What protocol support proves — and what it does not

Protocol work is worth doing. A machine-readable commerce interface is the difference between an agent guessing at a page and an agent reading a contract.

What it establishes is capability. What it does not establish is outcome. A merchant may implement a commerce protocol impeccably and still return the wrong variant through it, and no amount of conformance testing will surface that, because conformance is not asking.

For transparency about our own position: CRAB does not currently implement UCP, ACP or MCP as commerce channels. It implements merchants' own read-only cart interfaces on Shopify and WooCommerce. We say so in the method document and on the public pages, and we would rather be unimpressive than unclear.

12. Commerce Execution Assurance

The category these constraints imply is the independent verification that a commerce journey produced the correct commercial outcome, with retained evidence.

It is not monitoring, auditing or conformance testing, and it does not replace them. It answers the one question none of them asks: did the buyer get what they asked for?

13. The Commerce Execution Method

CEM is the documented method: the identity model, the identity chain, the nine stages, evidence and integrity rules, attribution rules, and the semantics of every state that can be reported. It is published as a prepublication draft.

It is a method, not a standard — not ISO, not W3C, not a certification scheme. We publish it so the method can be argued with independently of the product that implements it.

14. Implications for merchants

Being operable by a program and delivering the right product are different projects, and the second is currently under-resourced because completion is easy to measure and correctness is not.

The practical version: verify that the requested variant is what reaches the cart; check that any machine-readable channel agrees with the storefront; and re-verify after theme changes, app installs and platform upgrades, since those are where quiet substitutions are introduced.

15. Implications for ecommerce agencies

Agencies are asked increasingly often to make a store "AI-ready", and the deliverable is usually discoverability work whose success is asserted rather than demonstrated.

Baseline inspection, remediation, reinspection against that baseline is a defensible shape — provided the verification is independent of the implementation. An agency judging its own remediation is not assurance, whatever the report is titled.

16. Implications for commerce platforms

Platforms sit where these failures are most tractable. Variant substitution at add-to-cart, option controls that display without applying, and disagreement between a storefront and a platform's own cart API are platform-shaped problems, not merchant-shaped ones.

They are also the failures least visible to a platform, because they surface as individual merchant support tickets rather than as a pattern.

17. Limitations and open questions

• We publish no prevalence statistic. We have described failure shapes observed in our own inspections. We have not run a study designed to support a rate, and a percentage without that design would be a number pretending to be evidence.
• External observation only. CRAB sees the public commerce journey, not merchant internals. Some causes are not visible from outside.
• Protocol coverage is narrow today. Two merchant cart interfaces, read-only. Broader coverage waits on specifications and merchant adoption we do not control.
• Nothing is signed. Hash integrity establishes that evidence has not changed. It does not establish who produced it. A signing layer would be a separate thing.
• Open question. As agents become the dominant buyer, does the responsibility for execution correctness sit with merchants, platforms, or the agents themselves? We do not think this is settled.

18. About VSN and CRAB

VSN builds technology for agentic commerce, commerce execution assurance and commercial intelligence.

CRAB is VSN's commerce execution assurance product and the implementation of the Commerce Execution Method. It verifies whether the intended product and variant survive the commerce journey, and shows the evidence.

CRAB certifies nothing, scores nothing and signs nothing. It reports what happened, with the evidence to check it.

Next steps

• Check your commerce journey — request an inspection of a store you are authorised to test.
• CRAB Q&A — fifty questions on commerce execution assurance.
• The Commerce Execution Method — the method itself, as a prepublication draft.
• Commerce Execution in the Age of AI Agents — the whitepaper.

CRAB is built by VSN.