What “Agentic Commerce” Means for Product Feeds

Agentic commerce makes product feeds part of a purchasing decision, with consequences beyond winning a click. When a shopper asks for a particular size, delivery by Friday, and easy returns, the useful answer depends on whether those conditions hold together for one purchasable item.

The practical priority for merchants is to make every recommendation survive contact with checkout. Richer descriptions help explain a product; accurate inventory, fulfillment, and policy data determine whether the offer works for the buyer.

What Google Announced—and What Merchants Can Use

In its January 11, 2026 announcement, Google described agentic commerce as AI performing tasks for people. It introduced the Universal Commerce Protocol (UCP), outlined checkout on eligible AI shopping surfaces, launched Business Agent for brand conversations on Search, and announced additional Merchant Center attributes. It also introduced Direct Offers as a Google Ads pilot for presenting offers in AI Mode. Those initiatives span discovery, transactions, and advertising; they have different integration and eligibility considerations. (Google’s agentic-commerce announcement)

The feed work is now more concrete than the original announcement. Google’s published conversational-attribute guidance lists six optional fields: question_and_answer, document_link, related_product, item_group_title, variant_option, and popularity_rank. They supplement existing product data and can be submitted through a supplemental source, the primary source, or the Merchant API. Google recommends a supplemental source and says there is no need to repeat details already provided in descriptions, highlights, or product details. (How to use conversational attributes)

Our operational recommendation: audit the facts that can break a purchase first, then add information that helps shoppers distinguish suitable products. Submitting richer attributes should not be treated as proof of checkout eligibility or guaranteed placement.

The Feed-Readiness Checklist

1. Variants: Can the shopper buy the exact recommendation?

Give each sellable variant a distinct id, and use item_group_id to connect genuine variants. Include the attributes that distinguish them and a landing URL that selects the intended configuration. Google explicitly separates item identity from variant grouping and calls for distinct variant URLs. (Item group ID specification)

Acceptance check: Open the feed link for a blue, medium shirt in a fresh browser session. Confirm that blue and medium are selected, the image is appropriate, and adding it to the cart preserves both choices. Repeat with an unavailable size. A product-family page that silently defaults to a different variant fails this check even if the family name is correct.

2. Product identifiers: Is this the same item across systems?

Keep the distinction between your merchant identifier and the manufacturer’s product identity. A SKU can identify your catalog record; it is not a substitute for a GTIN. Use the assigned GTIN for the exact product, including its variant. Do not invent a barcode for an item without one; follow Google’s applicable brand and MPN guidance instead. Bundles and multipacks need particular care because manufacturer-created and merchant-created packages have different identifier rules. (GTIN specification)

Acceptance check: Sample identifiers against packaging or supplier records. Include a single unit, a multipack, and two variants. Flag cases where a family-level barcode has been copied across different sellable items. Give supplier-data exceptions an owner rather than filling gaps with plausible numbers.

3. Availability and price: Does the offer still exist?

Match availability and price across the feed, visible product page, structured data, and checkout. Google supports distinct availability values for in-stock, out-of-stock, preorder, and backorder products. Use the corresponding date information where required. For temporary markdowns, maintain sale_price and sale_price_effective_date alongside the regular price. (Product data specification)

Acceptance check: Trace a stock change and a scheduled sale through every destination. Record when the commerce system changed, when the feed was submitted, and when Merchant Center reflected it. Set an internal freshness target based on how quickly the item sells. An hourly bestseller and a made-to-order table should not share an unquestioned daily update policy.

Include failed updates in the audit. A successful export does not establish that the receiving system processed the latest value.

4. Pickup: Which store can fulfill the promise?

Local inventory joins a product id to a store_code. Those values must match the primary product data and the linked Business Profile respectively. Maintain store-specific availability and pickup_sla where relevant to your pickup setup. Google requires the pickup timeline to agree with the landing page and checkout; store inventory values override product-level pickup values for the associated store. pickup_method is optional under the current specification. (Local inventory data specification)

Acceptance check: Test one item at two stores with different stock positions. Distinguish stock already on the shelf from stock that must be transferred. Check an order placed after the pickup cutoff. A warehouse unit should not become a same-day store promise simply because the online catalog says it is available.

5. Delivery: Can the promised date be calculated?

Review destinations, charges, handling time, transit time, and cutoff assumptions in Merchant Center’s shipping configuration. Use product-level shipping data for applicable exceptions. Google’s specification distinguishes handling from transit and explains how product-level shipping overrides account settings. An override containing a shipping price can also displace account-level delivery times and minimum order values for that product and location. (Shipping specification)

Acceptance check: Quote the same item to a nearby postcode, a distant destination, and an excluded area. Repeat before and after the order cutoff. Compare the resulting cost and delivery estimate with checkout. Pay special attention to oversized products and free-shipping thresholds: the default parcel service may describe neither correctly.

6. Returns: Does the policy apply to this item?

Configure the standard return policy and map exceptions through return_policy_label. Google supports exception policies for products with different windows or no returns, alongside information such as return methods and restocking fees. A store-wide policy does not describe every item automatically. (Set up return policies)

Acceptance check: Choose an ordinary item, a final-sale item, and a product with a shorter return window. Compare the assigned policy with the website and customer-service instructions. Verify who pays return shipping and whether a fee applies. “Easy returns” should not conceal an exception that would change the buyer’s choice.

7. Promotions: Can an eligible customer redeem the offer?

Maintain promotions as structured, time-bounded records. For product-specific offers, map promotion_id to the eligible products and maintain the promotion’s effective dates, redemption requirements, and channel. Google’s promotions specification describes these separately from ordinary product data. (Promotions data specification)

Acceptance check: Test an eligible item and an excluded item, with and without any required code. Check minimum spend, start and end times, and whether pickup orders qualify. Assign responsibility for removing expired offers from every publishing destination.

Keep the integration decision separate: the January announcement described Direct Offers through Google Ads campaign settings. An ordinary Merchant Center promotion is not evidence that an advertiser is participating in that initiative.

Add Conversational Detail Where It Resolves Uncertainty

Once those checks pass, use the optional fields to answer questions the basic record leaves open:

These field purposes follow Google’s conversational-attribute guidance. The questions above are suggested audit prompts, not sample claims to copy into a catalog.

Start with recurring presale questions and return reasons. If customers repeatedly buy the wrong replacement filter, fixing compatibility information has a clearer purpose than generating hundreds of generic FAQs. Keep an internal record of the evidence, owner, and review date for each answer. When a supplier revises a model, that record tells the team what needs checking.

Run a Small Audit Before Expanding

Begin with 20 representative products: bestsellers, products with frequent stock changes, a variant family, a pickup item, a bulky shipment, a return exception, and a promotion. Treat this as an internal operating sample, not a Google requirement.

For each, record the expected buying conditions, the values Merchant Center actually processed, the customer-facing result, and any discrepancy. Assign fixes to the system that owns the fact: catalog management for specifications, inventory operations for stock, fulfillment for delivery, and merchandising for offers.

Track three outcomes: the share of sampled offers that agree end to end, the time changes take to propagate, and cancellations or support contacts caused by inaccurate information. Expand the audit after the recurring failures have owners and fixes.

A useful definition of feed readiness is simple: the exact product, offer, and fulfillment conditions remain consistent from a shopper’s question through the completed order. Conversational attributes can make that product easier to understand. The underlying records have to make it possible to buy.