Agent Identity vs Product Identity in Agentic Commerce

Agentic commerce has discovered its first identity problem. Payment networks are building Know Your Agent infrastructure to establish which AI agent is acting, who is accountable for it, and whether it should be trusted to transact. That is necessary. It is also only one side of the transaction.

Once the agent is authenticated, commerce still has to answer: which exact product is this agent about to recommend, price, reorder, substitute, or purchase? Agent identity tells you who is acting. Product identity tells you what they are acting on. Autonomous commerce needs both. Authenticating the actor does not validate the target.

What Know Your Agent actually solves

Ant International, Mastercard, and Visa’s joint Know Your Agent announcement describes collaboration on an interoperable framework for agent identification and trusted transaction execution. KYA concerns the actor: recognizing the agent, connecting it to accountability, supporting verification and onboarding, communicating trust signals, and enabling networks to process authorized actions.

That is an important control layer. It should not be redefined to solve catalog quality, and product identity is not a criticism of KYA. They answer different questions:

• KYA: Which agent is requesting this action, on whose authority, with which credentials?
• Product identity: Which real-world entity, variant, pack, SKU, or offer will the action affect?

The same separation already exists in human commerce. Authenticating a buyer does not prove that a merchant’s two similar item records describe the same product. Confirming a procurement user’s spending authority does not normalize case quantity. Agentic execution makes the distinction more consequential because the actor can move from discovery to transaction without a person noticing an ambiguous target.

Commerce has two identity layers

The primary distinction is simple:

Production commerce then needs a longer chain:

These layers complement rather than compete. AI Agents Need Permission Levels explains what an agent may do. Entity Resolution Is Becoming Infrastructure for AI Agents establishes a stable object for that permission to target. One without the other leaves either the actor or object ambiguous.

An authorized agent can execute perfectly against the wrong SKU

Authorization, policy checks, payment approval, and audit logging can all succeed while the commercial outcome is wrong.

Wrong variant

A procurement agent receives a request for a 230 V motor. It applies the approved-supplier list, spending threshold, lead-time rule, and contract price correctly. The supplier catalog record has been merged with a 110 V variant under the same family description. The agent orders the authorized supplier’s wrong item. Every actor control worked; variant identity failed.

Wrong packaging level

Two offers describe the same manufacturer product. One is priced per unit and one per case of 12, but both expose UOM = EA after a feed mapping. The agent divides price by requested quantity and selects the apparently cheaper offer. The arithmetic and purchasing policy are correct. The pack comparison is false.

Unapproved replacement

An agent is permitted to find alternatives for an out-of-stock component. It retrieves another component with matching headline dimensions and voltage but a different mounting pattern. Similarity is not an approved replaces relationship; a technically plausible recommendation becomes an unusable purchase.

Duplicate merchant listing

A merchant agent is allowed to stage price changes. Sales data attaches to a canonical sellable SKU, but a duplicate supplier listing remains active. The agent stages a markdown against the duplicate, leaving the actual offer unchanged. Write permissions worked. The target record did not.

These are not failures of fluent reasoning. They are failures to bind an authorized action to the correct commercial object. The confidence-threshold playbook can route uncertainty, but its threshold must receive separate identity, evidence, and impact signals rather than a single model score.

Product, SKU, offer, and pack are not the same thing

“Product” often hides several identity levels:

real-world product → family → model → variant → packaging level → sellable SKU → merchant offer

A cordless-drill family may contain models with different torque. One model may have bare-tool and battery-kit variants. A variant may be sold as one unit or a case. A retailer assigns a SKU to each sellable configuration. Multiple merchants—or multiple contracts at one distributor—can publish offers for that SKU with different price, stock, fulfillment, and eligibility.

The action determines the required resolution:

• Exploration: a family-level association may be enough to explain available models.
• Specification filtering: the agent needs model or variant identity so voltage and capacity apply correctly.
• Price comparison: it needs equivalent variant, pack quantity, unit, currency, and commercial scope.
• Cart and purchase: it needs the exact sellable SKU and current merchant offer.
• Catalog write-back: it needs the exact governed target plus expected current state and permission.

The GTIN vs MPN vs SKU comparison separates common identifiers, while Golden Record vs Canonical Record explains why one chosen row is not always enough to preserve these identities and relationships.

Protocols connect agents to commerce; they do not create merchant product truth

Google UCP, OpenAI ACP, and Claude Commerce Agents are different architectural choices. UCP and ACP define interoperable commerce capabilities; Claude Commerce Agents show how merchants can place agent workflows over controlled tools and existing systems. That comparison matters because none of the three should be treated as a new product master.

The ownership boundary is consistent even when the interfaces differ:

1. 1
   Agent and protocol layer
   Google UCP, OpenAI ACP, or Claude Commerce carries intent and invokes supported commerce capabilities.
2. 2
   Merchant-owned product truth
   The merchant resolves identity, variants, packs, attributes, relationships, provenance, price, availability, and business rules.
3. 3
   Controlled transaction or action
   Merchant and payment systems price, authorize, fulfill, stage, write, or decline the exact target operation.

The protocols and agent architectures differ, but the merchant remains responsible for the product truth exposed through them. Google’s UCP documentation and the ACP specification describe interfaces through which commerce systems expose capabilities. They do not adjudicate whether two supplier rows are one item, whether a GTIN refers to an each or case, or whether a replacement fits.

For implementation details, use the Google UCP merchant-readiness guide, the ChatGPT Shopping and OpenAI ACP catalog-readiness guide, and the Claude Commerce readiness guide. The UCP glossary and OpenAI ACP glossary define the protocols without collapsing them into product-data infrastructure.

Agent identity and product identity converge at the action boundary

Mastercard’s Agent Pay and Agentic Tokens materials describe infrastructure for agent-led transactions, including identifying registered agents and supporting secure payment interactions. Merchant participation and product discovery remain grounded in merchant-controlled commerce systems. This division is appropriate: payment infrastructure can authenticate and authorize the transaction layer without becoming the merchant’s product master.

At the action boundary, the layers meet. An agent may discover merchant-supplied product information, availability, price, shipping, and fulfillment, then proceed through an authorized transaction. The actor can be recognized, the merchant can control participation, and the payment can be valid—while the catalog still exposes a duplicate, stale offer, or wrong variant.

That is not a gap KYA was designed to fill. It is a separate product-data control:

verified agent + unresolved product = accountable action against an ambiguous target

The correct response is layered trust. Agent credentials and transaction authorization come from agent and payment infrastructure. Product identity, scoped facts, and catalog evidence come from product-data infrastructure. Merchant systems retain price, stock, fulfillment, and order authority.

Claude Commerce Agents make the product boundary visible

Anthropic’s commerce-agent engineering guidance and reference implementation separate agent intelligence from merchant systems. Shopping agents call tools for catalog, cart, order, and policy workflows. Merchant agents work through analytics, catalog, inventory, pricing, and campaign capabilities. The guidance recommends integrating existing core systems and business logic rather than rebuilding them in the model.

This reinforces a narrow but important point: agent intelligence is not product truth. The agent can orchestrate a search, explain a comparison, and request an action. The merchant remains responsible for the records and live state returned by tools.

Claro is not the model or agent platform. It is the product and supplier-data execution layer before those calls: resolving identities, assembling evidence-backed attributes and relationships, detecting conflicts, and writing approved changes back to existing systems. The Claude Commerce catalog article defines the backend contract, and the catalog-readiness guide turns it into an implementation checklist.

Product identity needs evidence, not only identifiers

GTIN, MPN, and SKU are useful signals. They are not universal proof. GTINs may be absent or assigned at a different packaging level. Supplier SKUs are local. MPN punctuation varies, old numbers persist after supersession, and some codes are reused across markets or revisions. Private-label and distributor records may not expose the original manufacturer identity at all.

Reliable resolution combines:

• normalized identifiers and known aliases;
• manufacturer and brand identity;
• category-specific attributes that distinguish variants;
• packaging quantity and unit of measure;
• compatibility, supersession, replacement, and offer relationships;
• source evidence and applicability;
• accepted and rejected historical decisions.

The output should not be “probably the same” without explanation. It should identify the resolved entity and level, expose supporting and contradicting signals, and retain an unresolved state when evidence is insufficient. The Canonical Product Record provides the persistent object. Product Data Provenance provides the evidence trail. AI Product Data Verification explains why converting these candidates into operational facts is now the scarce capability.

The trust chain for agentic commerce

Agentic commerce has two identity problems. Payment infrastructure is solving who the agent is. Product-data infrastructure still has to establish what the agent is acting on.

1. 1
   Agent identity — who is acting?
   Verify the agent, accountable operator, credentials, scope, and transaction context through the appropriate identity and payment infrastructure.
2. 2
   Product identity — which exact object?
   Resolve the family, model, variant, packaging level, sellable SKU, and merchant offer required by the action.
3. 3
   Trusted facts — what applies?
   Return evidence-backed specifications, relationships, price, availability, and compatibility with source, scope, and freshness.
4. 4
   Permission policy — is evidence sufficient?
   Combine action impact, identity certainty, fact verification, and business policy to recommend, request evidence, propose, transact, or block.
5. 5
   Action — what happens next?
   Execute the smallest authorized operation with target identity, expected state, idempotency, and reversal controls.
6. 6
   Audit and learning — what should be reused?
   Record outcome, evidence, corrections, returns, approvals, and rejected matches so future decisions improve.

Before an agent can safely act on a product, the system needs one resolved identity, evidence-backed facts, and a policy that says what those facts permit. KYA strengthens the first step for the actor. Canonical product truth strengthens the target and evidence steps. Agentic Commerce Runs on Machine-Readable Product Data covers the wider catalog foundation, and the Commerce Agent glossary defines the agent roles in this architecture.

Primary sources and related Claro resources

FAQ