What Has to Be True Before an AI Agent Can Act on a Specific Product?

Reading is not acting

Machine commerce already has real catalogue and tool primitives.

The Universal Commerce Protocol catalogue capability dated 25 August 2026 defines machine-readable catalogue search and lookup, product and variant identifiers, variant barcodes, custom metadata and structures for policies such as warranty and returns. Its MCP catalogue binding can expose catalogue search and lookup as callable tools. UCP also defines identity linking using scoped OAuth-style authorisation for user-authenticated commerce operations.

It is not the same thing as universal DPP consumption, and it does not establish a standard sustainability or passport vocabulary. Our review of the current UCP catalogue surface found no dedicated standard DPP or sustainability field set; the specification does, however, allow business-defined metadata and disclosures. The current Agentic Commerce Protocol product-feed specification likewise provides structured product data for agentic discovery, but the audited standard surface did not expose a dedicated DPP, sustainability, certification or material contract. Those are bounded absence findings, not claims that extensions or future versions cannot carry such data.

The same discipline applies when another commerce platform already carries product fields. Google Merchant Center's product-data specification includes fields such as GTIN and material, plus narrow certification structures. That does not by itself show that UCP, ACP or another agent protocol consumes those fields. Platform data availability and protocol consumption are separate evidence questions.

None of these catalogue or protocol capabilities proves that a user or agent has a warranty right, repair entitlement or authority over the physical product.

The mapping problem is separate again. A commerce system can have a field called material, weight or brand while meaning something different from a compliance record. The canonical treatment is where product data stops meaning the same thing. Semantic mapping is one layer of action readiness, not the whole stack.

Likewise, a GS1 Digital Link identifier can make a product identity web-addressable and resolvable. That is useful discovery infrastructure. It does not by itself create an executable product service or grant permission to use one.

The product-action stack

A machine acting on a particular product needs more than a good API. It needs a chain in which each layer answers a different question.

Later layers do not appear automatically because an earlier one works.

A product identifier can resolve correctly while the product state is stale. A credential can verify while the claim is outside scope. A tool can be callable while the agent has no entitlement to invoke it. A successful API response can still be operationally wrong if the system acted on the wrong product instance.

What exists now

Several pieces of this stack are Recommendation- or specification-level technology now.

Product identity and resource discovery

The GS1-Conformant Resolver Standard 1.2.1, current as at 19 August 2026, can connect a GS1-identified object to human- or machine-readable resources through typed linksets. It includes a narrow verificationService pattern, which is evidence that identifier-triggered service discovery is not purely conceptual.

GS1 Digital Link URI Syntax 1.7.0 provides current persistent-identifier syntax that can participate in that discovery chain. Neither specification creates a general executable lifecycle service, authorisation model or entitlement system.

A tightly scoped production precedent exists in the US pharmaceutical verification ecosystem: GS1 US guidance on DSCSA verification supports identifier-triggered verification routing and operational verification processes. It is useful evidence that a product identifier can sit inside a real verification workflow. It is not evidence of general autonomous repair, take-back or DPP action across sectors.

Machine-verifiable trust primitives

The W3C Verifiable Credentials 2.0 family became Recommendations on 15 May 2025. Data Integrity 1.0 provides compatible cryptographic integrity/authenticity checks and Bitstring Status List 1.0 provides a status primitive for suspension or revocation.

Those components can strengthen a machine trust decision. They still do not prove that the issuer is authoritative for the intended product scope or that the credential is attached to the genuine physical item. That deeper boundary is owned by machine-verifiable product certificates.

Callable tools and authorisation

The Model Context Protocol Tools specification dated 28 July 2026 allows servers to expose tools with defined input and output schemas that clients or models can discover and invoke. Its authorisation specification provides a current path for authenticated and authorised HTTP tool invocation.

That establishes a generic machine-action primitive. It does not bind a tool to a physical product identifier or decide whether a user is entitled to invoke a warranty, repair or return service for that product.

The A2A Protocol 1.0 similarly defines Agent Cards for discovering agents, capabilities, endpoints and security schemes. The Linux Foundation reported support from more than 150 organisations and enterprise production use in April 2026. That is an ecosystem signal, not an independent measure of product-specific agent action at scale.

Maturity today

A standard is not a deployment. A platform-specific implementation is not a cross-brand contract. A callable tool is not an entitlement.

Product identity can also travel inside a photograph. You can write the GTIN and Digital Link into the image file as standard XMP metadata, though a platform that re-encodes the image will often strip it.

The missing bridge is the important part

ActivateDigital’s bounded cross-protocol audit compared the current GS1 Resolver, MCP, A2A and UCP mechanisms. It did not find a normative bridge that takes a GS1 product identifier and automatically binds it to a generic executable MCP or A2A service plus the product-specific entitlement and authorisation semantics required to use that service.

That negative finding is narrow. It does not mean a proprietary integration cannot build the chain today. A brand, retailer or service provider can connect its own identifiers, data, trust rules, permissions and APIs. The finding is that those pieces do not yet collapse into a plug-and-play cross-brand standard merely because each component exists.

A scan is not an action architecture either. What happens when somebody scans a code explains how a carrier, address, identifier and resolver can route a request to a chosen resource. A post-sale service can sit behind that route. The scan does not decide whether the requester is entitled to invoke the service or what a safe machine action contract should contain.

What remains emerging

The emerging layer is not “AI agents exist”. It is the attempt to make commerce and service actions more interoperable while carrying stronger identity, policy and authorisation context.

UCP already exposes catalogue semantics, identity linking and protocol bindings for machine commerce. MCP already exposes callable tools and authorisation. A2A already exposes agent discovery. These are useful pieces of a future action stack.

Delegated-agent trust is also becoming an explicit commerce problem, but it is not settled infrastructure. Visa's current Trusted Agent Protocol material says the protocol is still in the process of development and deployment and that depicted features or sequences may not be available in all markets. That is evidence of direction and active implementation work, not proof of a universally deployed trust layer.

What remains emerging is their use in product-specific business workflows where the system has to carry more than catalogue identity. A repair action, for example, may need the exact product instance, current state, service eligibility, parts constraints, user authority, region and an auditable result. A return action may need merchant policy, purchase evidence and a live entitlement. Those semantics are business-specific today unless a particular platform or programme defines them.

The evidence supports these as current protocol capabilities, not as proof that a common product-specific action model has been deployed across brands.

What remains possible

The plausible destination is a portable chain in which an agent can move from a product identifier to an authorised action without bespoke integration at every step.

That would require, at minimum:

• stable product and instance identity;
• shared semantics for the product state needed by the action;
• accepted trust rules for evidence and issuers;
• portable user/agent authority and product entitlement;
• discoverable service contracts with machine-readable constraints;
• consistent outcome and audit records.

The pieces suggest that this is technically possible. The sources reviewed here do not support calling it current universal interoperability.

A useful architecture test is not “Can an agent call an API?” It is: Can a different authorised agent, starting from the product identity, discover the right service, understand the required state, prove its authority, invoke the action safely and produce a result that another party can audit?

Until that chain works repeatably across brands and services, cross-brand product-specific action remains POSSIBLE, not established practice.

Six failure modes worth designing out

These are architecture failure modes, not reasons to avoid automation.

Wrong product. The identifier resolves, but to the wrong variant, batch, serial or physical item.

Stale product state. The service acts on data that was valid earlier but is no longer current for the action.

Untrusted or mis-scoped evidence. A credential verifies technically, but its issuer, scope or subject is insufficient for the decision.

No authority or entitlement. The user or agent can reach the service but cannot prove the right to perform the requested action.

Ambiguous action. The interface exposes a callable operation without enough constraints to know what it means, when it is allowed or what side effects it creates.

No auditable result. The action completes but the system cannot reconstruct which product, evidence, authority, inputs and policy produced the outcome.

Designing these checks explicitly is more useful than adding “AI-ready” as a property of the product record.

What would change this answer

This page should be revisited when any of the following appears in stable, repeatable form:

• a normative product-identifier-to-service binding that works across implementations;
• portable product-specific trust and entitlement semantics rather than platform-only authorisation;
• production multi-merchant or multi-brand deployments in which agents discover and execute lifecycle actions without bespoke pairwise integration;
• material revisions to UCP, MCP, A2A, GS1 Resolver or related specifications that close the current bridge.

For a business building now, the decision is not whether to wait for universal interoperability. It is to keep the layers separate enough that today's bounded integrations can later be replaced or connected without pretending the missing bridge already exists.

Sources

Sources as at 4 September 2026.

• GS1: GS1-Conformant Resolver Standard 1.2.1, 19 August 2026. Used for product-identifier-to-resource and narrow service discovery.
  Standards body
• GS1: Resolver archive, 19 August 2026. Supporting source used to confirm the current resolver version.
• GS1: GS1 Digital Link URI Syntax 1.7.0, August 2026. Used for current persistent product-identifier syntax and discovery compatibility.
  Standards body
• GS1 US: DSCSA verification guidance. Supporting context for a tightly scoped production verification workflow, not cross-sector autonomous action.
• W3C: Verifiable Credentials 2.0 family, 15 May 2025. Used for current machine-verifiable credential standards.
• W3C: Verifiable Credential Data Integrity 1.0, 15 May 2025. Used for compatible cryptographic integrity/authenticity checks.
• W3C: Bitstring Status List v1.0, 15 May 2025. Used for compatible credential status checks.
• OpenID Foundation: OpenID for Verifiable Credential Issuance 1.0, 16 September 2025. Supporting context for standardised credential issuance.
• Model Context Protocol: Tools, 2026-07-28. Used for current generic machine-callable tool discovery and invocation.
• Model Context Protocol: Authorization, 2026-07-28. Used for current authenticated/authorised tool invocation primitives.
• A2A Project / Linux Foundation: Agent2Agent Protocol 1.0, 12 March 2026. Used for interoperable agent discovery and interaction primitives.
• Linux Foundation: A2A ecosystem announcement, 9 April 2026. Supporting first-party adoption signal only.
• UCP: Catalog Capability, 25 August 2026. Used for current product/variant catalogue semantics and their limits.
• UCP: Identity Linking, 25 August 2026. Used for scoped merchant authorisation, not physical-product entitlement.
• UCP: Catalog MCP Binding, 25 August 2026. Used for current machine-callable catalogue interfaces.
• UCP: Checkout A2A Binding, 25 August 2026. Supporting context for protocol interoperability, not product-identifier-to-service binding.
• ActivateDigital bounded cross-protocol product-to-service audit, 4 September 2026, using the GS1, MCP, A2A and UCP primary specifications above. Used only for the narrow finding that no normative plug-and-play product-identifier-to-executable-service-plus-entitlement bridge was identified in that review.
• UCP: Announcements / current release, 25 August 2026. Used to confirm the current UCP v2026-08-25 release status; it does not prove broad adoption or DPP usage.
• Agentic Commerce Protocol: Product Feed Specification, accessed 4 September 2026. Used for the bounded finding that the audited standard feed surface does not expose a dedicated DPP/sustainability contract; extensions and future versions remain possible.
• Visa: Trusted Agent Protocol, accessed 4 September 2026. Used to bound delegated-agent trust as still in development/deployment rather than a universal production layer.
• Google Merchant Center: Product data specification, accessed 4 September 2026. Used to distinguish product fields available in a commerce platform from evidence that an agent protocol consumes those fields.