The Agentic Commerce Protocol War Is a Distraction

14 minute read

Teams keep asking which agentic commerce protocol will win. It is the wrong architecture question.

ACP, UCP, AP2, A2A and MCP overlap at the edges, but they do not describe one interchangeable thing. One helps connect product discovery and purchase journeys. Another standardizes a broader commerce lifecycle. Another adds payment intent and mandate semantics. A2A coordinates independent agents. MCP exposes tools and context to an AI application.

Choosing one as the internal data model would couple a merchant's catalog, orders and policies to a fast-moving external interface. Waiting for one winner is worse. Distribution is already fragmenting across shopping assistants, developer platforms and commerce ecosystems.

The durable choice is less exciting: build a canonical commerce and trust core, then treat protocols as versioned adapters around it.

Start by separating protocol scopes

The protocol names appear together in announcements, so it is easy to assume they are rivals. Their official descriptions show a layered stack.

ACP connects merchants to ChatGPT commerce

OpenAI describes the Agentic Commerce Protocol as the connective layer between merchants and users through product discovery. Merchants can share product feeds and promotions, while current conversion paths can return the shopper to the merchant's own checkout. OpenAI's March 2026 update also says deeper native experiences remain available through ChatGPT apps.

ACP matters because ChatGPT is a distribution surface. It should not become the merchant's canonical product or order model.

UCP describes a commerce journey across surfaces

Google and Shopify describe the Universal Commerce Protocol as an open standard for interactions among consumer surfaces, businesses and payment providers. Its design includes capability discovery and extension points, with bindings through APIs, A2A and MCP. Google's technical UCP overview covers discovery, checkout and order management. Shopify says its 2026 tooling lets developers register an agent profile and use public MCP endpoints without applying for UCP access. Shopify's developer announcement is useful evidence that protocol access is moving from partnership programs toward ordinary developer infrastructure.

UCP is broader than a single assistant surface. It still needs mapping to each merchant's actual systems, policies and data quality.

AP2 addresses payment intent and accountability

Google introduced the Agent Payments Protocol as a payment-agnostic framework that can extend A2A and MCP. AP2 explicitly tackles authorization, authenticity and accountability, including proof that a user gave an agent authority for a purchase. Google Cloud's AP2 announcement describes intent, payment and audit concerns that a generic tool call cannot cover.

It would be inaccurate to say that every protocol merely transports messages and none expresses authority. AP2 has mandate concepts. The engineering question is how AP2 payment authority relates to enterprise authority outside payment: procurement policy, supplier eligibility, data use, delegation, refunds, fulfillment changes and service actions.

A2A coordinates independent agents

The official A2A specification focuses on discovery, capability communication, tasks, messages and artifacts across independent agent systems. It is designed to let opaque agents collaborate without sharing internal memory or tools. The A2A specification is a coordination protocol, not a merchant's ledger or product information model.

MCP exposes tools and context

MCP uses a client-server architecture in which AI applications connect to servers that expose tools, resources and prompts. Its tools are executable functions that an AI application can invoke. The official MCP architecture guide explains this boundary.

MCP is a good binding for actions such as catalog.search or cart.create. The tool schema does not, by itself, prove that a specific agent may spend a specific budget for a specific buyer.

Model the stack, not the logo wall

A merchant architecture can assign each concern to a stable layer:

This is not an argument for adding every protocol. It is an argument for refusing to force one protocol to own concerns outside its scope.

Use canonical actions inside the merchant boundary

Suppose three channels want to create a cart. One sends a UCP checkout request, one calls an MCP tool, and one uses a merchant's existing REST endpoint. The merchant should map all three into the same internal command:

type CreateCartCommand = {
  transactionId: string
  merchantId: string
  buyerContext: {
    subject?: string
    market: string
    currency: string
  }
  lines: Array<{
    variantId: string
    quantity: number
  }>
  promotionCodes: string[]
  deliveryCountry: string
  idempotencyKey: string
  source: {
    protocol: "ucp" | "acp" | "mcp" | "merchant_api"
    version: string
    requestDigest: string
  }
}

The cart service does not need to know how an MCP tool was described or how a UCP capability document was transported. It receives a validated command with stable merchant identifiers.

The adapter has strict responsibilities:

1. Validate the external schema and version.
2. Authenticate the caller under that binding.
3. Translate external identifiers into canonical merchant IDs.
4. Preserve protocol-specific evidence and extension fields.
5. Produce one canonical command and digest.
6. Translate the result and errors back without inventing success.

Business policy stays outside the adapter. A UCP connector should not have one discount limit while the REST connector has another. Both call the same deterministic policy with the same commercial state.

Capability negotiation needs runtime verification

Protocols increasingly let merchants advertise capabilities. That is useful, but a capability claim can become stale after a deployment, market change or connector failure.

Keep an internal capability registry:

{
  "capability": "checkout.create",
  "merchant": "merchant:example",
  "markets": ["DE", "FR"],
  "constraints": {
    "guest_checkout": true,
    "currencies": ["EUR"],
    "requires_customer_presence": false
  },
  "bindings": [
    { "protocol": "ucp", "version": "negotiated-version", "status": "active" },
    { "protocol": "mcp", "version": "negotiated-version", "status": "active" }
  ],
  "verified_at": "2026-08-11T08:00:00Z",
  "expires_at": "2026-08-11T09:00:00Z"
}

Then test the capability through its binding. Validate schema conformance, authentication, expected denial behavior, idempotency and a safe synthetic transaction. Discovery should rank only capabilities whose evidence is current enough for the use case.

A manifest is a deployment description, not permission for every agent to invoke everything it lists.

Authority must survive protocol translation

An agent may arrive over A2A, choose a tool over MCP, create a checkout through UCP and attach an AP2 payment mandate. The transaction crosses four protocol boundaries. Authority can disappear between them if each adapter extracts only the fields needed for its immediate API call.

Create a protocol-neutral transaction envelope that binds:

• accountable agent and organisation;
• authority or mandate references;
• purpose, action and resource;
• merchant, buyer and counterparty;
• amount, currency and commercial profile;
• request digest, audience, time and nonce;
• protocol source and transformation chain.

{
  "transaction_id": "tx:purchase:0194",
  "agent_id": "agent:buyer:procurement-7",
  "organisation_id": "org:buyer",
  "action": "checkout.create",
  "resource": "merchant:acme/cart:cart-882",
  "purpose": "office-supplies-replenishment",
  "amount": { "value": "742.00", "currency": "EUR" },
  "authority": {
    "enterprise_mandate": "mandate:procurement:q3-17",
    "payment_mandate": "ap2:payment-mandate:991"
  },
  "source": { "protocol": "ucp", "version": "negotiated-version" },
  "request_digest": "sha256:...",
  "issued_at": "2026-08-11T09:14:02Z",
  "nonce": "01K2..."
}

Do not assume two mandate formats have identical semantics because they share a word. Write an explicit mapping. If one format cannot express a required supplier restriction, approval condition or delegation limit, preserve the original signed object and enforce the missing condition in local policy. Never widen authority to make translation convenient.

Versioning is where interoperability becomes real

Protocol demos usually show matching client and server versions. Merchant systems live longer than that.

For every adapter, publish:

• supported protocol and extension versions;
• required and optional fields;
• downgrade behavior;
• canonical action mappings;
• error and retry semantics;
• signature and trust requirements;
• test vectors and known unsupported features.

Reject unknown mandatory extensions. Preserve unknown optional fields only when doing so cannot alter business meaning. Store the original request digest alongside the canonical command digest so an investigator can reconstruct the transformation.

Avoid version checks scattered through handlers:

interface CommerceBindingAdapter<Input, Output> {
  validate(input: unknown): Input
  authenticate(input: Input, transport: TransportContext): Promise<Caller>
  normalize(input: Input, caller: Caller): Promise<CanonicalCommand>
  render(result: CanonicalResult): Output
  conformance(): Promise<ConformanceReport>
}

This makes a protocol upgrade an adapter change, not a catalog migration.

Failure cases to test

Identifier collision. ACP and UCP requests refer to the same variant with different channel IDs. The resolver must reach one canonical variant without merging unrelated records.

Semantic downgrade. An incoming payment mandate contains a restriction the internal model ignores. Reject or preserve and enforce it. Do not silently drop it.

Capability drift. The registry advertises return creation, but the merchant connector only supports return lookup after an upgrade.

Retry mismatch. MCP retries a timed-out tool call with a new ID while the UCP adapter uses the old cart idempotency key. Define one business idempotency identity across bindings.

Partial transaction. Checkout succeeds but payment authorization times out. Keep cart, payment and order states separate and reconcile against authoritative providers.

Authentication confusion. An A2A agent card identifies an agent, but the checkout request arrives with an unrelated OAuth client. Bind runtime proof to the transaction identity.

Policy fragmentation. A promotion is allowed through one adapter and denied through another. Run the same canonical facts through one policy decision path.

Protocol outage. A surface is unavailable while the merchant APIs work. Circuit-break the adapter without taking down every channel.

Implementation checklist

• Inventory protocols by function, channel and counterparty.
• Define canonical product, offer, cart, order and outcome models.
• Define stable commerce actions independent of transport.
• Implement each protocol as a versioned boundary adapter.
• Preserve original signed objects and protocol request digests.
• Map identifiers through one canonical registry.
• Centralize business policy after normalization.
• Keep enterprise authority and payment authority explicit.
• Reject semantic downgrades and unknown mandatory extensions.
• Share idempotency identities across protocol bindings.
• Verify advertised capabilities with conformance tests.
• Reconcile transaction outcomes against authoritative systems.
• Monitor adapter-specific errors without fragmenting business metrics.
• Plan protocol replacement as an adapter operation.

Intelliger's position and current boundary

Intelliger's target commerce architecture uses protocol-neutral merchant connectors, a canonical Commerce Graph, stable universal commerce actions, capability verification and a resolver. OATI supplies a separate trust backbone for agent identity, delegated authority, deterministic constraints, revocation and receipts. The intent is to support ACP, UCP, MCP, A2A and existing APIs where they fit, not to replace them.

Most of that broader commerce platform is still target state. The implemented OATI developer preview provides schemas, SDKs, canonical signing, deterministic evaluation, lookup and discovery, reference HTTP middleware, MCP/A2A adapters, and 73 shared conformance cases. The Commerce v0.1 profile and paid-API sandbox exist, but the universal connector fleet, Commerce Graph, Merchant Agent Runtime and commerce resolver are not complete production services. Independent protocol review also remains open.

Protocol competition will continue, and some standards will gain more adoption than others. Merchants do not need to predict the final ranking. They need internal commerce semantics that remain correct when the next channel arrives.

Protocol normalization is only safe when AI agent identity remains separate from delegated authority. The broader agentic commerce platform architecture shows where those adapters sit relative to merchant systems, evidence and outcomes.