The Agentic Commerce Readiness Stack: From Product Discovery to Authorized Action

Agentic commerce has two separate readiness questions. Can an agent find and interpret a product for a defined need? And, if a person delegates a purchase, what may the agent inspect, prepare, or change, under whose authority?

A complete product feed can help with the first question. A protocol profile can describe a merchant’s capabilities. Neither proves that a shopping agent will select the product, and neither authorizes a purchase. Readiness therefore needs evidence about product representation and controls for agent actions. It is not a single score.

The two questions belong to one system:

Product evidence
  -> controlled interpretation test
  -> reviewed learning and revised representation
  -> a supported commerce capability
  -> an authorised action
  -> verification of the result

Learning connects product representation to action readiness; the result of a later action can send the team back to a product fact, test, or policy. This is a map of responsibilities, not a requirement to implement every stage before improving a feed. The practical starting point is one shopping need and one product path that can be understood, tested, and, where appropriate, used within verified authority.

Product pages and machine-readable commerce

Product pages still matter to people. They also sit beside other information that an agent may use: product feeds, structured data, merchant profiles, availability services, reviews, and checkout endpoints. These sources can make product facts easier to retrieve and compare. They do not guarantee that a particular agent can access them or will prefer the product.

Consider a request for a waterproof running jacket under £150, available before Friday, from a merchant with a clear returns policy. Those are stated requirements. The agent may infer other preferences, but should keep them separate from what the shopper actually supplied. A useful product record needs more than a persuasive description. It needs a stable item and variant identifier, current price and availability, delivery terms, evidence for the product claims, and a route for checking the merchant’s policy. Each fact should have a source and a time, because stock, price, and delivery promises change.

A browser can still be the route to a product or checkout. Structured feeds and protocols provide other routes that may be easier to parse and validate. They are integration options, not proof that commerce has moved away from the web page.

Two kinds of readiness

The first kind is discoverability: can an agent find a product, interpret its attributes against a shopper’s constraints, and explain why it is a candidate? The second is action control: can the agent inspect or change commercial state within authority granted for this task?

Question	What readiness means	Evidence to collect
Discoverability	Product information is current, consistent, and accessible in a named channel or test environment	Feed and schema checks; dated observations from the target surface; product, query, provider, and version records
Action control	An identified agent can perform only the permitted action, and the result can be checked	Principal and scope; policy decision; approval or mandate; idempotency key; action receipt; readback from the system of record

The two tests can produce different answers. A product may be perfectly legible in a feed while the merchant has no approved checkout integration. A checkout can be safe and functional while the product never appears in the agent’s results. Passing either test says nothing by itself about the other.

This distinction also changes how teams should use the word visibility. A model in a test harness selecting a product is evidence about that test. It is not evidence that Google, ChatGPT, or another shopping surface recommends the product to customers. That requires observations from the named surface or from an authorized integration, and commercial impact requires separate outcome measurement.

Simulation can guide a test, not prove visibility

A useful learning loop is:

state a product hypothesis
  -> run a defined test
  -> inspect the evidence
  -> revise the product representation
  -> test again
  -> compare with observed surface or business outcomes

A simulation can help identify unclear claims, missing attributes, or conflicts between a product description and a structured feed. Before a run, record the product and variant set, user-intent cases, provider and model version, feed snapshot, language, market, date, and evaluation rule. If the setup changes between runs, record that too.

Seven selections of the jacket in ten synthetic runs, followed by five in ten, do not establish a change in real-world visibility. The model, prompts, sampling, competitors, or catalog may have changed, and similar runs may be dependent. Building to Learn explains how constructing a lab exposed that measurement gap. Here the result guides which product facts or test conditions to investigate next.

Technical note: uncertainty within a benchmark

Bayesian updating can help track a narrowly defined test result, provided the estimate is not relabelled as market probability. For example, define success as a particular product appearing in the top three for a fixed set of synthetic prompts on one named model and catalog snapshot. Let θ represent the success rate on that benchmark. A Beta(a, b) prior describes uncertainty before these trials: a and b are positive parameters that act like prior success and failure counts in the update. Choosing a = b = 1 gives a uniform starting distribution. Record that choice rather than hiding a favourable assumption in the prior. After observing w successes among n trials, the simple beta-binomial update is:

posterior: Beta(a + w, b + n - w)

That posterior describes the benchmark as defined. It does not estimate the chance that a customer will see, trust, or buy the product on a commercial platform. The simple model also assumes trials are comparable; prompts and generations that share inputs may require paired or grouped analysis.

Carry the finding into the next test

Keep raw outputs linked to the interpretation: hypothesis, scope, product snapshot, model/version, cases, evaluation rule, result, reviewer, date, and review or expiry conditions. Label findings synthetic, observed on a target surface, or measured in production. Memory & Agency explains the conditions for reuse and revision. For commerce, price and stock need fresh checks rather than durable brand beliefs. Memory resumes the investigation; it does not strengthen the original evidence.

Protocols have different jobs

MCP, commerce protocols, and payment authorization are related, but they do not solve the same problem.

Standard or system	Role	What it does not establish by itself
MCP	Connects AI applications to external systems, including data and tools	That a tool call is safe, that a user authorized a purchase, or that a merchant supports a commerce flow
UCP	An open commerce standard with modular capabilities; Google implements a supported subset on its surfaces	That every capability in the standard is supported by a particular partner, or that a product will rank
ACP	An open commerce protocol used for catalog and checkout integration with ChatGPT	Broad partner availability, enabled checkout, or proof that a feed is surfaced to shoppers
AP2	Defines mandates and receipts for securing agent-performed payments	Catalog discovery or checkout APIs; those sit in a commerce protocol

As of 21 October 2026, Google’s UCP documentation describes a merchant profile that publishes protocol versions, capabilities, and endpoints. The profile and the Google surface negotiate capabilities, and Google’s integration guide says that not every feature in the evolving UCP standard is available on its surfaces. Keep the open UCP standard distinct from this Google implementation. A profile helps an integration negotiate capabilities; it is not a universal discovery guarantee.

OpenAI’s commerce documentation describes ACP as the connection between merchants and ChatGPT. Its current onboarding guide says product-feed onboarding is available to approved partners, and its checkout specification says Instant Checkout is available to approved partners. The integration path can be documented while access to the live product remains limited.

The AP2 specification identifies itself as version 0.2. It describes checkout and payment mandates and receipts, and places those functions inside a commerce protocol. Its scope is authority and payment evidence, not product catalog APIs. MCP is a general connection protocol for tools and information, as its overview describes. If an MCP tool can reserve inventory or submit a purchase, the tool still needs its own identity, policy, and effect controls.

For a merchant, the practical question is which user journey and partner to support, and which exact capabilities that integration provides. Check the current version, partner eligibility, and surface-specific support before making a capability claim.

Delegation does not transfer every commercial role to the agent. Google’s UCP FAQ describes the merchant remaining merchant of record, with its customer relationship and data. A platform can coordinate discovery or checkout while the merchant retains transaction, fulfilment, and service responsibilities. The agent-owned-web essay examines this separation between control of the task and the supplier’s continuing role.

The control plane governs actions

A control plane is the policy and recordkeeping layer between agents and commerce systems. It answers four concrete questions: who is acting, what authority they have, what effect an operation can cause, and how the result will be verified.

An authenticated agent identity is not the same as permission to act for a person. A delegated grant should be limited to a purpose, resource, set of operations, and time window. For example, permission to read a public product catalog does not imply permission to read a loyalty account, reserve stock, or pay. A signed mandate can provide evidence of user intent for a particular purchase, but the merchant and payment parties still have verification duties.

Start with named capabilities, each with a defined input, output, scope, and effect. Then classify an operation by what it changes, not by its endpoint name:

Effect	Example	Appropriate control
Public read	Search catalog or inspect a public policy	Rate limits, provenance, and current source data
Private read	Retrieve loyalty or account information	User-authorized, narrowly scoped access and access logs
Internal draft	Prepare revised product copy or a cart draft that is not submitted	Draft identifier, review status, and a clear no-submit boundary
External change	Reserve inventory, apply an offer, or create a session that changes merchant state	Explicit authority, policy check, idempotency, approval where required, receipt, and readback
Payment	Submit or authorize a charge	Verified payment mandate, scoped credential, transaction binding, receipt, and reconciliation

A cart draft and a reservation are different. A draft can remain inside the agent’s workspace. A reservation may hold inventory for other customers, start a timer, or create an external record. Some checkout-session APIs also have side effects. Inspect the implementation and classify the actual state change before assigning an action to a risk tier.

A controlled flow can look like this:

authenticated agent
  -> read product by stable ID
  -> prepare an internal cart draft
  -> show the exact items, price, delivery, and terms
  -> check policy and delegated authority
  -> request approval or verify a mandate
  -> submit the authorized action once
  -> record the service receipt
  -> read the order or reservation back from its system of record
  -> reconcile expected and observed state

The receipt and the readback answer different questions. A receipt records what the service says it processed. A readback checks what state exists afterward. A successful HTTP response is not enough to prove that the intended order or reservation exists, and a receipt does not make an external action reversible.

A schematic receipt for an inventory reservation might include:

{
  "action": "reserve_inventory",
  "actor": "external_agent_1",
  "product_id": "sku_12345",
  "effect": "external_state_change",
  "idempotency_key": "task-789-reservation-1",
  "authority_ref": "approval-456",
  "policy_result": "allowed",
  "request_hash": "...",
  "service_result": {
    "status": "accepted",
    "reservation_id": "reservation_abc"
  },
  "readback": {
    "status": "confirmed",
    "source": "merchant_inventory_api",
    "observed_at": "..."
  }
}

This is an application design example, not a protocol schema. If a request times out, do not assume it failed and blindly retry. Query by the idempotency key or service reference, read the current state, and decide whether to resume, compensate, or ask a person. The recovery path depends on the action; not every effect can be rolled back.

Begin with read-only discovery

The first useful integration is often one that changes nothing. Let an agent inspect a product, variant, price, availability, return policy, merchant profile, or protocol capability. Keep the returned information tied to its source, version, and retrieval time.

A product payload may include a stable merchant ID and the fields supported by the target feed. Provenance around that payload can record where it came from, which protocol or snapshot supplied it, when it was retrieved, and whether the value was confirmed or inferred. Keep that provenance wrapper separate from any protocol-defined schema. Do not add an invented field and imply that a platform consumes it.

Read-only discovery is useful to both marketing and engineering. Marketing can see whether the product’s attributes and proof match the intent being tested. Engineering can verify that a product selected for a later action is the same product returned by the read path. Resolve the stable product ID again before changing state; do not reconstruct it from a title, screenshot, or generated summary.

Treat checkout as a boundary

A readiness check can report that a specific merchant, product, and integration support a given checkout capability. It should not start checkout, reserve stock, or imply that a payment is approved. Keep the distinction visible in both the tool name and its result.

For commerce teams, useful checks include whether the profile is reachable, which versions and capabilities it declares, whether required fields are current, and which partner surface supports the chosen path. For an action, confirm the exact cart, price, fulfillment terms, payment method, and authority before submission.

The operating sequence is discovery, readiness check, draft preparation, explicit approval, and controlled execution. A merchant may stop at any point and offer the customer a conventional checkout instead.

Give agents their own scoped identity

Agents should not inherit a person’s entire merchant or customer session. Give each agent or job an authenticated identity, then grant only the access needed for that task. Credentials should be revocable and short-lived where practical. Record who delegated the authority, which resource it covers, what operation is permitted, and when the grant expires.

A schematic grant might look like this:

principal_type: external_agent
principal_id: buyer-assistant-v1
delegated_by: user_789
resource: sku_12345
scopes:
  - catalog:read
  - protocol.readiness:read
  - checkout:prepare
expires_at: 2026-10-21T11:00:00Z

This grant permits preparation, not purchase. If a purchase is later authorized, bind that authority to the actual checkout details and have the relevant parties verify it. Identity proves which agent is making a request; policy and mandate verification determine what the request may do.

Record the effect and verify the state

For every consequential state change, retain enough information to connect the actor, authority, request, policy decision, service response, and resulting object. Use an idempotency key for retries. Record failures and unknown outcomes as first-class states so operators can distinguish “not attempted,” “rejected,” “accepted,” and “still needs reconciliation.”

After the service responds, read the resulting order, reservation, or account state from its authoritative source. Compare it with the requested action. If it differs, stop and route the discrepancy for recovery. A second agent should not repeat an uncertain action because the first agent’s screen looks incomplete.

How the commerce lab represents this design

The public agentic commerce lab repository describes a supervised agent workspace: the agent suggests, a person reviews and approves, and the system monitors the outcome. Its README distinguishes synthetic validation from observed outcomes and says lab scores do not guarantee production ranking results.

Building to Learn supplies the historical three-week prototype account. No pinned February version accompanies that account, so the public project’s documentation cannot establish which controls were implemented then. Its synthetic tests, later surface observations, and any commercial outcomes require separate records.

The repository describes control-plane patterns for keeping discovery, policy, approval, execution, and audit in separate records. It is an experimental architecture, distinct from the page-level Conversion Lab demo discussed in the agent-owned-web essay. A documented mechanism, a working integration, and measured commercial improvement require different evidence.

What commerce marketers can do now

Start with one product family and one real shopping need. Check that the product record, variants, price, availability, delivery, returns, promotions, and evidence agree across the merchant’s page and feeds. Keep eligibility rules for offers machine-readable, and make trust signals such as certifications, reviews, support channels, and return terms current. State which agent or surface is being tested and which facts it can access.

Make the brand’s claims part of that record, rather than leaving them only in prose guidelines. A practical claim register can hold:

• The approved term, product or variant, and factual claim.
• The differentiator or capability it describes and the shopping requirement it may serve.
• Its supporting source, test conditions, limitations, and review date.
• The price, promotion, or eligibility conditions that affect the offer.
• Where the claim may be used and who can approve a revision.

For the jacket, “waterproof” needs its own substantiation and limitations. Stock availability does not prove delivery before Friday. A feed, comparison answer, and ad can use the same evidence while making different claims. Keep their identifiers and source records connected without implying that a platform accepts every field in this internal register.

Then keep three kinds of result separate:

1. Data quality: required fields are present, current, and consistent.
2. Agent interpretation: a named test environment handles a defined set of needs as expected.
3. Customer or business outcome: observed qualified visits, completed purchases, successful use, returns, or retained value. A claim that a change improved these outcomes requires a credible causal comparison.

Do not report the second as the third. If the target surface does not expose observations or outcome data, report the limitation and use the test only to improve the product representation or integration readiness.

For measurement, preserve product and offer IDs across agent-mediated events where the integration permits it. Record qualified visits, conversion, returns, and retained value against a defined denominator. A change in a synthetic test is a reason to investigate, not evidence that the change caused a commercial result.

What commerce engineers should build

Expose small capabilities with clear boundaries. A first read-only set might include catalog.search, product.read, price.read, availability.read, policy.read, and protocol.profile.inspect. A preparation set might include cart.prepare and checkout.readiness.check, with outputs that cannot be mistaken for an order or reservation. Add state-changing actions only after the merchant can verify identity, authority, idempotency, effect, receipt, and readback.

Keep stable identifiers across product, variant, intent, test, cart, checkout, and order records. Snapshot the inputs used for a comparison so a later test can distinguish a product change from a feed, prompt, provider, or model change. Make read and write scopes explicit. Give private customer data its own authorization and retention rules.

For each action, document the expected effect, failure states, retry behavior, approval point, authoritative readback, and recovery path. Keep immutable action records, policy preflight, approval gates, and circuit breakers for repeated failures or suspicious activity. If an operation can change shared stock, charge a customer, send a message, or create a lasting record, include that effect in preflight and the approval display.

Useful jobs before autonomous checkout

The same architecture supports several bounded applications. Choose one because it answers a real question, then define its input, result, and verification:

Job	Input and useful result	Evidence to check	Effect boundary
Product discoverability audit	A catalog slice and shopping requirements produce a list of missing or ambiguous claims	Source facts, actual feed/schema checks, and dated observations from the named surface	Read and report; propose copy changes separately
Intent simulation and reviewed learning	Frozen products and test cases produce comparisons, hypotheses, and a scoped memory update	Raw outputs, evaluation rules, uncertainty, and synthetic/observed status	Run tests; save a reviewed interpretation, without publishing product copy
Protocol audit and discovery dashboard	Merchant profiles and endpoint responses produce a capability/remediation view	Retrieved version, reachable capability, partner support, and retrieval time	Inspect readiness without creating a checkout session
Offer and price watch	Permitted price, stock, and offer records produce alerts	Fresh source data, consistent product/offer IDs, and eligibility conditions	Read or recommend; no automatic price or campaign change
Controlled cart preparation	Selected product IDs and constraints produce an internal draft for review	Current price, delivery, terms, and exact targets	Prepare; treat reservations, submitted sessions, and payment as separate effects
Agent traffic and identity review	Request and authentication records produce an abuse or integration finding	Verified identity where available, rate patterns, and access scope	Observe; changes to access policy require their own authorised workflow

An agent label or user-agent string alone is not proof of identity or permission. A readiness dashboard should show the evidence behind each finding and whether a source was live or a fallback. A missing observation remains unknown; it should not be filled by a model’s confident explanation.

A practical adoption sequence

1. Make one catalog slice reliable. Reconcile product IDs, variants, price, availability, fulfillment, return terms, and evidence across systems.
2. Test one defined intent set. Freeze the data and test configuration. Label results synthetic unless they come from the target shopping surface.
3. Compare a proposed change with evidence. Repeat the same cases where possible, inspect raw outputs, and use observed or controlled business outcomes for claims about real-world lift.
4. Add memory with provenance. Store findings with scope, source type, version, date, and review or expiry rules.
5. Choose one supported commerce integration. Confirm current partner access and capability support, then implement its exact version and contract.
6. Keep the first action bounded. Prepare a draft, show the exact effect, verify authority, and require approval before a reservation, order, or payment. Log the receipt and read the resulting state.

An audit can report these checks and their evidence without collapsing them into a universal “readiness score.” Prioritise gaps by their effect on the chosen user journey.

An evidenced path to the next action

For the jacket request, a useful readiness result says which variant meets the stated requirements, where each fact came from, what the test environment actually observed, and which supported operation can happen next. If delivery remains uncertain or checkout authority is absent, the result should make that gap clear and offer an appropriate handoff.

The Map That Talks Back extends this path to a physical visit. Place records, route estimates, booking status and the venue’s actual service must agree closely enough for the recommendation to work on arrival. A confirmed action still leaves the experience to be delivered.

For the merchant, the deliverable is an integration and action plan backed by evidence: product gaps to repair, test conditions to preserve, capabilities to support, and effects that remain out of scope. It lets marketing and engineering improve the same customer path without confusing a synthetic selection, a protocol declaration, and a completed order.

Readiness makes participation possible. Whether that participation creates an advantage competitors cannot readily copy is the next question. Distribution Alone Is Not a Moat connects these capabilities to growth, retained value, and defensibility.

Reference Reading

Protocol and platform documentation

• Universal Commerce Protocol, the open standard, and Google’s integration guide, for its supported implementation.
• Google UCP FAQ, including the merchant-of-record model.
• Google UCP profile and version documentation
• OpenAI Agentic Commerce Protocol
• OpenAI product feed onboarding
• OpenAI Agentic Checkout specification
• Google Agent Payments Protocol, version 0.2
• Model Context Protocol overview

Worked example and related reading

• Agentic Commerce Control Plane repository
• Memory & Agency: What Should an Agent Remember?, on preserving evidence and revising lessons.
• The Geometry of Intention
• The Anatomy of a Marketing Agent
• The Muscles of the Machine
• Secure Marketing Agents