DEV Community: WebAZ

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

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

WebAZ — Mon, 31 Aug 2026 23:29:05 +0000

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:

What is the last proven fact?
What remains unknown?
Is the next action safe to retry?
Which participant acts next?
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:

What may the Agent read?
What may it prepare without committing the user?
Which exact step requires human approval?
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

An Open Task Is Not Yet a Contribution

WebAZ — Sun, 30 Aug 2026 03:02:23 +0000

Most contributor onboarding starts by collecting identity.

Create an account. Join the community. Request repository access. Pick an issue. Only then discover whether the work is relevant, bounded or even ready to be attempted.

That sequence is especially awkward in AI-assisted development. An Agent can produce a plausible patch quickly, but speed does not answer the questions that maintainers actually need resolved:

Was this problem authorized?
What files, systems or external actions were inside the boundary?
What evidence would prove completion?
Which risks required human review?
Who is accountable for the result?

A useful contributor surface should reveal those constraints before it asks for commitment.

Start with problems, not identity collection

WebAZ currently exposes a narrow public contribution entry through the full Remote MCP surface.

Without an API key, a person or Agent can:

list public build tasks;
inspect a task's execution boundary and acceptance criteria;
submit an evidence-backed suggestion to the maintainer review inbox.

The conceptual flow looks like this:

discover public task
  -> inspect boundary and verification
  -> decide whether the problem is understood
  -> submit a structured suggestion
  -> maintainer review

The default buyer-facing MCP surface does not advertise the contribution tool. The full surface exposes webaz_contribute, where list_open, detail and suggest are public starting actions.

A compact interaction can begin with:

{
  "action": "list_open",
  "area": "docs",
  "agent_capabilities": "markdown,read-source"
}

The result is not merely a title list. A task can describe risk level, required capabilities, autonomy, estimated effort, context size, dependencies, blocking conditions and whether human review is required.

Before doing anything, a prospective participant can ask for the detail view:

{
  "action": "detail",
  "task_id": "<public-task-id>"
}

That is where a real coordination system should state what may change, what must not change, what commands or evidence are expected and what “done” means.

Suggestions are intentionally weaker than contributions

The next distinction prevents the public entry point from becoming a participation factory.

A suggestion is a proposal in a maintainer review inbox. It is not:

a contribution fact;
formal participation;
repository access;
accepted work;
a reward, payment or redemption claim;
ownership or governance rights.

That weaker status is useful. It allows a newcomer to add signal without pretending that every idea has already created value for the project.

A good suggestion should still carry enough structure to be evaluated:

{
  "action": "suggest",
  "title": "Add a reproducible empty-state example for the public catalog",
  "summary": "The current guide shows successful search but not the expected zero-result contract. Add one exact request, response and verification note.",
  "expected_outcome": "A reader can distinguish an honest empty result from a transport or authentication failure.",
  "source_ref": "https://example.com/reproduction-note"
}

This example is illustrative. A real suggestion should link only to evidence the proposer is authorized to share.

Private source changes the public promise

The WebAZ production core repository is private. Source access and code contributions are invitation-based.

That means the public contribution surface must not imply an open repository or promise that a suggestion will turn into code access. Public discovery and proposal are the available first steps. Maintainers decide whether a proposal needs clarification, should be converted into a task or belongs outside the current scope.

This is less permissive than a public issue tracker, but it is more precise about what the system can promise today.

It also creates a safer role for Agents. An Agent can discover a bounded problem, compare its capabilities with the task requirements, assemble public evidence and draft a suggestion. It cannot independently become the accountable contributor. Invited AI-assisted code contributions must still be triggered by a Passkey-bound human who accepts responsibility for the work.

Task metadata is part of the product

An open-task system becomes useful when it helps prevent collisions and mis-scoped work.

For Agent-assisted collaboration, I would expect at least these fields:

{
  "risk_level": "low",
  "required_capabilities": ["markdown", "read-source"],
  "agent_autonomy": "autonomous",
  "estimated_context_size": "small",
  "human_review_required": false,
  "dependencies": [],
  "blocking_conditions": [],
  "value_state": "uncommitted"
}

The final field matters. A task estimate describes effort, not payment. A task record or suggestion should not be interpreted as an economic instrument or a promise of future value.

A five-question contributor test

Before adding another signup form or “good first issue” label, test the entry point with five questions:

Can someone see a real problem before registering?
Can they inspect the execution and verification boundary before starting?
Can they tell the difference between a suggestion and accepted contribution?
When AI assists, is there an accountable human?
Can a maintainer reconstruct why the work was accepted?

The goal is not zero friction. Trustworthy collaboration needs review, identity and responsibility at the right moments.

The goal is to delay those demands until the participant understands the problem, while keeping every later status honest.

For WebAZ, that begins with public task discovery and evidence-backed suggestions. No account is required to understand the work. Acceptance still has to be earned.

WebAZ entry: https://webaz.xyz

Payment Succeeded. Did the Transaction?

WebAZ — Sat, 29 Aug 2026 08:49:54 +0000

A payment API returns success. The interface turns green. Everyone relaxes.

But what exactly succeeded?

The payment rail may have accepted or settled money while the merchant never received the callback. Inventory may still be uncommitted. The selected variant may have changed. Fulfillment may not have started. A buyer or Agent may be staring at a timeout and deciding whether to retry.

In distributed commerce, payment success is one fact. Transaction completion is a chain of facts owned by different systems and people.

The green checkmark hides several clocks

A useful commerce state model separates at least these stages:

intent
  -> authorization
  -> payment attempt
  -> payment outcome
  -> merchant acknowledgement
  -> order acceptance
  -> fulfillment
  -> delivery / return / dispute

These stages do not advance on one clock.

The payment rail knows whether money moved.
The merchant knows whether it accepted the commercial obligation.
The inventory system knows whether the exact item and variant were committed.
The fulfillment system knows whether dispatch started.
The buyer knows whether the received outcome matches what was approved.

Collapsing them into paid=true creates a dangerous ambiguity: nobody can tell who owns the next action.

Timeout is a state, not permission to retry

Suppose an Agent submits a payment and the connection times out. There are at least three possibilities:

The payment failed before reaching the provider.
The payment succeeded, but the response was lost.
The provider accepted it, but final settlement is still pending.

Blindly retrying can create a duplicate charge. Blindly declaring failure can leave a paid buyer without an acknowledged order.

The correct response is usually outcome_unknown, followed by deterministic reconciliation. The system should query the authoritative payment record using the same idempotency key, compare it with the approved purchase intent and then advance the commerce state exactly once.

The receipt should connect intent to responsibility

A model-generated sentence is not enough. A recoverable transaction needs a compact machine-readable record such as:

{
  "intent_id": "intent_123",
  "idempotency_key": "checkout_123_attempt_1",
  "approved": {
    "seller": "seller_42",
    "item": "sku_7",
    "variant": "green-8-pack",
    "currency": "USDC",
    "maximum_total": "18.29",
    "destination": "SG",
    "terms_version": "terms_2026_08_29"
  },
  "payment": {
    "state": "confirmed",
    "authoritative_reference": "rail_ref_456"
  },
  "commerce": {
    "merchant_acknowledged": false,
    "inventory_committed": "unknown",
    "fulfillment": "not_started",
    "next_owner": "merchant_reconciliation"
  }
}

This is an illustrative architecture pattern, not a WebAZ API response. Its important property is that payment and commerce remain separate while the record identifies what was approved and who must act next.

Agents make this boundary more important

Humans already misread green checkmarks. Agents add retries, tool chaining and compressed summaries.

An Agent-safe commerce workflow should therefore:

bind approval to an exact seller, item, variant, currency, maximum total, destination and terms version;
assign an idempotency key before the first external write;
represent timeout as unknown, not failed;
reconcile against the authoritative rail before retrying;
keep payment, order and fulfillment states independently visible;
name the system or person that owns the next action.

The Agent may prepare and explain. It should not reinterpret approval or invent completion.

One current WebAZ example

WebAZ currently exposes two live settlement rails with different custody models.

With Direct Pay, payment happens off-platform from buyer to seller. WebAZ does not hold the principal. WebAZ does not verify the payee or payment method, guarantee payment or issue the seller's refund. It records order states, acknowledgements, a snapshot of the payment instructions and evidence so the later process remains legible.

For eligible USDC orders, real funds are locked in an immutable Base-mainnet escrow contract. The contract is runtime-gated, capped per order and has not had a third-party security audit. An on-chain payment or release still does not prove delivery; settlement and fulfillment remain different states.

The public WebAZ launch pulse reported 37 completed orders and 15 resolved disputes at 08:41 UTC on 29 August 2026. Those are dated protocol counts, not a claim that every failure mode above occurred on WebAZ.

A practical test

Take one failed or ambiguous checkout from your own system and answer five questions:

What is the last authoritative fact?
Which state is still unknown?
Is retrying safe, and how is that proven?
Who owns the next action?
What evidence will let the buyer, merchant and operator reconstruct the decision later?

If the answer is only “the payment screen was green,” the transaction is not yet legible enough for an Agent.

Payment success matters. But a trustworthy commerce system must also explain what happened next.

WebAZ protocol status: https://webaz.xyz/.well-known/webaz-protocol.json

An MCP Server Is Not Interoperable Just Because It Connects

WebAZ — Fri, 28 Aug 2026 07:34:14 +0000

An MCP handshake proves that two endpoints can start a session. It does not prove that an Agent can understand the tool, call it correctly, distinguish display text from machine-readable state, or know when to stop.

I ran an independent test with FastMCP 3.4.7 as the client and WebAZ's public shopping MCP as the remote server.

The question was deliberately narrow:

What should an MCP smoke test verify beyond connection success?

A four-part minimum

1. Advertised schema

Call list_tools() and inspect the input schema, not just the tool name. A caller should be able to construct a valid request and identify conflicting fields.

The tested endpoint exposed one anonymous tool, webaz_search. It did not advertise account, order, reservation or settlement actions.

2. Explicit error state

Check CallToolResult.is_error. A text block alone is not proof that an operation completed successfully.

The test call returned is_error=false.

3. Concise model-facing content

The ordinary content block summarized that three products were found without copying the full payload into model context.

4. Deterministic structured content

The structured result carried destination normalization, product fields and workflow state:

response_type=comparison
completion=complete
assistant_action=answer
Singapore normalized to SG
three products returned from four matches

Checking only rendered text would have missed the fields a deterministic client or UI needs.

Minimal reproduction

import asyncio
from fastmcp import Client


async def main():
    async with Client("https://webaz.xyz/mcp/shopping-v1") as client:
        tools = await client.list_tools()
        assert [tool.name for tool in tools] == ["webaz_search"]

        result = await client.call_tool(
            "webaz_search",
            {
                "query": "tissue",
                "ship_to": "Singapore",
                "sort": "price_asc",
                "limit": 3,
            },
        )

        assert result.is_error is False
        assert result.content
        assert result.structured_content["completion"] == "complete"
        assert result.structured_content["assistant_action"] == "answer"


asyncio.run(main())

Observed on 2026-08-28 with Python 3.13.12 and FastMCP 3.4.7.

The Agent-commerce implication

A fluent answer can hide an incomplete transaction state. Discovery is not a quote. A quote is not an order. An order is not settlement. Settlement is not fulfillment.

Those boundaries should be represented in schemas and structured results, not only in prose prompts.

This was one public, read-only call. It was not a security audit, load test, OAuth test, renderer test, order test or payment test. FastMCP did not participate in or endorse the experiment.

The takeaway: verify the advertised schema, is_error, concise content and raw structured_content separately. Connection success is only the beginning.

FastMCP client documentation: https://gofastmcp.com/clients/tools

Public test endpoint: https://webaz.xyz/mcp/shopping-v1

A 5-Minute Grok Commerce Experiment with a Custom MCP

WebAZ — Thu, 27 Aug 2026 11:08:10 +0000

This is a reproducible experiment, not a concept mockup. Add WebAZ to your own Grok account and test whether Grok can turn buying intent into structured product discovery and comparison.

WebAZ is not currently listed in xAI's preconfigured Connector Catalog, so installation uses Grok's Custom MCP option.

Before You Start

Use a Grok account with access to Connectors.
Open https://grok.com/connectors.
The public-search experiment does not require a WebAZ account.
Never paste a password, API key, wallet seed phrase or other secret into a connector URL or chat.

Experiment A: Public Product Search

Add the Connector

Click New Connector.
Select Custom.
Name: WebAZ Shopping
MCP URL: https://webaz.xyz/mcp/shopping-v1
Save and enable it.

Run the Test

Use WebAZ Shopping to find tissue under 15 USDC. Compare price, delivery time and return terms.

Expected Result

Grok invokes WebAZ Shopping Search.
It returns structured product cards rather than a generic list of links.
Results may include current WebAZ price, delivery, return and seller information.
Missing facts should remain missing; Grok should not invent shipping fees, taxes, guarantees or seller confirmation.

What This Does Not Do

No WebAZ account access
No order creation
No inventory reservation
No payment
No private account data

Experiment B: Account Quote or Draft

Add this only when you want account-authorized quote or draft functionality.

Click New Connector → Custom again.
Name: WebAZ Shopping Account
MCP URL: https://webaz.xyz/mcp/grok-v1
Complete WebAZ OAuth when prompted.

An OAuth prompt or HTTP 401 before authorization is expected security behavior.

Test with a bounded instruction:

Use WebAZ Shopping Account to prepare a quote for the selected item. Do not place an order or pay. Show the exact item, seller, price, delivery and return terms for my review.

A quote or draft is not a completed transaction. Any real commitment should remain subject to explicit human confirmation.

Business and Enterprise

A team administrator provisions the connector in xAI Cloud Console under Grok Business → Connectors → + Add Connector → Other. Team members can use it after provisioning, but each member must complete their own OAuth for account features.

Current Availability

Grok supports user-added Custom MCP connectors.
WebAZ public shopping initializes anonymously and is discovery-only.
WebAZ account functionality is OAuth-protected.
WebAZ is not currently in xAI's preconfigured Connector Catalog.
xAI does not currently document a public self-service submission process for third-party catalog listing.

Sources

Before You Connect an AI Shopping Tool, Ask These Seven Questions

WebAZ — Tue, 25 Aug 2026 15:15:15 +0000

Installing an AI connector is easy. Deciding whether it deserves authority is harder.

The usual installation guide answers technical questions: Which URL do I enter? Which package do I run? Which client is supported?

A useful trust guide should answer a different set of questions:

What can the AI access before I sign in?
Which actions can change real state?
Which actions still require a person?
What happens to payment?
What evidence survives after the tool acts?
Which safety claims can be independently checked?
What is still unknown or unfinished?

I am using WebAZ as the concrete example below, but the checklist applies to any MCP server or AI-commerce connector.

1. Can I test useful behavior without creating an account?

A connector should not demand maximum trust before demonstrating minimum usefulness.

WebAZ exposes a discovery-only shopping MCP endpoint:

https://webaz.xyz/mcp/shopping-v1

It can search the reviewed public product surface. It cannot create an order, reserve stock, charge a payment method, move funds, accept terms, or read private account data.

That makes the first evaluation reversible: connect, inspect product data, and decide whether the result is useful before registering.

The broader Remote MCP endpoint is:

https://webaz.xyz/mcp

For MCP clients that use local STDIO configuration, the current public bridge is:

npx -y @seasonkoh/webaz@latest

The package is a thin bridge to the live service. It is not a local copy of the private WebAZ production core.

2. Does the interface separate reading from acting?

“The AI has tools” is not a permission model.

A safer surface distinguishes at least four levels:

read public facts;
prepare a reversible draft;
request a consequential action;
commit or settle with accountable authorization.

On WebAZ, anonymous access is for public reads. Authenticated capabilities depend on the selected surface and granted authorization. Selected higher-risk actions return a browser approval URL rather than silently treating the model's request as the person's consent.

This distinction matters more than a generic instruction such as “please ask before buying.” Capability boundaries should exist in the interface, not only in the prompt.

3. Why does registration use an invitation and Passkey?

Browsing does not require an invitation. Account creation currently does.

WebAZ uses invitations as an anti-abuse and Sybil-resistance control while the live network is actively developed. It is an account-integrity control, not a launch-status label or an investment-style scarcity mechanism.

A Passkey binds the account to an accountable human and is retained as a confirmation boundary for selected consequential actions. It does not make every transaction safe, and it does not verify that a seller's off-platform payment instructions are correct. It establishes who approved an action; it does not replace due diligence.

4. Where does the money go?

The word “payment” is too broad to describe custody.

WebAZ currently has two real rails with different models.

Direct Pay

The buyer pays the seller directly off-platform. WebAZ records the payment-information snapshot, acknowledgements, order state, and evidence. WebAZ does not hold the principal, verify the payee or payment method, guarantee payment or delivery, or issue the seller's refund.

USDC on-chain escrow

Eligible orders can lock real USDC in an immutable contract on Base mainnet. Contract exits are limited to the original buyer, the voucher-bound seller, or the configured fee destination, and per-order caps are enforced on-chain.

The contract has not had a third-party security audit. That limitation belongs in the main explanation, not in fine print.

5. What remains after the AI acts?

An agent response is not a transaction record.

For a real workflow, the system should preserve the product and payment information that was accepted, the order state, relevant acknowledgements, evidence, and the transition that occurred. Without that trail, a convincing conversation can still leave the buyer and seller unable to explain what happened.

WebAZ is designed around explicit order states and evidence rather than treating the chat transcript as the source of truth.

6. Can the current claims be checked without trusting a social post?

The strongest source should be current and machine-readable.

WebAZ publishes its live protocol facts here:

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

The document reports the current software version, MCP endpoints, authentication model, network phase, payment disclosures, and links to additional capability and integration documents.

The official npm registry currently reports @seasonkoh/webaz version 0.1.36. Search snippets may lag behind registry changes, so the registry and the live protocol document are better version sources than an old directory page.

7. What should still make me cautious?

Trustworthy documentation should make refusal possible.

For WebAZ, the important limits include:

registration remains invite-gated;
additional payment methods are still being added;
Direct Pay occurs off-platform and the payee or method is not verified by WebAZ;
WebAZ does not guarantee payment, delivery, or seller refunds;
the USDC contract is live but has not had a third-party security audit;
the public npm package is a bridge, not public access to the private production core;
a manual MCP connection is not the same as an official app-directory listing.

Those statements do not weaken the trust story. They are the trust story.

A low-risk first test

Start with public discovery and ask the AI to separate facts from unknowns:

Search WebAZ for products relevant to my request. Show price, stock, delivery, returns, seller context, and every warning or missing field. Do not create an order or assume compatibility.

Use the Agent Commerce Lab for current client setup:

https://webaz.xyz/ai/

The first question is not whether an AI can click “buy.”

It is whether the system makes authority, evidence, custody, and uncertainty visible before anyone does.

Current-status boundary, verified 2026-08-25: WebAZ is publicly launched and actively developed. Direct Pay and eligible Base-mainnet USDC escrow are real payment rails with different custody models. WebAZ does not hold the principal on Direct Pay and does not verify the payee or payment method. The USDC contract has not had a third-party security audit. Public shopping discovery does not create orders or move funds.

The Second Click Is the Real Test of an AI Shopping Plugin

WebAZ — Tue, 25 Aug 2026 02:34:31 +0000

The first successful search is the easiest part of an AI shopping demo.

A user asks for a product, the model calls a tool, and a polished result card appears. That proves the happy path can work once. It does not yet prove that the integration can survive ordinary use.

The more revealing test is the second click.

Can the shopper open the same product again? Can they move between products without an earlier interaction suppressing the next one? What happens when a direct tool response and a matching result notification arrive in different orders? Does the detail view stay in the shopper's language?

Those questions shaped the latest WebAZ Shopping review build.

One interaction, one settlement

Interactive tool surfaces often receive the same logical result through more than one path. A direct response may arrive first, or a matching tool-result notification may arrive first.

If each path has its own timeout and success logic, the UI can briefly show a failure even though a valid result has already arrived. It can also render the same outcome twice or leave an interaction in an ambiguous state.

The safer model is to give each detail request one lifecycle and one deadline:

both valid arrival orders converge on the same settlement path;
duplicate suppression means "still pending," not success or failure;
the first matching success settles the interaction once;
a timeout remains an honest failure when no matching success arrives.

This sounds small, but it is the difference between a demo animation and a state machine that a user can rely on.

Repetition is part of the contract

A product-detail action is not globally unique. A shopper may inspect a product, compare another one, and return to the first. Deduplication that outlives one interaction turns a valid second click into a silent no-op.

The scope of deduplication therefore has to match the scope of the user action. Replays inside one interaction should be suppressed. A later, deliberate interaction should be allowed to run normally.

This principle applies beyond shopping. Idempotency protects a system from accidental replay, but it should not erase a new user intention.

Localization has to survive the tool boundary

A multilingual conversation can still produce a detail view in the wrong language if locale context is lost between search results, tool metadata, and the rendered component.

Keeping product details in the shopper's locale is more than a presentation preference. Shipping terms, return conditions, stock notes, and unknown fields are decision-relevant information. A language fallback can change whether the user understands the limits of the result.

Keep the first public surface narrow

The reviewed WebAZ Shopping endpoint is intentionally discovery-only. It exposes one public webaz_search tool for product search and comparison.

It does not provide login, account access, ordering, payment, credentials, or private data.

That boundary lets us test the read-only experience before attaching consequential actions. A shopping integration should first demonstrate that it can return repeatable, localized, decision-ready information. Preparation, commitment, and settlement can then be added behind their own explicit authority boundaries.

What this build proves, and what it does not

The current review build demonstrates a more reliable product-discovery interaction:

repeated detail clicks work as new interactions;
asynchronous result paths converge on one outcome;
timeouts remain explicit;
product details preserve shopper locale;
the public tool surface remains discovery-only.

It does not mean that a new ChatGPT plugin version has been approved or published. The build and demo are prepared for the review process; approval and publication are separate steps.

You can watch the current 55-second production demo here:

https://webaz.xyz/plugin-review/webaz-shopping-demo.mp4

For teams building AI commerce interfaces, the practical question is simple: after the first impressive result, what does your second click reveal about the system?

One Commerce Protocol, Two Interfaces: PWA for Humans and MCP for Agents

WebAZ — Mon, 24 Aug 2026 01:21:22 +0000

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.

Different strengths, shared state

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.

Permissions should describe actions

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.

Preparation is not consent

Agent workflows become easier to reason about when actions are separated by reversibility:

Read: inspect public or party-authorized state.
Prepare: search, compare, quote or assemble a request.
Commit: create a commercial obligation or change accountable state.
Settle: move value or finalize an irreversible outcome.

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.

A discovery-only surface is still useful

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:

start with a narrow read surface;
evaluate outputs against the human-visible record;
add preparation actions with explicit states;
add commitment only when identity, permission and recovery are defined;
keep human-presence requirements outside the agent's ability to bypass.

An integration checklist

Before adding an agent interface to a commerce system, ask:

Do the web app and the agent read the same product and order identifiers?
Can both interfaces name the same current state?
Is each agent write mapped to an explicit scope?
Are undeclared writes rejected?
Are preparation and commitment separate transitions?
Does human approval happen on a surface the person can inspect?
Can an agent resume from the confirmed result instead of guessing whether an action succeeded?
Can both interfaces produce the same audit trail when an operation fails?

If the answers differ by interface, the problem is not just API design. It is a split transaction model.

One protocol is the product

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.

The Most Important Output of a Shopping Agent May Be `unknown`

WebAZ — Sun, 23 Aug 2026 06:58:46 +0000

A shopping agent that always returns a complete answer is not necessarily useful. In commerce, completeness can be a warning sign.

Product pages are uneven. A listing may state price, stock, return terms, handling time and a delivery estimate while omitting exact dimensions, compatibility, maximum load or included accessories. A human buyer usually notices the gap and asks a follow-up question. A language model may instead complete the pattern from similar products and present the inferred value with the same confidence as a seller-declared fact.

The difficult part of AI commerce is therefore not only retrieval. It is preserving provenance and uncertainty through the entire decision process.

Three classes of product facts

An agent-facing product record should distinguish at least three classes:

Declared facts: values supplied by the seller or another accountable source.
Derived facts: values calculated from declared inputs through a visible rule.
Unknown facts: values that are absent, ambiguous, stale or unsupported.

These classes should not collapse into one polished description. A field that is absent should remain absent. A derived estimate should identify its inputs. A seller statement should not silently become a platform guarantee.

An illustrative response shape could look like this:

{
  "item": "Metal Laptop Cooling Stand",
  "declared": {
    "price": { "amount": 18.4, "currency": "USDC" },
    "availability": "in_stock",
    "return_window_days": 7,
    "handling_time_hours": 72,
    "delivery_estimate_days": { "SG": 12, "default": 18 }
  },
  "decision_flags": [
    "new_seller",
    "no_sales_history"
  ],
  "unknown": [
    "exact_dimensions",
    "weight",
    "supported_laptop_size_range",
    "maximum_load",
    "included_parts",
    "material_thickness"
  ],
  "checked_at": "2026-08-23"
}

This is an explanatory shape rather than a claim that every commerce platform uses the same schema. The useful property is the separation itself.

Why a string like `unknown` is not enough

Production systems usually need more than a null value. The reason a field is unknown affects what the agent should do next.

For example:

{
  "field": "maximum_load",
  "state": "unknown",
  "reason": "not_declared_by_seller",
  "next_action": "ask_seller",
  "blocks": ["compatibility_recommendation"]
}

Other reasons might include stale_value, conflicting_sources, not_applicable, or outside_sale_region. These states lead to different behavior. A stale price may require refresh. Conflicting dimensions may require evidence review. An undeclared compatibility claim should block a recommendation rather than invite a guess.

Decision flags are not verdicts

Risk indicators need the same care. A new seller or a seller with no sales history is not automatically untrustworthy. Those are decision flags: facts a buyer may want to weigh, not accusations generated by the platform.

The agent should surface the flag, explain its source and allow the buyer to choose. It should not convert a sparse history into a fabricated reputation score.

A public test surface

WebAZ currently exposes a reviewed, discovery-only shopping surface at:

https://webaz.xyz/mcp/shopping-v1

The surface exposes one search tool and cannot create orders or move funds. The WebAZ Agent Commerce Lab includes a known-versus-unknown prompt using the real reviewed laptop-stand listing described above.

The prompt asks the agent to produce two lists:

facts the listing actually states, with values;
facts a careful buyer would want but the listing does not state.

For the second list, the agent must say unknown and must not fill gaps with typical values for similar products.

That constraint matters because it makes the failure visible. If an agent invents a screen-size range or maximum load, the output can be compared against the public listing and rejected.

A practical evaluation checklist

When evaluating a shopping agent, test more than whether it found the product.

Does every price include a currency and a freshness signal?
Does availability come from the current sellable variant rather than marketing text?
Are handling time and delivery time kept separate?
Are return terms represented as conditions rather than a vague "easy returns" claim?
Can the agent list important missing fields without guessing?
Does it distinguish seller statements from platform verification?
Are decision flags shown as evidence for human judgment rather than automated verdicts?
Does the workflow stop before an unsupported or irreversible action?

This evaluation is useful even before a store supports agent checkout. It reveals product-data gaps that affect human buyers too.

Honest incompleteness is a capability

AI commerce is often presented as a race toward fewer questions and faster checkout. That framing rewards confident completion, even when the underlying product record is incomplete.

A safer goal is decision readiness. The agent should collect what is known, preserve where it came from, expose what remains unknown and identify the next responsible action. Sometimes that action is comparison. Sometimes it is asking the seller. Sometimes it is stopping.

You can run the known-versus-unknown test on the discovery-only WebAZ Agent Commerce Lab:

https://webaz.xyz/ai/

Ask it to separate seller-stated facts from missing details. The quality of the unknown list may tell you more than the recommendation.

Independent Stores Do Not Need a Second AI Store

WebAZ — Sat, 22 Aug 2026 07:33:45 +0000

When merchants hear that AI assistants may become a new shopping interface, the first reaction is often: do we need to build another storefront for agents?

Usually, no.

The more immediate problem is that the existing store rarely has one dependable product record that both a person and an agent can interpret in the same way.

A human shopper can open several tabs, read the product description, inspect a variant selector, find the shipping FAQ, and ask support what a vague sentence means. An agent has to turn all of that into a structured decision. If the facts conflict or a detail is missing, the model may omit the problem or fill the gap with a plausible answer.

That is not mainly a chatbot problem. It is a product-data and action-boundary problem.

One commercial truth, two interfaces

An AI-ready store does not need two independently maintained catalogs. It needs one commercial source of truth that can be rendered for humans and exposed to agents.

At minimum, that record should make these categories explicit:

Identity: product, exact variant, SKU or merchant product identifier.
Current state: whether the item is active and in stock now.
Commercial terms: price, currency, sale region, and seller or payee reference.
Fulfillment: handling time and delivery estimate, kept separate.
Returns: whether returns are accepted, the time window, and important conditions.
Evidence: when the value was checked and which system supplied it.
Unknowns: details the merchant has not declared and the agent must not invent.

The last category is easy to underestimate. A record that says unknown is often safer and more useful than a polished paragraph that lets a model infer the wrong compatibility, delivery date, warranty, or included accessory.

Here is an illustrative audit shape, not a claim about a universal commerce standard:

{
  "item_id": "merchant-item-123",
  "variant": "black-128gb",
  "availability": "in_stock",
  "price": {
    "amount": 49.00,
    "currency": "SGD"
  },
  "sale_regions": ["SG"],
  "handling_time": "2 business days",
  "delivery_estimate": "3-5 business days",
  "returns": {
    "accepted": true,
    "window_days": 7
  },
  "unknowns": [
    "official warranty coverage"
  ],
  "checked_at": "2026-08-22T07:00:00Z"
}

The exact schema will differ by platform. The important design property is that the agent does not have to reverse-engineer a transaction from marketing prose.

Discovery is not checkout

Making a product readable to an agent does not mean the agent should immediately be able to buy it.

These are different capability levels:

Discover: find products that match a request.
Compare: explain differences, missing information, and risk flags.
Prepare: build a quote, cart, or order request without creating an obligation.
Commit: create the order or authorize payment through the required human and policy controls.
Settle and recover: record what happened, reconcile unknown outcomes, and define who acts next.

A store can become much more useful to AI at levels one and two without granting autonomous checkout. This is a practical migration path because it improves product clarity before introducing irreversible actions.

A live implementation boundary

WebAZ is currently testing this separation in public.

As checked on August 22, 2026, its public protocol document reports software version 0.1.35 and schema version 37. The broad machine catalog at:

https://webaz.xyz/.well-known/webaz-acp-feed.json

is explicitly described as an ACP-inspired discovery projection, not a strict ACP-ingestable merchant feed. It exposes product-level fields such as item identity, title, description, price, availability, seller, sale region, category, and return terms when available.

WebAZ also exposes a smaller human-reviewed shopping surface at:

https://webaz.xyz/mcp/shopping-v1

That endpoint is deliberately discovery-only. It lets an agent search reviewed, active, in-stock listings and return decision flags, but it cannot create an order or move funds.

This boundary matters more than the size of the catalog. It creates a place to test whether agents can represent products honestly before asking them to perform consequential actions.

Audit one product page

Pick one product from an existing store and ask:

Can a buyer and an agent identify the exact sellable variant?
Are stock and price current, or only implied by page text?
Is the sale or delivery region explicit?
Are handling time and delivery time separated?
Are return terms machine-readable or buried in a generic policy page?
Does the page distinguish merchant-declared facts from assumptions?
Would a human page and an agent response show the same commercial terms?
If a value changes, can both interfaces identify the newer record?

The goal is not to make the page longer. The goal is to make the same commercial truth available through a human interface and a machine interface.

Start with legibility

AI-ready commerce is often framed as an autonomous-checkout race. That skips the more basic work.

Before an agent can transact responsibly, it has to know what is being sold, by whom, under which terms, which facts are current, and which facts are missing. A separate AI storefront can hide those problems behind another interface. A shared product record exposes and improves them.

You can test the discovery-only WebAZ Agent Commerce Lab here:

https://webaz.xyz/ai/

Try one real shopping request, then inspect which facts are explicit and which questions still require the merchant or buyer.

Connect Your AI to a Real Store, But Do Not Let It Buy Yet

WebAZ — Fri, 21 Aug 2026 05:56:20 +0000

Most AI-commerce demos race toward the most dramatic moment: the agent clicks Buy.

That is probably the wrong first milestone.

Before an AI should create an order, it needs to demonstrate something less exciting and more important: it can inspect a real store without inventing facts or assuming authority it does not have.

The first test is not checkout

A useful shopping agent should be able to answer questions such as:

Did it find the exact product or merely a similar title?
Is the product currently in stock?
What delivery estimate did the seller actually state for this destination?
What are the return and handling terms?
Which important details are missing?
Is the seller new or missing transaction history?

The agent should expose those facts before it asks for permission to do anything consequential.

This leads to a clean initial architecture: create a discovery surface that has enough real commerce context to support a decision, but no capability to create an order or move money.

A deliberately narrow MCP surface

WebAZ now exposes a live shopping MCP endpoint:

https://webaz.xyz/mcp/shopping-v1

It requires no login and exposes exactly one tool: webaz_search.

The surface is limited to reviewed, active, in-stock physical products. A search can return product price, stock status, delivery estimate, return window, handling time, public seller context, and explicit decision flags.

It cannot:

create an order;
reserve stock;
charge a payment method;
move funds;
accept terms for a user; or
access private account data.

This is not a temporary omission. It is the point of the surface.

A live query

On August 21, 2026, I queried the public tool for phone stand products that could ship to Singapore.

The tool returned three current matches. The displayed price range was 2 to 16.1 USDC. All three were in stock and showed seven-day returns. Their stated handling times ranged from 48 to 72 hours, with an approximately 12-day seller-provided delivery estimate for Singapore.

The results also included decision flags. All three indicated a new seller; two indicated no sales history.

Those flags are more important than they may appear. Product discovery systems are often optimized to return something plausible. A decision-support system should instead make uncertainty and weak evidence visible.

The query result is not an order, reservation, settlement quote, or recommendation. Products and terms can change. It is a dated snapshot of what the reviewed catalog stated at query time.

The human boundary comes later

Discovery-only does not mean agents can never participate in a transaction.

On the authenticated WebAZ surface, an agent can move through reversible preparation steps:

search → quote → draft → submit order request

Execution stops there. A human Passkey approval is required before the order exists.

That separates two very different questions:

Can the agent prepare a decision?
Who has authority to create the real obligation?

The public shopping endpoint answers the first question without quietly granting the second.

Why this matters for three audiences

Buyers

The agent can organize current facts and unknowns before the buyer decides whether to continue. It cannot turn a recommendation into a purchase behind the user's back.

Independent sellers

The same query becomes a store-readiness test. If an agent cannot explain stock, delivery, returns, variants, and warnings accurately, the problem may be missing or ambiguous catalog data rather than the AI model.

Agent builders

The interface keeps the public tool surface small. There is no need to rely on a prompt such as “please do not buy anything.” The capability simply is not present.

That is a stronger boundary than model behavior alone.

Try the test

The live Agent Commerce Lab includes setup instructions for ChatGPT, Claude, Codex, and Cursor:

https://webaz.xyz/ai/

One prompt to try:

Find phone stands that ship to Singapore. Compare price, stock, delivery ETA, returns, handling time, and every decision flag. Separate facts the listing states from facts that are missing. Do not assume compatibility unless the listing states it.

The interesting result is not whether the agent produces a confident recommendation.

It is whether the agent knows where confidence should stop.

Boundary: The public WebAZ shopping MCP is discovery-only. It does not create orders, charge, reserve inventory, move funds, or accept terms. Product availability and seller-stated terms can change.

DEV Community: WebAZ

Your MCP Server Needs a Machine-Readable "No"

Missing tools are not a complete boundary

Five kinds of "no"

1. Unavailable

2. Scope-gated

3. Rate-limited

4. Forbidden

5. Human-gated

Documentation is not enforcement

A live example

A practical test for Agent builders

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

Start with shared facts

Separate preparation from commitment

Settlement paths should remain distinguishable

Direct Pay

USDC on-chain escrow

Payment is not fulfillment

Apply the same discipline to contribution

A four-question implementation test

An Open Task Is Not Yet a Contribution

Start with problems, not identity collection

Suggestions are intentionally weaker than contributions

Private source changes the public promise

Task metadata is part of the product

A five-question contributor test

Payment Succeeded. Did the Transaction?

The green checkmark hides several clocks

Timeout is a state, not permission to retry

The receipt should connect intent to responsibility

Agents make this boundary more important

One current WebAZ example

A practical test

An MCP Server Is Not Interoperable Just Because It Connects

A four-part minimum

1. Advertised schema

2. Explicit error state

3. Concise model-facing content

4. Deterministic structured content

Minimal reproduction

The Agent-commerce implication

A 5-Minute Grok Commerce Experiment with a Custom MCP

Before You Start

Experiment A: Public Product Search

Add the Connector

Run the Test

Expected Result

What This Does Not Do

Experiment B: Account Quote or Draft

Business and Enterprise

Current Availability

Sources

Before You Connect an AI Shopping Tool, Ask These Seven Questions

1. Can I test useful behavior without creating an account?

2. Does the interface separate reading from acting?

3. Why does registration use an invitation and Passkey?

4. Where does the money go?

5. What remains after the AI acts?

6. Can the current claims be checked without trusting a social post?

7. What should still make me cautious?

A low-risk first test

The Second Click Is the Real Test of an AI Shopping Plugin

One interaction, one settlement

Repetition is part of the contract

Localization has to survive the tool boundary

Keep the first public surface narrow

What this build proves, and what it does not

One Commerce Protocol, Two Interfaces: PWA for Humans and MCP for Agents

Different strengths, shared state

Permissions should describe actions

Preparation is not consent

A discovery-only surface is still useful

An integration checklist

One protocol is the product

The Most Important Output of a Shopping Agent May Be `unknown`

Three classes of product facts

Why a string like unknown is not enough

Decision flags are not verdicts

A public test surface

Why a string like `unknown` is not enough