Humans and AI Agents Need One Commerce Record, Not Two Realities

An AI-commerce demo can look complete after three steps:

prompt -> product search -> tool call

That is enough to demonstrate connectivity. It is not enough to demonstrate commerce.

The difficult questions begin immediately afterward:

• Did the seller publish enough information for a decision?
• Was the quoted price still valid when the request was submitted?
• Did the Agent prepare an order or make a binding commitment?
• Which human approved the consequential step?
• Which settlement path was selected?
• If a response timed out, did the action fail, succeed or remain unknown?
• What evidence can the buyer, seller and operator inspect later?

A production-oriented system should not answer those questions differently depending on whether the user arrived through a browser or an Agent.

Humans and Agents need different permissions over one explicit commerce record, not two incompatible realities.

Start with shared facts

An Agent cannot make a reliable purchase decision from marketing copy alone. A useful product record needs decision-relevant facts such as:

{
  "price": "19.90 USDC",
  "availability": "in_stock",
  "handling_time": "within 72h",
  "delivery_estimate": "7-14 days",
  "return_window": "7 days",
  "unknowns": ["final carrier before fulfillment"]
}

The exact schema will differ by system. The important property is that a person and an Agent inspect the same facts, including what is not known.

If the browser says “available” while the Agent endpoint returns stale inventory, the system has not created agentic commerce. It has created a second, less visible storefront that will eventually disagree with the first.

Separate preparation from commitment

Many useful Agent actions are reversible:

• search;
• compare;
• request a quote;
• assemble a cart;
• prepare an order request;
• explain the terms to the user.

The commitment boundary is different. Creating an order, authorizing payment or accepting a consequential term should not be smuggled into a harmless-looking tool chain.

A safer flow looks like this:

discover
  -> quote
  -> prepare order request
  -> show terms and unknowns
  -> human approval
  -> create order

WebAZ currently uses this distinction on its authenticated commerce path. An Agent may search, quote, draft and submit an order request. A human Passkey approval is required before the order exists.

The reviewed public shopping MCP is narrower by design. It is anonymous and discovery-only: it exposes search but cannot create orders or move funds.

That limitation is a product property, not a missing demo effect. A client can connect the surface without accidentally giving an exploratory prompt transactional authority.

Settlement paths should remain distinguishable

“Payment supported” hides more than it explains.

Different settlement mechanisms have different trust assumptions, failure modes and recovery options. They should not be presented as interchangeable buttons behind one generic payment claim.

WebAZ currently exposes two real settlement paths.

Direct Pay

Direct Pay supports off-platform payment from buyer to seller. WebAZ records order states, acknowledgements, a snapshot of the seller's payment instructions and submitted evidence.

The boundary matters: WebAZ does not hold principal. It does not verify the payee or payment method, guarantee payment or delivery, or issue the seller's refund.

USDC on-chain escrow

The USDC path locks real funds in an immutable Base-mainnet contract. The contract constrains exits and enforces per-order caps on-chain; WebAZ does not custody the principal.

The contract has not had a third-party security audit. That disclosure belongs beside the feature, not in a footnote that disappears during promotion.

The shared principle is not that the two paths are equally safe. It is that the selected path and its boundary remain visible in the transaction record.

Payment is not fulfillment

A payment provider can report success while the commerce system still lacks a confirmed order, inventory allocation or fulfillment state.

Agents make this distinction more urgent because an automated retry can turn an ambiguous timeout into a duplicate consequential action.

After every write, the system should be able to answer:

1. What is the last proven fact?
2. What remains unknown?
3. Is the next action safe to retry?
4. Which participant acts next?
5. Which evidence supports that conclusion?

This is why state, acknowledgements, evidence, recovery and dispute handling are part of the commerce interface rather than back-office details.

Apply the same discipline to contribution

Agent participation has a similar boundary problem.

An Agent can discover a public task, inspect its constraints and prepare an evidence-backed suggestion. That does not automatically make the suggestion an accepted contribution, grant source access or create an economic claim.

The WebAZ production core is private. Source access and code contributions are invitation-based. Invited AI-assisted work requires a Passkey-bound accountable human.

Again, different roles operate on one record:

requester -> executor/tool -> reviewer -> accepted artifact -> accountable party

The Agent can be named as an executor without being presented as the person who accepted responsibility for shipping the result.

A four-question implementation test

Take one real transaction in your own system and ask:

1. What may the Agent read?
2. What may it prepare without committing the user?
3. Which exact step requires human approval?
4. What evidence remains after that action?

If the browser and Agent surfaces produce different answers, the integration is not yet operating under one commerce model.

If “payment succeeded” is the last explainable state, the transaction record is incomplete.

If the Agent can commit but nobody can identify the accountable approver, the permission model is incomplete.

The goal is not maximum autonomy. It is legible autonomy: every participant can see the facts, permissions, commitment boundary and resulting evidence.

That is the shared stack WebAZ is currently testing across its PWA, MCP surfaces, real settlement paths and contribution entry.

WebAZ: https://webaz.xyz