merx

A WORKING DESIGN PROPOSAL

Product feeds that answer a decision.

AI shopping agents still need product data. What changes is how much they need, when they need it and what they must verify before buying.

Do agents need an XML product feed?

A bulk product feed is useful for indexing, comparison and offline processing. XML is capable of representing rich data; simply switching to JSON does not make a catalog agent-ready. A buying agent also needs current availability, evidence behind claims, explicit limitations and the next valid step.

Merx proposes using two complementary interfaces: a signed catalog snapshot for indexing and an intent-specific Capability Feed for decision-making. Existing exports can remain in place for channels that need them.

Ask for a fit, receive the evidence

Consider: “Find low-acidity coffee for espresso, deliverable to Slovakia within five days.” Instead of receiving every product in the store, the agent gets a signed packet containing ranked candidates, reasons, suitability warnings and rejected products with explanations.

MERX CAPABILITY FEED 0.1

  1. Facts: identity, attributes, provenance and declared limitations.
  2. Decision: why the product fits this specific request.
  3. Offer: current indicative price and available quantity.
  4. Action: the inputs needed to negotiate or create a quote.

Cache facts. Refresh the offer.

A product's dimensions may stay the same while stock changes every minute. Capability Feed hashes the stable public facts separately. An agent can submit previously verified hashes; unchanged facts are omitted while a new offer snapshot is returned.

The packet signature binds its contents and request hash. An agent must verify the merchant key and signature, resolve cached facts and request a fresh signed quote before ordering. Discovery does not reserve inventory, and a signature does not make an unverified claim true.

Try it with the actual engine

git clone https://github.com/kamilkubik89/merx.git
cd merx
npm run demo:feed

Requires Node.js 22.6+. The demo creates a signed packet, verifies it and shows a cache-aware refresh. The same operation is available through REST at POST /v1/discover and as discover_offers over MCP and A2A.

What is implemented, and what is next?

Signed packets, request binding, cached product facts, indicative offers, payment-provider discovery and next-action hints are implemented. Matching is lexical, evidence references are not independently verified, and storage is in memory.

Signed change streams, evidence revocation, compatibility graphs, selective disclosure and cross-store comparison are future design directions. Merx Capability Feed is an experimental project format, not a universal industry standard.

An additive migration path

Keep your current XML exports, map known catalog fields into structured facts and add provenance where available. Preserve missing values as unknown. Introduce intent-based discovery alongside existing channels, then evaluate it using actual agent requests. Merx currently reads catalog JSON; a general XML importer is not bundled.

For context, see the Google Merchant product data specification, UCP for commerce interoperability and AP2 for authorization. The Merx proposal focuses on the connection between product evidence and an agent's next decision.