BLOG / ai-commerce-authority-handoffs.mdx
AI commerce authority handoffs: from product knowledge to an order
Map four explicit handoffs from SKU.md to live Catalog, MCP or UCP, page WebMCP actions, Checkout, and order systems.
An agent should cross four explicit authority handoffs before a product explanation becomes an order. Every handoff revalidates identity, state, permission, or user intent.
SKU.md is merchant-hosted product discovery and stable product knowledge: agents can find products, understand sourced facts, and know where to recheck live commerce. It is not a new checkout protocol.
The four handoffs
| Handoff | Source owns | Required guard |
|---|---|---|
| 1. SKU.md → live Catalog | Current Product, Variant, price, and availability | Exact identity match and fresh response |
| 2. Catalog → MCP or UCP capability | Callable operation and negotiated input/output | Capability, authentication, scope, and error handling |
| 3. Live source → page WebMCP action | Action meaningful in the open page’s current UI | Visible context and user review |
| 4. Action → Checkout/order | Binding totals, payment, purchase, and order state | Explicit confirmation and authoritative completion result |
These are conceptual handoffs, not a claim that every merchant uses all four technologies. SKU.md is not adopted by UCP, MCP, or WebMCP merely because an independent document links to them.
Handoff 1: knowledge returns to live Catalog
The agent reads stable Facts, Claims, Disclosures, and Limitations, then matches Product, Variant, SKU, and any GTIN against the live result. UCP Catalog says catalog pricing and availability reflect current request terms but are not transactional commitments; Checkout remains authoritative.
If the live source is unavailable or identity conflicts, the handoff fails. The agent should report uncertainty rather than substitute offer_snapshot or prose.
Handoffs 2 and 3: callable capability and page action
MCP can expose tools and resources, but the protocol surface does not itself prove that a merchant authorizes a call or that its result is current. UCP can bind commerce capabilities to REST or MCP after discovery and negotiation.
WebMCP is a separate page-context draft. A page can expose an action meaningful in its active UI. It is not a backend catalog, offline discovery mechanism, or proof of completed commerce. A visible form or tool still needs bounded inputs, safe failure, and user review.
Handoff 4: Checkout and order systems make binding decisions
UCP Checkout owns session status, fulfillment, payment handling, totals, and completion. Some paths require buyer input or review; the agent must surface those states. An order exists only when the authoritative system returns confirmation.
- Present the exact item and current conditions.
- Explain material disclosures and unresolved uncertainty.
- Ask the user to confirm the consequential action.
- Submit through the authorized system.
- Report its result without upgrading an error or pending state to success.
Expected behavior when a handoff fails
| Failure | Correct response |
|---|---|
| Variant mismatch | Stop; ask for disambiguation |
| Live price unavailable | Mark unknown; do not use stale prose |
| Tool lacks authorization | Request the proper handoff; do not retry blindly |
| User declines | End without side effects |
| Checkout requires review | Open the trusted review path |
| Order result uncertain | Report pending or unknown, never completed |
Further reading
Review stable product knowledge vs live commerce data and ProductGroup, Variant, SKU, and GTIN before implementing the loop.