When a product adds an agent interface, it is tempting to treat it as a second application: the web interface is for people, while a collection of tools is for AI.
That split is convenient at the UI layer. It becomes dangerous when it reaches the transaction model.
If the human interface and the agent interface use different order states, permission rules or definitions of completion, the system develops two versions of commercial reality. A person may see a pending request while an agent reports a completed action. A step that requires human confirmation in the web app may become an unreviewed shortcut in the agent API. When something fails, neither side can explain the same outcome.
The safer design is two interfaces over one protocol.
A PWA and an MCP server should not be identical. They serve different operators.
A human interface is good at displaying terms, collecting deliberate approval, managing identity and helping a person inspect an exception. An agent interface is good at structured discovery, comparison, repetitive preparation and following explicit machine-readable contracts.
The interfaces can divide work without dividing truth:
Human PWA Agent MCP
--------- ---------
inspect terms read structured facts
manage identity search and compare
review a proposed action prepare a request
perform Passkey approval receive the resulting state
inspect exceptions continue from explicit outcomes
\ /
one state machine
The important property is not visual consistency. It is behavioral consistency. Both interfaces should agree on the entity being acted on, the current state, the allowed transition and the evidence produced by that transition.
Possession of a credential should not silently mean permission to perform every write.
WebAZ publishes a capability matrix in which authenticated agent writes map to named action scopes. Undeclared writes are denied by default. This makes authorization part of the integration contract instead of an assumption hidden in client code.
Conceptually, an agent declaration can say:
{
"allowed_actions": [
"search",
"place_order"
]
}
The exact set is less important than the principle: permission should name the action and its boundary. A search capability does not imply permission to place an order. Permission to prepare an order does not imply permission to approve an irreversible step.
Agent workflows become easier to reason about when actions are separated by reversibility:
An agent can be very useful at the first two levels. Moving from preparation to commitment should require a visible rule, not a vague instruction such as "buy the best one."
In WebAZ, risk actions return an approval URL. The human completes the required Passkey ceremony in a browser surface. The agent can prepare the action and continue after the protocol reports the result, but it does not impersonate the person during the approval.
Some actions are covered by an iron rule: no declared scope overrides the requirement for live human presence. This is a protocol property, not a preference left to each agent client.
Not every MCP endpoint needs a path to checkout.
WebAZ's reviewed shopping-v1
surface is deliberately discovery-only. It exposes one search tool for reviewed active listings and cannot create orders or move funds. That smaller surface lets buyers and builders evaluate whether an agent can represent product facts and unknowns honestly before introducing consequential actions.
This is a useful deployment pattern:
Before adding an agent interface to a commerce system, ask:
If the answers differ by interface, the problem is not just API design. It is a split transaction model.
Agent-native commerce should not mean maintaining an AI shortcut beside the real system. It should mean exposing the real system through another interface while preserving the rules that make its outcomes understandable.
WebAZ publishes the current integration contract, capability matrix and negative-space rules as machine-readable documents:
The PWA and MCP do different jobs. The protocol remains one.