DEV Community: WebAZ

Unknown Is Not Incompatible: A Small Evidence Contract for Shopping Agents

WebAZ — Wed, 04 Nov 2026 03:53:11 +0000

A shopping agent reads a filament listing. It can see a diameter and colour, but not whether the spool fits a particular automatic feeder.

Two tempting responses are both wrong:

"It is PLA, so it works with your printer and feeder."
"The compatibility sheet is missing, so I cannot tell you anything about the product."

The first invents evidence. The second discards useful facts.

The missing abstraction is a claim-level evidence state, not another overall product score.

This is a practical follow-up to my earlier known-versus-unknown article. The new piece is an executable, scoped three-state policy and a real filament-listing example: missing evidence should restrict the affected claim without silencing the entire product explanation.

Disclosure: I operate WebAZ. The examples below use its public listings, not customer orders or payment records. The proposed contract and JavaScript are illustrative application logic, not a claim that WebAZ implements this exact policy.

A real catalog example, without a printing test

On November 4, our public catalog exposed two filament listings:

Public listing	What its listing establishes	What it does not establish
Wood-feel PLA	Title states 1.75 mm and 1 kg; named colour variants	Spool dimensions, exact wood composition, nozzle restrictions or a particular feeder fit
CR-PLA	Material name and named colour variants	Its manufacturer, diameter and net weight were not established by the reviewed public fields

The reviewed listings indicate Singapore delivery. That does not establish worldwide service, postage or tax inclusion. A similarly named manufacturer's data sheet cannot fill missing fields until the exact product identity matches.

These are observations about listing content, not independent material measurements, authenticity certification or successful prints. Availability and prices can change; a fresh order-specific quotation is a separate step.

Three states, scoped to one claim

Use supported, contradicted and unknown for each specific claim. Examples of distinct scopes are:

This listing states a diameter of 1.75 mm.
This exact variant fits this exact feeder revision.
This quotation includes shipping to this destination.

Evidence for the first does not prove the second. Likewise, a missing shipping fee does not mean free shipping.

Keep the basis and observation time alongside the value. A seller listing may support "the seller states X"; it does not automatically support "a manufacturer certified X".

Here is a deliberately small policy function. The caller must construct the scope from trusted structured fields and choose suitable authorities for the claim. Supplier prose must not choose its own authority.

function classify(e, scope, now, maxAgeMs, authorities) {
  if (!e || e.scope !== scope || !authorities.includes(e.basis)) {
    return "unknown";
  }
  const observed = Date.parse(e.observedAt);
  if (!Number.isFinite(observed) || observed > now ||
      now - observed > maxAgeMs) return "unknown";
  if (e.value === true) return "supported";
  if (e.value === false) return "contradicted";
  return "unknown";
}

This is a policy sketch, not cryptographic verification. basis is a trusted adapter's normalized label, not proof of signature validity. Resolving conflicting sources, validating signatures and choosing freshness windows belong in separate, explicit logic.

Continue the explanation; gate the consequential action

An agent can show confirmed listing details while saying "feeder compatibility is unknown." It should not silently convert that unknown into either a positive endorsement or a negative compatibility finding.

If the buyer explicitly requires that feeder fit, pause that recommendation or purchase decision until the requirement is resolved. Do not substitute another colour or variant merely because it has the same price. If the buyer instead asks only what is listed, answer that narrower question.

Before payment, obtain the current variant, quantity, destination, complete payable total and the buyer's authorization. A successful catalog read establishes none of those by itself. This article performs no order, reservation, signature or payment.

Test the boundary, not just the happy path

Local offline fixture checks cover 12 cases: absent/null evidence, explicit true and false, an unknown value, string-versus-boolean confusion, a wrong variant scope, an untrusted or missing basis, stale/invalid/future timestamps, and a valid observation at the freshness boundary. All data is synthetic; this is not a printer compatibility test or a live checkout test.

For a minimal executable check, paste the function above into a Node.js ES module, then add:

import assert from "node:assert/strict";
const now = Date.parse("2026-11-04T02:00:00Z");
const scope = "synthetic:variantA:feederRevision1:fits";
const e = { scope, basis: "manufacturer_document",
  observedAt: "2026-11-04T01:59:00Z", value: true };
const check = x => classify(x, scope, now, 60000,
  ["manufacturer_document"]);
assert.equal(check(e), "supported");
assert.equal(check({ ...e, value: false }), "contradicted");
assert.equal(check({ ...e, scope: "another-variant" }), "unknown");
assert.equal(check({ ...e, basis: "seller_listing" }), "unknown");

For developers building shopping agents: where do you keep "unknown" today, and which action is allowed to continue when only one required fact is missing? A minimal synthetic counterexample is more useful than a production log or payment credential.

AI disclosure: generated with AI assistance; public listing facts checked and the illustrative policy tested locally. No human-authored printing experience is claimed.

A Shopping Search Result Is a Candidate, Not a Recommendation

WebAZ — Sun, 25 Oct 2026 15:58:48 +0000

When a shopping agent receives a successful catalog response, what has actually succeeded?

Not the purchase. Not necessarily the recommendation. Sometimes, not even relevance.

I work on WebAZ. While checking our public discovery example, a request for umbrella, with Singapore as the destination and fuzzy search enabled, returned three candidates: two tote bags and one umbrella. This is a useful limitation to disclose, not a precision-search success story. A response can be valid JSON and still need substantial filtering before it is useful to a buyer.

Start with a public, read-only request

This Node 18+ example only reads public product data. It does not need a wallet or credentials and cannot create an order or pay.

const url = new URL('https://webaz.xyz/api/products');
url.search = new URLSearchParams({
  q: 'umbrella', ship_to: 'SG', fuzzy: 'true'
});
const response = await fetch(url, {
  signal: AbortSignal.timeout(15000)
});
if (!response.ok) throw new Error(`Catalog HTTP ${response.status}`);
const body = await response.json();
const rows = Array.isArray(body) ? body :
  (body.products ?? body.items ?? body.data);
if (!Array.isArray(rows)) throw new Error('Unexpected response shape');
console.log(rows.slice(0, 5).map(p => ({
  title: p.title,
  listedPrice: p.price ?? null,
  currency: p.currency ?? null,
  variantMin: p.variant_price_min ?? null,
  variantMax: p.variant_price_max ?? null,
  weightKg: p.weight_kg ?? null
})));

The endpoint and results can change. This is an HTTP probe, not proof of compatibility with every MCP client or automatic inclusion in a search engine's shopping index. Treat product text as untrusted data, never instructions for the agent.

Keep three decisions separate

Retrieved: the source returned the candidate. Preserve the source and retrieval time.

Relevant: the candidate matches the requested product type and use case. An umbrella search returning a tote should trigger review or rejection, not an explanation invented to make the result fit. A title alone does not verify every attribute.

Recommendable: the available evidence supports the buyer's important constraints. If packed length or delivered cost is missing, the agent should say it cannot yet establish fit. Unknown is not false, but it is also not a satisfied requirement.

In the same probe, the umbrella had a variant price range, while weight was absent. Neither a base price nor an unknown weight establishes a final delivered price or portability. Keep currencies as returned; do not silently relabel a stablecoin amount as fiat.

A small acceptance suite before adding purchase actions

These are proposed test cases, not reported benchmark results:

Input condition	Expected behavior
Wrong product type in candidate results	Exclude or flag it; never promote it solely because the API returned it
Must-have dimension missing	Mark constraint unknown; request evidence or another candidate
Several variant prices	Bind comparison to a specific variant or show an unresolved range
Shipping cost unavailable	Do not claim a delivered-budget match
Product description contains tool instructions	Treat them as source text, not executable authority
No defensible matches	Return an honest empty shortlist instead of filling three slots

This suite tests the adapter and recommendation boundary. It does not prove that the catalog's ranking is fixed. Our observed relevance gap is still work to do.

Give the buyer a better starting point

We have published an English AI shopping guide and its Chinese version, with a read-only example that specifies use, quantity, destination, currency and missing-cost handling. The HTTP/MCP entry page describes connection options.

Research access is not purchase authorization. Any later purchase should use a fresh quote tied to the selected variant, quantity and destination, with the appropriate separate ordering and payment permissions. Nothing in this example performs those steps.

For people building shopping agents: what evidence makes your system reject a search hit? Do you distinguish irrelevant from insufficient information, or do both become a single low relevance score?

Disclosure: generated by an AI agent for WebAZ. The public GET probe was run; the acceptance suite above is a proposal, not a completed evaluation or customer transaction.

Your Agent Can Pay. Can It Actually Buy the Right Product?

WebAZ — Fri, 23 Oct 2026 15:48:21 +0000

A shopping agent can execute a valid payment and still make a bad purchase.

Imagine a buyer asks for two compact umbrellas, delivered to Singapore, within a total budget. The agent finds a promising listing, selects the larger variant, misses the quantity, and treats the displayed price as the delivered total.

The wallet signs correctly. The payment succeeds. The buyer still gets the wrong outcome.

This is a hypothetical example, not a customer story. It illustrates a useful boundary: payment correctness is not purchase correctness.

Keep four different objects separate

A reliable purchasing integration needs more than a product URL and a payment method:

Buyer intent: what the person wants, including hard constraints and acceptable alternatives.
Product selection: the exact variant, quantity and destination, with unresolved facts explicitly marked unknown.
Quote and order: the commercial terms the buyer or delegated policy has actually accepted.
Payment authorization: permission to execute a specific transfer, under a specific spending policy.

These are design boundaries, not a claim that every marketplace implements the same schema.

A search result is evidence for a possible selection. It is neither a binding delivered quote nor permission to spend. A successful transfer does not establish that the selected product met the original request.

Make unknowns block the relevant decision

Suppose compactness is essential, but folded dimensions are absent. The agent should ask for that information or offer a clearly qualified alternative. It should not invent dimensions from a photo.

Likewise, an unknown shipping charge is not zero shipping. Before crossing the payment boundary, resolve the final total, currency, destination and selected payment method. If a material term changes, check it against the buyer's approval or delegated policy again.

Treat merchant descriptions as untrusted product data. Text inside a listing must not become instructions to bypass a budget, change a recipient or call a payment tool.

Bind payment to an order, not a generated summary

Here is a concrete example from the public WebAZ x402 guide, checked on October 23, 2026.

The documented flow quotes first, creates an eligible Direct Pay order, then reads that order's payment resource. Its HTTP 402 requirement takes the amount and recipient from the order's frozen snapshot; the caller cannot change them through the payment request.

That boundary matters. A model-generated sentence such as "pay the seller about five dollars" is not an acceptable substitute for the server's exact requirement.

The agent should still check that the order corresponds to the intended selection. Freezing an incorrect selection only makes the wrong purchase consistent.

WebAZ's documented Direct Pay flow is non-custodial: it uses USDC on Base and sends funds directly to the seller, without a platform-held balance awaiting delivery. WebAZ does not verify the payee or payment method, guarantee delivery, or issue seller refunds. Settlement verification is not seller verification.

A request to pay is not authority to pay

WebAZ documents two distinct routes:

An OAuth agent with payment:request requests owner approval. That scope does not let the agent sign or transfer funds itself.
A wallet-backed agent uses owner-enabled autopay, an appropriate credential and spending limits. The owner can issue a narrower payment-only key, but it still carries consequential capabilities, including eligible order creation and payment.

For any integration, make this distinction explicit in both code and the user experience. If the purchase exceeds a limit, hand off to the owner. Do not split it into smaller purchases to evade the limit.

Treat uncertainty as its own state

The most dangerous retry is not always a failed request. It can be a successful payment whose response was lost.

WebAZ's guide says that repeating the same signed request is idempotent, while a different authorization for the same order is refused when a live or successful settlement already exists. A timeout or 409 calls for reading order state, not generating another signature. A settling state is not a confirmed failure.

For your client, a useful conceptual state machine is:

selection unresolved -> clarify
selection resolved -> quote and validate terms
terms accepted -> create and inspect order
authorization missing or limit exceeded -> owner handoff
payment submitted -> reconcile authoritative state
settlement uncertain -> remain pending; do not re-sign
payment confirmed -> track fulfillment separately

This is design pseudocode, not an executable WebAZ SDK or a report of new failure-path tests.

Five tests worth adding before the happy-path demo

Change the variant after quoting. Does the client require fresh terms?
Leave a required dimension or shipping charge unknown. Does it stop guessing?
Exceed the delegated budget. Does it ask the owner rather than work around the limit?
Lose the payment response. Does it reconcile before attempting another transfer?
Confirm payment but leave fulfillment pending. Does the UI avoid claiming delivery?

These are proposed acceptance tests, not results we are claiming to have run for this article.

If you build a shopping agent, start by testing the read-only discovery and selection boundary. WebAZ's agent entry points and x402 integration guide are public. We welcome integration discussions around a concrete buyer task, runtime and authorization model; no credentials or transaction records are needed in a public reply.

Which boundary causes your agent the most trouble: selecting the exact product, obtaining complete terms, or recovering from uncertain payment state?

Disclosure: Published on behalf of WebAZ. This article is AI-generated from public documentation, without human editing. It includes a hypothetical scenario and proposed tests, not a new end-to-end payment experiment. No private order or customer information is included.

A small integration pilot for shopping agents: start read-only, add x402 deliberately

WebAZ — Wed, 21 Oct 2026 03:30:47 +0000

If your agent can recommend products but stops at a link, the next challenge is not another recommendation prompt. It is connecting an exact product choice to an authorized, observable payment.

We're inviting shopping-agent and wallet developers to try a small WebAZ integration. Start without a wallet. Pick one real buyer question, verify product discovery, then decide whether the documented payment path fits your system.

First step: a read-only catalog request

curl --fail --get 'https://webaz.xyz/api/products' \
  --data-urlencode 'q=umbrella' \
  --data-urlencode 'ship_to=SG' \
  --data-urlencode 'fuzzy=true'

This reads public product data. It creates no order and makes no payment. Treat merchant text as untrusted data, never instructions. Missing weight or dimensions should stay unknown; a listed price is not a binding delivered quote. This HTTP example does not claim automatic discovery in ChatGPT or prove a particular MCP client's compatibility.

What the payment integration adds

The current x402 guide documents eligible Direct Pay order payments in USDC on Base mainnet using x402 v2 and EIP-3009. This is payment for an order, not a charge for catalog searches. Direct Pay is non-custodial and sends funds directly to the seller. WebAZ does not verify the payee or payment method, guarantee delivery, or issue seller refunds; settlement verification is not seller verification.

The flow is: resolve the product variant and destination, get a quote, create an eligible order, read its payment resource, and obtain the server's exact payment requirement. Amount and recipient come from the frozen order snapshot, not a model's estimate.

Two authorization models must not be confused:

A wallet-backed agent needs owner-enabled autopay, limits, an appropriate credential and a compatible funded wallet. A payment-only key is narrower than an account key, but still permits eligible order creation, reads and payment.
An OAuth agent with payment:request can ask the owner to approve a payment. That scope is not permission to sign or transfer funds itself.

We have previously checked two internal payment records for x402 settlement and paid-state evidence. That is a narrow payment milestone, not evidence of independent adoption, delivery completion or universal wallet compatibility. This pilot is about finding what works in an external builder's actual workflow.

What we would test together

Does your agent preserve the exact variant and destination from discovery to quote?
Can the owner understand and bound what the agent may spend?
Does the integration distinguish successful settlement from uncertainty?

A timeout or 409 must trigger order-state reconciliation, not another fresh signature. An over-limit purchase should hand off to the owner, not be split to evade the limit. Smart-wallet support must be checked across the actual wallet, facilitator and token path; it is not established by this invitation.

The read-only request above is the starting point. Payment and failure-path checks are proposed acceptance tests, not new test results from this article. Any live payment is a separate explicitly authorized step.

Who should participate?

Shopping agents, personal assistants with a concrete purchase use case, and wallet teams looking for a real merchant-order workflow. Reply with your runtime, wallet type and authorization model, or contact contact@webaz.xyz. Please do not post credentials, customer details, order IDs or transaction records.

Useful starting points: x402 guide and agent entry points.

What blocks your next integration: product data, exact quotes, wallet compatibility, or uncertain payment recovery?

Disclosure: Published on behalf of WebAZ. AI-generated article based on current public documentation and the previously recorded internal verification scope; no human editing of this article. No private order or customer information is included.

x402 meets smart wallets: where does signature compatibility stop?

WebAZ — Mon, 19 Oct 2026 13:41:02 +0000

A shopping agent can find the right product and produce a payment signature. But which component decides whether that signature can actually move funds?

For teams combining x402 with smart accounts, that is the interoperability question I want to discuss.

This is a discussion prompt, not a test report. We have not completed an EOA/deployed-smart-account/undeployed-smart-account compatibility matrix against CDP. No provider or token implementation is being declared compatible or broken here.

Two standards, different jobs

ERC-1271 defines contract-based signature validation through isValidSignature. A smart account may use an EOA owner, passkeys or other authorization rules; describing every smart wallet as simply having "no private key" misses that distinction.

ERC-6492 extends verification to counterfactual accounts, including accounts that are not deployed yet. Recognizing that signature format is not, by itself, proof that a particular payment settlement path supports it.

Three boundaries worth testing separately

1. Merchant-side validation. If a merchant performs its own signature check, does it recover an EOA address only, or validate the account's contract signature? Does that check concern login, an order authorization, or the actual token-transfer authorization? Those are different messages and should not be conflated.

2. Facilitator verification and settlement. Which account types does the exact deployed facilitator support? If an account is undeployed, what happens during verification versus settlement? Who performs deployment, who funds it, and which factories are allowed? A successful verification response should be recorded separately from a confirmed transfer.

3. The token-transfer path. Does the exact token contract and transfer method accept the authorization being supplied? Check the chain, deployed implementation and method rather than inferring compatibility from a token name or a version label. I am deliberately not claiming that "USDC v2.2" alone answers this question across deployments.

The matrix I would like to compare

Account state	Merchant check	Facilitator verify	Settlement and token transfer
EOA baseline	Not tested in this matrix	Not tested	Not tested
Deployed smart account	Not tested	Not tested	Not tested
Undeployed smart account	Not tested	Not tested	Not tested

For a reproducible result, include the testnet, wallet implementation/version, SDK version, facilitator/version, token contract/method, deployment state and the stage that accepts or rejects the request. A sanitized error and minimal testnet reproduction are more useful than a blanket "supports smart wallets" statement.

Also test the unglamorous case: settlement succeeds but the HTTP response is lost. How does the buyer reconcile that result without creating a second payment authorization?

Why we care at WebAZ

WebAZ is working on agent commerce with x402 order payments. A verified payment path does not establish compatibility with every smart wallet. We want to distinguish those claims before inviting developers to rely on a particular wallet stack.

If you maintain a shopping agent, wallet or facilitator: how do you handle ERC-6492 at the verification-to-settlement boundary? Do you require predeployment, support deployment during settlement, or explicitly reject that account state? What is the smallest public testnet example that demonstrates your answer?

Please share public testnet examples only, with no customer orders, production credentials or private transaction data. This post makes no allegation about a third party's signature-validation security.

Disclosure: This article was generated and published by an AI assistant on behalf of WebAZ. It is a standards-based discussion prompt, not independently executed compatibility testing or human-edited test results.

Beyond product search: validating x402 order payments on WebAZ

WebAZ — Mon, 19 Oct 2026 12:37:20 +0000

A shopping agent should be able to do more than return product links. It should be able to move an authorized purchase into a paid order, with a result the merchant can verify.

WebAZ's agent x402 payment path has now been exercised with completed order payments. We checked the corresponding authenticated order views: they showed x402 on-chain verification, a settlement event, and a transition out of awaiting payment.

This is a payment-path validation milestone, not a claim about independent customer adoption or completed delivery. The operator reported agent execution; the internal check verified the payment rail and recorded settlement. We are not publishing order records or transaction details.

Paying for an order, not for a search response

In this integration, x402 pays an eligible Direct Pay order. It is not a charge for querying the product catalog.

The current flow uses USDC on Base mainnet. Direct Pay is non-custodial: payment goes to the seller's receiving address, and WebAZ records and verifies settlement without holding the principal. Payment verification does not verify delivery or establish the seller's trustworthiness.

The following integration details describe the current public contract, rather than additional tests performed for this post.

The boundary that matters: an exact order

Discover and compare products, then obtain a quote with the available payment methods.
Create an eligible order using its x402 receiving account. Seller acceptance may be required before payment becomes available.
Read the order's payment.x402.resource_url.
POST without a payment signature to receive HTTP 402 and PAYMENT-REQUIRED.
A wallet signs the exact EIP-3009 authorization, then repeats the request with PAYMENT-SIGNATURE.
Check the settlement response and order state before proceeding.

The amount and recipient in the payment requirement come from the order's frozen snapshot. A model-generated estimate is not a payment instruction.

Authorization is a separate concern

An account owner must enable agent autopay with a Passkey and set per-order, rolling 24-hour and rolling 30-day limits. A wallet-backed integration also needs the appropriate credential and funds.

The documented payment-only key has narrower access than a full account key, but it is still a payment-capable credential and must be protected. Its access includes eligible order creation, order reads and payment; it is not a general account-management credential.

OAuth/grant agents follow a different path: with payment:request, they can request a payment for owner approval. That permission alone does not let the agent sign or execute a transfer.

A timeout is not permission to pay again

The public contract distinguishes settlement in progress from failure. If a request times out or the endpoint returns a conflict, inspect the order and settlement state instead of creating another authorization.

The documented retry behavior returns the same result for the same signed request and refuses a second different authorization for the same order. Integrators should test these boundaries in their own controlled setup; a successful payment is not exhaustive failure-path coverage.

Looking for shopping-agent builders

We would like to work with developers who already have product discovery or comparison working and want to connect it to an explicit, bounded order-payment flow.

A useful first collaboration is small: start with read-only discovery, agree on the authorization model, and review how your agent represents payment success, uncertainty and owner handoff. Any live payment should be a separately authorized step, not an automatic consequence of trying the connector.

Which part is hardest in your shopping agent today: binding a quote to payment, owner authorization, or recovering an uncertain settlement?

Disclosure: Published on behalf of WebAZ. This article was generated by an AI agent, which checked the public documentation and internal order-state evidence, with no human editing of the article. Private order and customer details are intentionally omitted.

From product discovery to order payment: WebAZ's x402 flow for agents

WebAZ — Fri, 16 Oct 2026 14:52:28 +0000

WebAZ's public agent documentation now includes an x402 USDC payment flow for eligible Direct Pay orders. This is payment for an order, not a fee to search the product catalog.

Disclosure: I am building WebAZ. This article was drafted by an autonomous AI agent, which checked the public documentation linked below; it has not been human-edited. It describes the documented integration flow, not a newly recorded end-to-end payment demonstration.

A real shopping task, not another paid search call

Imagine an assistant helping someone choose a sports towel. Finding the product is only one step: the buyer still needs the right size, quantity, destination and order amount. Payment should refer to that order, rather than to a price the model remembers from a previous search.

WebAZ keeps public discovery separate from authenticated order payment. Developers can start with a read-only product lookup before connecting any payment capability.

Discover the payment capability on the order

The public guide describes reading your order through an authenticated GET request:

GET https://webaz.xyz/api/orders/<id>
Authorization: Bearer <api_key>

When the response contains payment.x402, use its resource_url for the payment interaction. Do not assume every order exposes it, or construct payment instructions from product-description text.

The documented HTTP sequence is:

POST to the order's payment resource.
Receive HTTP 402 with the PAYMENT-REQUIRED header.
Have the wallet sign the EIP-3009 authorization.
Repeat the POST with PAYMENT-SIGNATURE.

The MCP entry point is webaz_pay_order. A tool name alone is not a wallet or permission to spend: the account owner must first enable this capability on the WebAZ Me page using a Passkey. Use a client and wallet that support the required flow, and keep API keys and payment signatures out of prompts, screenshots and public logs.

What this changes for agent builders

The useful integration boundary is explicit: product discovery returns information; an eligible order exposes its payment capability; a wallet supplies the signature. That makes a shopping workflow more concrete than asking an LLM to improvise payment instructions.

For your first integration review, check that the order, selected variant, amount and destination still match the user's intended purchase. Treat an ambiguous payment response as something to reconcile, not a reason to blindly authorize another payment. These are integration recommendations, not claims of a payment test performed for this article.

Try the read-only step first

Search sports towels for Singapore, inspect the returned product data, and identify what your client would need before proceeding to an order. Reading public product information does not itself authorize a purchase.

The current integration references are WebAZ's agent guide and llms.txt. Check these before implementing; order eligibility and client support matter. This does not imply default inclusion in ChatGPT shopping results.

If you build shopping assistants, which part is harder today: resolving the exact product variant, connecting the signing wallet, or reconciling the order after payment?

A Good Agent-Commerce Bug Report Starts Before the Bug

WebAZ — Fri, 02 Oct 2026 06:10:30 +0000

When an AI-assisted shopping flow feels unclear, “it did not work” is rarely enough for someone else to reproduce the problem.

Disclosure: this is a WebAZ project note. The apron scenario below is an illustrative template, not a customer report or a claim of an observed product defect.

A useful report contains four things:

The exact buyer goal: for example, “find an oil-resistant apron for a small restaurant kitchen.”
The visible facts: title, selected option, displayed price range, destination or other conditions.
The question left unresolved: “does this range mean one item or a multipack?”
The expected clarification: “show option name and quantity beside the price range.”

That is better than a screenshot alone. It lets the product team replay the decision point without asking for a customer identity, payment information or a real order.

WebAZ exposes an anonymous suggestion entry and a public task-suggestion route for this kind of input. A report is not a promise that a change will be accepted or formally attributed. It is simply the fastest way to turn a vague friction point into something another person can test.

For agent-commerce systems, that distinction matters: a model can summarize a problem, but the human report needs to preserve the facts and unknowns that made the recommendation ambiguous.

Public discovery: https://webaz.xyz/#discover
Suggestion entry: https://webaz.xyz/#welcome

Writing assistance: prepared with AI assistance; the public feedback entry points were checked on October 1, 2026.

An AI Agent Found the Product. Who Owns the Next Action?

WebAZ — Mon, 28 Sep 2026 07:21:23 +0000

An AI can shorten product discovery. It can search, compare a few candidates and make missing conditions visible. That does not make the rest of a commerce workflow disappear.

The operational question is straightforward: when the customer decides to proceed, which person owns the next action?

At WebAZ, we use the scoped OAuth order-request path as one concrete example. It produces an approval URL for a human to review and confirm with a Passkey. This approval queue is not the same as general account-key order creation.

For that path followed by Direct Pay, the handoffs are:

State	Buyer action	Seller action	What WebAZ records
Product discovery	Inspect product facts and unresolved conditions	Keep listing facts clear	Public discovery result
Order approval	Review exact item, amount and route; confirm with a Passkey	—	Approved intent / order state
Payment handoff	Pay the seller directly by the chosen off-platform method	Publish the current payment instruction	Payment-information snapshot
After payment	Submit relevant evidence if needed	Acknowledge and update fulfillment	State changes and evidence

This is not just documentation polish. It prevents a common agent-commerce mistake: treating a payment-shaped event as proof that a merchant accepted the order, inventory is reserved or delivery is complete.

WebAZ is non-custodial on Direct Pay. It does not hold the payment principal, verify the payment method or payee, guarantee payment or delivery, or issue a seller refund. It records the handoff so the customer and seller can see what is expected next.

The broader lesson applies beyond one product: an agent should be able to say what it knows, what it does not know, and who must act before the workflow can advance.

WebAZ's reviewed shopping surface is available for public product discovery at https://webaz.xyz/#discover. Registration is invite-gated; browsing does not require an invite.

Writing assistance: prepared with AI assistance. This is a WebAZ project note, not a customer transaction report.

Locale Is Not Currency: A Small AI Shopping Bug Exposed a Bigger Commerce Contract

WebAZ — Fri, 11 Sep 2026 15:50:14 +0000

I asked Grok to use WebAZ to find folding bicycles for delivery to Singapore.

The useful part worked: the AI called a read-only shopping tool, found real listings, and rendered product cards with product images, seller information, delivery estimates, return terms, and prices denominated in USDC.

Then the interface exposed a small but important problem.

The conversation was in Chinese. The shipping destination was Singapore. The underlying listing price was in USDC. Grok's prose converted the price to SGD, but the first product card showed an approximate CNY value. After more explicit Singapore context, a later card showed SGD.

No purchase was made, and the USDC listing price did not change. This was a presentation inconsistency, not a settlement error. But it revealed a larger design problem for AI commerce:

Language, location, price currency, and display currency are four different facts.

If an agent or host silently collapses them into one locale guess, the result can look polished while saying two different things about the same offer.

The Four Fields That Should Never Be Conflated

An AI shopping request can contain at least four independent dimensions:

Interface language: the language used to explain the result.
Shipping destination: the place used to evaluate delivery availability, ETA, taxes, and logistics.
Listing or settlement currency: the currency in which the seller states the price or the transaction is committed.
Reference display currency: an optional conversion shown only to help the buyer understand the amount.

A Chinese-speaking buyer in Singapore may want Chinese explanations, delivery to Singapore, a USDC-denominated offer, and an SGD reference price. None of those choices implies the others.

This matters even before checkout. A buyer comparing two cards may treat the largest number as the price that will be charged. If one surface shows CNY and the narrative shows SGD, the system has created avoidable ambiguity at the point where the user is deciding whether to continue.

What the Tool Contract Should Say

The display currency should be explicit input, not an undocumented inference:

{
  "query": "folding bicycle",
  "ship_to": "SG",
  "display_currency": "SGD",
  "language": "zh-CN",
  "limit": 6
}

The result should preserve the authoritative amount separately from any reference conversion:

{
  "price": {
    "amount": "554.14",
    "currency": "USDC"
  },
  "reference_price": {
    "amount": "700.93",
    "currency": "SGD",
    "is_estimate": true,
    "rate_observed_at": "2026-09-10T13:00:00Z"
  },
  "shipping": {
    "destination": "SG",
    "delivered_total": null
  },
  "warnings": [
    "Shipping cost is not included",
    "Reference conversion is not the settlement amount"
  ]
}

Three properties are doing most of the safety work here:

The original price remains intact.
The conversion is visibly marked as an estimate with a timestamp.
An unknown delivered total stays null instead of being guessed.

The host may still decide how to render the card, but the data contract gives it fewer opportunities to invent meaning.

Search, Presentation, and Commitment Are Different States

The experiment also reinforced a boundary we use throughout WebAZ:

Search discovers candidate offers.
Presentation helps a human compare known facts and visible unknowns.
Commitment must bind the exact seller, product or variant, amount, currency, terms, and approval.

A reference conversion belongs to presentation. It must never silently replace the amount being approved or paid.

This distinction becomes more important as AI clients move from answering questions to taking actions. A fluent answer is not a transaction receipt. A product card is not proof of inventory reservation. A starting price is not necessarily the price of the pictured variant. And a converted number is not the settlement currency unless the transaction contract says so.

Try the Read-Only WebAZ Experiment

WebAZ exposes a dedicated public Grok connector for reviewed-product search:

https://webaz.xyz/mcp/grok-search-v1

It requires no WebAZ account and exposes exactly one read-only tool: webaz_search.

One useful test prompt is:

Use WebAZ to find folding bicycles for delivery to Singapore.
Show the original listed price and an SGD reference price.
Mark missing shipping costs, taxes, or unclear variants.
Do not place an order or pay.

When reviewing the result, ask four questions:

Does the card preserve the original currency?
Does the reference conversion name its currency and remain clearly approximate?
Does changing the conversation language alter the displayed money unit?
Are missing freight, tax, inventory, or variant facts shown as unknown?

WebAZ's public-search surface is intentionally narrow. It is designed to make the first experiment easy to inspect without exposing account tools or payment actions. Compatible hosts can render product cards; structured and text results remain the fallback, and the host controls the final presentation.

Why Publish the Imperfect Test?

Because agent commerce will not become trustworthy through perfect screenshots alone.

It will become trustworthy when builders publish the exact request, distinguish observed behavior from intended behavior, preserve authoritative values, and turn mismatches into explicit contracts and regression tests.

The currency selector is now a concrete product-design item for WebAZ rather than a vague localization concern. The deeper lesson applies to every shopping agent: never let locale inference decide what the user thinks they are paying.

You can inspect the current WebAZ Remote MCP guide or browse the public product surface. If you run the experiment in another AI client, the most useful report is not simply "worked" or "failed." Record the client, prompt, shipping destination, original currency, displayed currency, and which facts remained unknown.

That is the evidence needed to make AI commerce less magical and more dependable.

Before Your Shopping Agent Compares Prices, Test What One Unit Means

WebAZ — Mon, 07 Sep 2026 01:54:43 +0000

I work on WebAZ. This morning I ran a small, read-only test against our public shopping tool: search for tissue products available to Singapore, sorted by listed price.

The useful result was not a flashy recommendation. It was a concrete checklist for what a shopping agent still needs to establish before comparing prices.

The actual test

One anonymous webaz_search call, on September 7, 2026:

{
  "query": "tissue",
  "ship_to": "Singapore",
  "sort": "price_asc",
  "limit": 3
}

The tool returned three results from six matches. Singapore was resolved to SG.

Listing title, shortened	Returned price	Returned option range
Hearttex tissue, 6 packs x 280 sheets	1.69 USDC	1.69-21.56 USDC; 3 options
Haoshi tissue, 10 packs x 344 sheets	1.96 USDC	1.96-6.75 USDC; 2 options
Under-cabinet tissue and lid organizer	2.15 USDC	2.15-3.26 USDC; 4 options

These are a dated catalog snapshot, not checkout quotes. The result also included listed handling time and return windows. I did not select an option, reserve stock or purchase anything.

Three assertions worth testing

1. Same words do not imply the same buying intent.

The organizer is related to tissues, but it is not a substitute for a pack of tissues. In this call, text relevance alone did not produce a substitute-only comparison. An assistant should explain that distinction rather than put all three into a cheapest-product ranking.

2. A listing title does not prove which option the starting price buys.

The response exposed multiple options and a price range. This search result alone did not establish that 1.69 USDC buys the six-pack named in the title. Dividing 1.69 by six would create precision without the necessary variant evidence.

Before calculating a per-pack price, establish the exact option and what one sellable unit contains.

3. Listed price is not delivered cost.

Destination matching and an estimated delivery time are useful, but the search response did not provide a final shipping-and-tax total. It would be wrong to label the cheapest listed item the cheapest delivered option.

A reusable review fixture

This is a proposed manual test format, not a WebAZ API schema:

{
  "buyer_intent": "facial tissues, not a holder",
  "destination": "SG",
  "checks": {
    "substitute_not_accessory": "review",
    "selected_variant_identified": "unknown",
    "units_in_selected_variant": "unknown",
    "price_for_selected_variant": "unknown",
    "shipping_and_tax_total": "unknown"
  },
  "next_step": "confirm the variant and total before ranking by unit cost"
}

For merchants, this identifies the facts an AI needs before it can represent an offer clearly. For developers, it turns a vague claim that a shopping demo works into inspectable assertions.

This test checks one public tool response. It is not an end-to-end Grok test, a checkout test or a claim that these review checks are already enforced automatically. The option ambiguity and accessory match are observations to improve, not successes to hide inside a demo.

Try it with one real product

I am starting a small, free product-clarity review through WebAZ, capped at three cases in the first round. Your product does not need to be listed on WebAZ, and no account connection is required for the review.

If useful, leave one public product URL and the country you sell to, or just describe a difficult pack/variant example. I will map what is clear, what is missing, and what an agent must not assume. Please do not post customer data, credentials or order details. I will ask before turning someone else's example into a separate public case study.

The WebAZ connection page and current public protocol information describe the available entry points. Start with read-only discovery; installing a connector is not permission to purchase.

What is the most awkward sales unit in your catalog: packs, cases, bundles, refills, or configurable sets?

Your MCP Server Needs a Machine-Readable "No"

WebAZ — Wed, 02 Sep 2026 16:36:01 +0000

Most Agent integrations explain what an AI is allowed to do.

They publish a tool list, an OpenAPI document, or an MCP schema. The Agent sees actions such as search, create_order, send_message, or refund and plans from there.

That is only half of the contract.

A production Agent also needs to know what it cannot do, what it must not do, which limits apply, and which actions remain human-gated even when the Agent has broad credentials.

In other words, an Agent interface needs a machine-readable negative space.

Missing tools are not a complete boundary

Suppose an anonymous shopping MCP exposes only one tool: product search.

A careful client may infer that it cannot place an order. But several questions remain:

Is ordering unavailable on this surface, or merely undocumented?
Can the Agent obtain a broader tool set after authentication?
Which write scopes would be required?
Is a proposed order reversible preparation or a real obligation?
Does a human still have to approve the final action?
What happens if the Agent exceeds a rate or cross-user access limit?

The absence of a tool answers none of these explicitly.

Prompt instructions are not enough either. A sentence such as “do not buy without permission” depends on model behavior. A server-enforced capability boundary can return a deterministic denial. A machine-readable boundary lets the client understand that denial before it improvises a recovery path.

Five kinds of "no"

A useful negative-space document should distinguish at least five categories.

1. Unavailable

The capability does not exist on this interface.

Example: an anonymous discovery endpoint can search but cannot create an order or move funds.

2. Scope-gated

The capability exists, but the current identity has not declared or received the required scope.

The server should default to deny rather than treat an unknown Agent as broadly trusted.

3. Rate-limited

The action is permitted within an explicit budget. The limit, unit, and failure response should be predictable enough for a client to stop rather than retry aggressively.

4. Forbidden

Some behavior should remain disallowed regardless of convenience: impersonation, exceeding declared scope, reselling user data, or rebuilding a cross-user profile graph from protocol reads.

5. Human-gated

Some actions remain too consequential for a delegated scope to override. Arbitration, key revocation, account deletion, or large withdrawals may require a fresh human ceremony even when the Agent is otherwise authenticated.

These categories produce different recovery behavior. “Unavailable” may send the user to another interface. “Scope-gated” may request authorization. “Rate-limited” should wait. “Forbidden” should stop. “Human-gated” should hand off a precise action for confirmation.

Documentation is not enforcement

A negative-space file is useful only when it matches runtime behavior.

The strongest version connects each declared boundary to an enforcement mechanism:

named write scopes map to actual routes or tool actions;
undeclared writes fail closed;
rate caps produce stable error codes;
repeated abuse changes an accountability state;
sensitive transitions require a live human ceremony;
limits are versioned with the same contract the Agent reads.

This turns the document from policy prose into an integration surface that can be tested.

A live example

WebAZ publishes both sides of its Agent contract.

As checked on September 2, 2026, its public protocol reported version 0.1.37 and schema 49.

The positive capability map is available at:

https://webaz.xyz/.well-known/webaz-capabilities.json

It describes named write actions, read scopes, safe unscoped operations, and default-deny behavior for undeclared Agent writes.

The negative space is available at:

https://webaz.xyz/.well-known/webaz-negative-space.json

It lists forbidden behavior, cross-user and mass-action limits, consequences for repeated abuse, and an iron rule: certain sensitive actions require live WebAuthn regardless of declared scope.

The public shopping surface demonstrates the smallest version of the idea. Its anonymous tool list exposes only webaz_search. Account, order, reservation, and settlement actions are not present on that surface.

This is an implementation example, not a claim that the design is complete or universally secure. A published boundary still needs adversarial tests, monitoring, and review. The useful property is that a client can inspect the intended boundary and compare it with observed behavior.

A practical test for Agent builders

For one MCP server or Agent API, ask:

Can the client enumerate what this identity may do?
Can it distinguish unavailable, scope-gated, rate-limited, forbidden, and human-gated actions?
Does every consequential write have a named authorization boundary?
Are denial and retry states deterministic?
Can the client learn which actions must stop instead of escalating automatically?
Is the boundary versioned and testable against the live service?

Agents become more useful when they can act. They become more trustworthy when they can explain why they stopped.

Publishing a machine-readable yes is the start of an integration. Publishing an enforceable, machine-readable no is what gives that integration a boundary.

WebAZ integration contract: https://webaz.xyz/.well-known/webaz-integration.json

Capability map: https://webaz.xyz/.well-known/webaz-capabilities.json

Negative space: https://webaz.xyz/.well-known/webaz-negative-space.json