Agent-Optimised Catalogue Feed

1.Abstract

The Google Merchant Center XML feed has been the de facto standard for declaring product catalogues to search engines for over a decade. It was designed for a world in which the consumer was a human and the intermediary was a search result. Agentic commerce inverts that assumption. A consumer instructs an AI agent in natural language. The agent reads the catalogue, decides what to buy, and pays without human intervention. The GMC feed contains almost none of the information the agent needs to make that decision safely.

This document specifies a small set of optional extensions to the GMC feed and to the schema.org Product type. Together they declare, per product: whether an agent is permitted to purchase the item without human approval, which agent payment protocols the merchant accepts for it, whether it is eligible for spending mandates, what its replenishment terms are, and which products may substitute for it if it is unavailable. The extensions are namespaced under x-agent-* to coexist with the existing feed format and require no changes to merchant infrastructure beyond adding the fields.

2.Motivation

An AI shopping agent presented with a typical product feed today has three serious problems. First, it cannot tell whether a product is purchasable by an agent at all. The catalogue contains B2B SKUs, prescription items, made-to-order pieces, and subscription-only products. None carry a flag distinguishing them from items a consumer agent can buy outright. The agent learns this only by attempting checkout and failing.

Second, it cannot tell which payment rails the merchant accepts. The agent may carry a Mastercard Agentic Token, a stablecoin wallet, a Skyfire KYA-PAY credential, or no payment instrument at all. The catalogue is silent on what each product accepts. The agent must speculatively probe the checkout to find out.

Third, it cannot tell whether the merchant honours spending mandates. These are the AP2-style consumer pre-authorisations that let an agent transact within a defined limit without the consumer approving each purchase. Without this signal, every agent purchase requires a human in the loop, which defeats the purpose of agentic commerce.

These three gaps explain why the visible failure mode of agentic commerce in 2026 is not technical but contractual. Agents can find products. They cannot tell which ones they are allowed to buy.

3.Relationship to prior work

AOCF does not replace existing catalogue and protocol work. It assembles signals around a gap that nothing currently fills.

3.1.Google Merchant Center feed

The GMC feed is the foundation. Most merchants already publish one. AOCF treats it as the carrier and adds optional g:x-agent-* elements alongside the existing fields. A merchant adopting AOCF does not have to publish a second feed and a merchant who has not adopted AOCF still produces a valid GMC document.

3.2.OpenAI Agentic Commerce Protocol (ACP)

OpenAI's ACP defines a feed format optimised for product selection inside ChatGPT shopping: identifiers, titles, descriptions, prices, inventory counts, shipping options, ratings, optional variants and categories. Its purpose is to help an agent find the right product. It does not declare per-product purchase permissions, payment method routing, mandate eligibility, or substitutes. AOCF and ACP target different stages of the agent journey. A merchant can ship both, and the data overlaps cleanly: ACP fields cover discovery, AOCF fields cover purchase.

3.3.Managed agent feed services

Services such as Feedonomics ACE syndicate merchant catalogues to multiple agent-facing surfaces (ChatGPT, Gemini, Copilot, PayPal, Stripe, Perplexity, Amazon). They handle the integration plumbing for merchants who would rather not publish to each surface directly. Such services route catalogues to the protocols those surfaces define. AOCF is upstream of that work: it is what the merchant publishes once, in a standard form, that any service or agent can read. A managed feed service can ingest an AOCF document and transform it for each downstream destination.

3.4.schema.org Product

schema.org defines structured product data for human-facing search and rich results. It does not declare agent-specific purchase semantics. AOCF's JSON-LD binding (Section 7) extends Product with x-agent-* properties that current schema.org validators ignore, preserving compatibility with existing rich-results indexing.

3.5.Where AOCF fits

The agent commerce stack today resolves the layers above and below AOCF, not the layer it occupies. Below: payment protocols (ACP, MPP, x402, AP2, KYA-PAY) define how to settle a transaction once the agent has decided to attempt one. Above: feed delivery services (Feedonomics ACE) and discovery formats (OpenAI ACP) determine how the catalogue reaches the agent in the first place. The gap is in the middle: per-product, machine-readable declarations of what the agent is permitted to do with each item. That is the layer AOCF specifies.

4.Scope and terminology

This document defines field names, value spaces, and validation rules for declaring agent-purchase terms in three serialisations: the Google Merchant Center XML feed, the schema.org JSON-LD Product type, and the OpenAPI 3.x specification used by checkout APIs. It does not define a new transport, a new authentication scheme, or a new payment protocol. It assembles signals that other specifications already define and makes them addressable per product.

The key words MUST, SHOULD, MAY, REQUIRED, and OPTIONAL in this document are to be interpreted as described in RFC 2119.

4.1.Roles

• Merchant. Operates a product catalogue and one or more checkout endpoints. Publishes an AOCF feed.
• Agent. Software acting on behalf of a consumer. Reads the AOCF feed before attempting checkout. May be operated by an LLM provider, a wallet vendor, or a merchant-of-merchants intermediary.
• Consumer. The human on whose behalf the agent acts. Issues spending mandates, approves out-of-mandate purchases.

4.2.Conformance levels

An AOCF feed is conformant at one of three levels:

• Level 1 — Declaration. Includes x-agent-purchasable on every product entry. This alone is enough for an agent to decide whether to attempt a purchase.
• Level 2 — Routing. Adds x-agent-protocols and optionally x-agent-instruments. The agent knows which execution rails the merchant supports and which payment instruments travel over them.
• Level 3 — Mandate. Adds x-agent-mandate-eligible and, where relevant, x-agent-replenishment. The agent can transact under pre-authorised consumer mandates without per-purchase approval.

5.The extension fields

"x-agent-replenishment": {
  "interval": "P30D",
  "locked-price": true,
  "cancel-anytime": true
}

6.Example feed

A complete Level 3 conformant product entry in GMC XML format. The standard GMC fields are unchanged. The AOCF extensions are added in the g: namespace alongside them.

<item>
  <g:id>SKU-12345</g:id>
  <g:title>Aurora Cleansing Balm 100ml</g:title>
  <g:description>A gentle cleansing balm for normal to dry skin...</g:description>
  <g:price>28.00 GBP</g:price>
  <g:availability>in stock</g:availability>
  <g:gtin>5012345678901</g:gtin>
  <g:brand>Aurora</g:brand>

  <!-- AOCF Level 1 -->
  <g:x-agent-purchasable>true</g:x-agent-purchasable>

  <!-- AOCF Level 2 -->
  <g:x-agent-protocols>
    <g:protocol>mpp</g:protocol>
    <g:protocol>mastercard-agent</g:protocol>
    <g:protocol>ap2</g:protocol>
  </g:x-agent-protocols>
  <!-- x-agent-instruments omitted: all standard cards accepted -->

  <!-- AOCF Level 3 -->
  <g:x-agent-mandate-eligible>true</g:x-agent-mandate-eligible>
  <g:x-agent-spending-cap>32.00 GBP</g:x-agent-spending-cap>
  <g:x-agent-replenishment>
    <g:interval>P60D</g:interval>
    <g:locked-price>true</g:locked-price>
    <g:cancel-anytime>true</g:cancel-anytime>
  </g:x-agent-replenishment>
  <g:x-agent-substitutes>
    <g:sub>SKU-12346</g:sub>
    <g:sub>SKU-12347</g:sub>
  </g:x-agent-substitutes>
  <g:x-agent-token-budget>420</g:x-agent-token-budget>
</item>

7.JSON-LD binding

The same fields MAY be expressed as schema.org Product extensions in JSON-LD on a product page. This permits agents to consume AOCF data without ever fetching the feed file.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Aurora Cleansing Balm 100ml",
  "sku": "SKU-12345",
  "gtin13": "5012345678901",
  "brand": { "@type": "Brand", "name": "Aurora" },
  "offers": {
    "@type": "Offer",
    "price": "28.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock"
  },
  "x-agent-purchasable": "true",
  "x-agent-protocols": ["mpp", "mastercard-agent", "ap2"],
  "x-agent-mandate-eligible": true,
  "x-agent-spending-cap": "32.00 GBP"
}
</script>

The x-agent-* properties are unrecognised by current schema.org validators and will be silently ignored. They do not affect existing rich-results indexing.

8.OpenAPI binding

Merchants who expose a Products API MAY declare AOCF terms in the OpenAPI schema for each product object. This lets agents that prefer API discovery over feed parsing read the same information.

components:
  schemas:
    Product:
      type: object
      properties:
        id: { type: string }
        title: { type: string }
        price:
          type: object
          properties:
            amount: { type: string }
            currency: { type: string }
        x-agent-purchasable:
          type: string
          enum: [true, false, conditional]
        x-agent-protocols:
          type: array
          items: { type: string }
        x-agent-instruments:
          type: array
          items: { type: string }
        x-agent-mandate-eligible:
          type: boolean

9.Validation rules

1. An item with x-agent-purchasable: false MUST NOT declare x-agent-mandate-eligible: true. Validators MUST flag this combination as an error.
2. An item with x-agent-purchasable: conditional MUST include x-agent-conditions with at least one entry.
3. x-agent-spending-cap MUST be greater than or equal to the item's standard price.
4. x-agent-substitutes MUST reference identifiers that resolve to other items in the same feed (or a merchant API endpoint that resolves them).
5. x-agent-replenishment.interval MUST be a valid ISO 8601 duration.
6. x-agent-protocols values are case-sensitive and MUST be drawn from the enumerated list. Unknown values SHOULD be rejected by validators with a warning rather than silently ignored. The same applies to x-agent-instruments when present.
7. x-agent-protocols and x-agent-instruments are independent dimensions. Declaring a protocol does not restrict which instruments travel over it unless x-agent-instruments is also present. Validators MUST NOT infer instrument support from protocol names.

10.Agent behaviour

An AOCF-aware agent SHOULD evaluate the following sequence before attempting any purchase.

1. Read the AOCF declarations for the candidate product.
2. If x-agent-purchasable is false, abandon the purchase silently and consider substitutes if declared.
3. If conditional, verify each entry in x-agent-conditions against the consumer's profile and abandon if any are unsatisfied.
4. Select a protocol from x-agent-protocols in declared order, restricted to protocols the agent supports. If x-agent-instruments is present, confirm the agent's payment instrument is listed before proceeding. If x-agent-instruments is absent, assume all standard card instruments are accepted.
5. If the live price at checkout exceeds x-agent-spending-cap, abort and seek consumer reapproval.
6. If the agent is operating under a consumer mandate and x-agent-mandate-eligible is false, the agent MUST escalate to the consumer for explicit approval rather than completing autonomously.

An agent that ignores AOCF declarations and proceeds to checkout regardless is technically permitted to do so. The merchant's checkout will reject the purchase if it cannot be honoured. But doing this routinely wastes both parties' compute and is unfriendly behaviour. AOCF is the polite path.

11.Security and privacy

AOCF feeds are public. They MUST NOT contain consumer-specific data, mandate identifiers, or merchant-specific authentication tokens. The mandate eligibility flag is a declaration about the merchant's policy, not a credential.

An attacker controlling a merchant's feed could attempt to advertise broader purchasability terms than the merchant's checkout actually honours. This is detectable: agents that complete checkout in violation of declared terms SHOULD log the discrepancy and downgrade their trust score for the merchant. Aggregators publishing AOCF compliance scores SHOULD treat declared-but-not-honoured terms as a compliance failure.

Merchants SHOULD sign their feeds (e.g. via the existing GMC manifest signature mechanisms or via a published /.well-known/aocf-key endpoint) to allow agents to verify integrity. Signature schemes are out of scope for this document.

12.Versioning

The version of this specification an item conforms to MAY be declared via x-agent-spec-version at the feed root or per item. Absence implies 1.0. Future versions MUST NOT repurpose existing field names with incompatible semantics; instead, deprecated fields are retained alongside their replacements for at least one major version.

13.References

• RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
• Google Merchant Center XML feed specification
• OpenAI Agentic Commerce Protocol (ACP)
• Machine Payments Protocol (MPP) — IETF draft-httpauth-payment-00
• Mastercard Agentic Tokens technical documentation
• Visa Intelligent Commerce technical specification
• AP2 Spending Mandate framework