The agentic web is the part of the web designed for software agents to understand declared capabilities and perform bounded tasks. For ecommerce, readiness requires more than making product pages readable. A store also needs to define which current state an agent can use, which visible elements it can work through, which actions are allowed, and how the result is verified.
That is the difference between an agent finding information about a store and participating safely in the interface a shopper is using.
Agent-readable and agent-executable are different
An agent-readable store exposes information an agent can retrieve or interpret. This can include crawlable pages, structured product data, merchant feeds, policies, and platform catalogs.
For the merchant-side data audit, see The AI Shopping Product Data Checklist.
An agent-executable experience exposes a bounded action contract. The agent can request a supported operation under the host’s authorization and receive an observable result.
Executability is not automatically better. An action surface creates more responsibility:
- Which state is current?
- Which user authorized the action?
- Which resources are in scope?
- Is the action reversible?
- What proves it completed correctly?
The useful goal is not maximum autonomy. It is a clear and inspectable boundary.
The five tests of interface readiness
1. Current state is connected
The host should supply the state relevant to the current task. That might be the record, screen, selection, or component state already in view.
“Connected current state” is deliberately narrower than “the agent knows the live catalog.” An agent should not infer state the host did not expose.
2. Visible targets are grounded
If the agent guides the shopper to an interface element, that target should be explicitly identified by the host. The shopper can then see what the guidance refers to and remain oriented.
This avoids an answer in one surface that leaves the shopper searching for the corresponding control somewhere else.
3. Actions are host-supported
The host decides which actions exist. A supported action needs:
- a defined job and input contract;
- the application’s normal authorization checks;
- a policy for risky or ambiguous requests;
- a clear failure state.
The agent’s ability to ask for an action does not grant permission to perform it.
4. Postconditions are verifiable
After a state change, the system should inspect or receive the resulting state. A function call that returned without an exception is not enough when the interface may still disagree.
Verification compares the requested postcondition with what the host now exposes.
5. The shopper remains oriented
The shopper should be able to see what changed, understand why, and continue from the familiar interface. This is a product-design requirement, not only a protocol question.
A readiness sequence for ecommerce teams
Step 1: map the interaction locus
Decide where the agent works:
- an external AI channel;
- a chat-contained shopping flow;
- an alternative or rebuilt storefront;
- an adaptive search or discovery canvas;
- the merchant’s connected existing interface.
Each locus implies different data, control, and continuity.
Step 2: enumerate state and targets
List the state and interface elements a connected experience genuinely needs. Expose the minimum useful set rather than an entire page or data model.
Step 3: define one supported action
Choose a low-risk, reversible task. Specify authorization, input constraints, expected result, and failure behavior before adding more actions.
Step 4: add post-action inspection
Record the starting state, action attempt, and resulting state. Treat mismatched or unavailable verification as a failure mode to surface.
Step 5: test comprehension and control
Ask target users:
- Can they explain what the agent observed?
- Can they see the target it is referring to?
- Do they understand which action it will take?
- Can they tell whether the action succeeded?
- Do they know how to reverse or correct it?
These questions are more useful at an early stage than claiming a conversion effect.
Where WebMCP fits
WebMCP is one experimental browser-side proposal for exposing structured page tools. Its current API uses document.modelContext. It is adjacent to interface readiness, but it is not the only possible implementation and is not a requirement for kn8.
The broader agentic commerce protocol stack covers different jobs including discovery, commerce, payment authorization, and agent-to-agent communication. Do not treat one browser API as the whole agentic web.
Common readiness mistakes
Treating crawlability as action support
Structured data can help an agent interpret content. It does not authorize a state change.
Treating a chat response as interface grounding
An accurate answer can still leave the shopper disconnected from the product, control, or next step it describes.
Exposing actions without postconditions
The system cannot distinguish success from a silent or partial failure if it never observes the resulting state.
Claiming arbitrary-site support
A connected-interface agent needs an explicit host contract. It should not imply that it can understand and operate any website without integration.
How kn8 approaches the interface
kn8 is an AI shopping agent whose workspace is the connected storefront interface the shopper is already using. It uses current state and visible targets the host exposes, guides the shopper in that interface, performs only supported actions, and verifies what changed. This wording does not claim a catalog, inventory, cart, checkout, platform, or protocol integration without a connected demonstration. See kn8 on a connected storefront task →
Key takeaways
- Agent-readable and agent-executable are different levels of readiness.
- Useful execution begins with bounded state, targets, permissions, and postconditions.
- Verification and shopper orientation are product requirements, not optional polish.
- WebMCP is one experimental adjacent proposal, not the definition of the agentic web.
- Start with one demonstrable task before making platform or commercial claims.