From product pages to product protocols

A product page is a conversation with a person who is already looking at your store. A protocol is a promise to anyone, including a machine, about how to ask questions and what shape the answers will take. Commerce is moving from the first to the second.

What a page assumes

A page assumes a human with a browser, patience, and context. It assumes they will scroll to find shipping information, hover to see a size chart and click through a cookie banner. None of that is written down anywhere. It is simply what everyone expects from a shop.

What a protocol states

A protocol writes the expectations down. It says: here is how you ask what this item costs, here is how you ask whether it is available in a given size, here is how you start an order and here is what a completed order looks like. The details can vary. The predictability is the point.

We have seen this pattern before. Search engines pushed merchants toward structured markup. Payments settled on a few standard flows. Each time, the merchants who adopted the shared shape early got reach they did not have to negotiate for.

A gradual shift

Nobody has to rebuild their store. The practical path is incremental: publish structured product data alongside every page, keep it correct, and expose the few actions an agent needs. Then measure whether an agent can use it.

Why measurement comes with it

A protocol that nobody tests drifts. Prices update in one place and not another, a field gets renamed, a checkout step is added. Conformance tooling and public benchmarks exist to catch that drift. They turn a vague claim of agent-friendly into a result a merchant can check.