{"slug": "one-commerce-protocol-two-interfaces-pwa-for-humans-and-mcp-for-agents", "title": "One Commerce Protocol, Two Interfaces: PWA for Humans and MCP for Agents", "summary": "WebAZ, a commerce platform, has introduced a dual-interface architecture where a Progressive Web App (PWA) serves human users and a Model Context Protocol (MCP) server serves AI agents, both operating over a single state machine to ensure behavioral consistency. The company emphasizes that agent permissions must be explicitly declared and that irreversible actions require human approval via Passkey, preventing agents from impersonating users. WebAZ's 'shopping-v1' MCP surface is discovery-only, allowing agents to search listings without placing orders, as a safe deployment pattern.", "body_md": "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.\n\nThat split is convenient at the UI layer. It becomes dangerous when it reaches the transaction model.\n\nIf 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.\n\nThe safer design is two interfaces over one protocol.\n\nA PWA and an MCP server should not be identical. They serve different operators.\n\nA 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.\n\nThe interfaces can divide work without dividing truth:\n\n```\nHuman PWA                         Agent MCP\n---------                         ---------\ninspect terms                     read structured facts\nmanage identity                   search and compare\nreview a proposed action          prepare a request\nperform Passkey approval          receive the resulting state\ninspect exceptions                continue from explicit outcomes\n              \\                 /\n               one state machine\n```\n\nThe 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.\n\nPossession of a credential should not silently mean permission to perform every write.\n\nWebAZ 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.\n\nConceptually, an agent declaration can say:\n\n```\n{\n  \"allowed_actions\": [\n    \"search\",\n    \"place_order\"\n  ]\n}\n```\n\nThe 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.\n\nAgent workflows become easier to reason about when actions are separated by reversibility:\n\nAn 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.\"\n\nIn 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.\n\nSome 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.\n\nNot every MCP endpoint needs a path to checkout.\n\nWebAZ's reviewed `shopping-v1`\n\nsurface 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.\n\nThis is a useful deployment pattern:\n\nBefore adding an agent interface to a commerce system, ask:\n\nIf the answers differ by interface, the problem is not just API design. It is a split transaction model.\n\nAgent-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.\n\nWebAZ publishes the current integration contract, capability matrix and negative-space rules as machine-readable documents:\n\nThe PWA and MCP do different jobs. The protocol remains one.", "url": "https://wpnews.pro/news/one-commerce-protocol-two-interfaces-pwa-for-humans-and-mcp-for-agents", "canonical_source": "https://dev.to/seasonkoh/one-commerce-protocol-two-interfaces-pwa-for-humans-and-mcp-for-agents-4fme", "published_at": "2026-08-24 01:21:22+00:00", "updated_at": "2026-08-24 02:13:45.298738+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-infrastructure", "ai-safety"], "entities": ["WebAZ", "MCP", "PWA", "Passkey"], "alternates": {"html": "https://wpnews.pro/news/one-commerce-protocol-two-interfaces-pwa-for-humans-and-mcp-for-agents", "markdown": "https://wpnews.pro/news/one-commerce-protocol-two-interfaces-pwa-for-humans-and-mcp-for-agents.md", "text": "https://wpnews.pro/news/one-commerce-protocol-two-interfaces-pwa-for-humans-and-mcp-for-agents.txt", "jsonld": "https://wpnews.pro/news/one-commerce-protocol-two-interfaces-pwa-for-humans-and-mcp-for-agents.jsonld"}}