Agentic Commerce Platforms Are Infrastructure

14 minute read

An agentic commerce platform is more than the shopping assistant a buyer sees. Shopping assistants attract attention because they are visible. A user describes a need, the agent compares products and a polished carousel appears. The interface is useful. It is also the easiest layer to replace.

Foundation models change. Agent surfaces multiply. Merchants keep their systems of record. Payments, inventory, fulfillment, returns and commercial authority remain messy.

The company that builds durable agentic-commerce value will solve that mess. It will connect merchant systems, normalize products and actions, verify who an agent represents, constrain what it may do, reconcile outcomes and route transactions using evidence. The assistant may belong to that company, a retailer, a bank, a model provider or the buyer. The infrastructure has to work with all of them.

This is a thesis, not a market forecast. "Billion-dollar" makes a good headline, but no architecture guarantees a valuation. The defensible point is narrower: conversational access alone is a weak technical moat when the transaction depends on deeper systems that every assistant needs.

The interface is moving faster than the transaction layer

OpenAI's current commerce direction illustrates the split. In March 2026 it expanded ACP for product discovery, letting merchants share feeds and promotions and supporting several delivery paths. It also said it was allowing merchants to use their own checkout experiences while OpenAI focused on discovery. OpenAI's product discovery announcement is a clear signal that discovery and conversion do not have to live in one product surface.

UCP defines capabilities for cart, checkout, identity linking and orders. Its Checkout capability leaves the business as merchant of record, while payment handlers come from the business profile. The UCP Checkout specification expects the protocol to connect existing participants rather than replace their commerce stack.

MCP takes a similar approach at the tool layer. It lets servers expose named tools with input and optional output schemas, and it allows the visible tool set to vary with the authorization on a request. The MCP tools specification does not claim that tool discovery decides business authority.

The protocols are useful precisely because they separate concerns. That leaves a large infrastructure problem between "the agent can call this" and "the enterprise can safely honor it."

The assistant depends on several infrastructure layers

An agentic-commerce stack needs at least these responsibilities:

buyer or merchant experience
  -> protocol gateway
  -> commerce graph and live state
  -> identity, authority and policy
  -> execution adapters
  -> evidence, reconciliation and outcomes

The protocol gateway speaks ACP, UCP, MCP, A2A, HTTP or merchant-specific APIs. It maps their objects into stable internal actions.

The commerce graph normalizes products, variants, compatibility, offers, policies, customers, carts and orders. It preserves merchant-native identifiers and provenance.

The trust layer verifies the agent and accountable organization, checks delegated authority, evaluates deterministic policy and handles revocation.

Execution adapters call the systems that own price, inventory, payment, fulfillment and returns. They translate without becoming the source of policy.

Evidence binds the request, decision and observed result. Reconciliation follows changing external state.

Outcome infrastructure connects predictions to what actually happened: selected, purchased, delivered, returned, disputed or retained.

An assistant consumes these layers. It does not eliminate them.

Merchant integration is not glamorous, which helps

A retailer may have a storefront platform, PIM, ERP, order-management system, warehouse system, payment provider, returns platform and customer-service tools. Their data models disagree. Identifiers drift. One system owns list price, another owns contract price, and a third can override fulfillment.

A reliable merchant connector has to answer:

• Which product record is authoritative for each field?
• How does a product family map to purchasable variants?
• Which fields can be indexed, and which require a live call?
• How are market and customer eligibility represented?
• What constitutes one idempotent cart, order or refund operation?
• Which external status closes or reverses a transaction?

These mappings look like integration work because they are. The moat appears when the platform turns repeated mappings into a connector framework, a canonical graph, conformance tests and reusable operational knowledge.

A protocol-only company can be bypassed by a new protocol. A connector-only company can become services-heavy. The stronger position combines protocol neutrality with a stable internal transaction and evidence model.

Trust is more than agent identity

An authenticated agent may still lack authority to buy, negotiate, disclose customer data or issue a refund. Identity answers who holds the credential. Commerce needs the rest of the sentence: acting for which organization, under what delegation, for which purpose, against which counterparty, within what budget and until when?

AP2 addresses part of this for payments through Checkout and Payment Mandates plus corresponding receipts. It explicitly places deterministic validation inside each role and leaves catalog and checkout communication to the commerce protocol. The AP2 specification shows why payment authority can complement UCP rather than compete with it.

The broader infrastructure opportunity is a portable authority model across commerce actions. A refund, inventory reservation and supplier order all need different constraints, but the transaction pattern is stable:

identity -> mandate -> bound request -> deterministic decision
-> execution -> signed receipt -> reconciled outcome

That pattern should work when only one enterprise deploys it. A supplier should not need to rebuild its API before a buyer can control an outbound purchasing agent. Bilateral adoption can add stronger evidence later.

Live state defeats the all-in-one assistant

Product descriptions can be indexed. Inventory, contextual price, promotions and delivery estimates change too quickly to trust as prompt context.

UCP distinguishes cart exploration from checkout finalization and requires binding transaction data for eligibility and policy at checkout. Its Order capability treats the business response as a current-state snapshot and recommends reconciliation through events and retrieval. UCP Cart and UCP Order both assume that state lives outside the conversational surface.

The infrastructure platform therefore needs two paths:

1. Indexed retrieval for stable facts and candidate generation.
2. Authoritative tool calls for volatile facts and commitment.

The assistant receives three to ten candidates, not the entire catalog. Before purchase it refreshes price, availability, fulfillment and policy. This is closer to a query planner plus transaction coordinator than a chatbot with a large context window.

Receipts become the shared object after the conversation ends

Conversations are hard to compare across models and merchants. A receipt can have stable fields: agent, organization, mandate, request digest, policy version, decision, external reference and observed result.

AP2 uses mandate and receipt pairs as potential dispute evidence, while leaving operational retention and retrieval details outside its current scope. That gap matters. Schemas do not run evidence stores, resolve conflicting outcomes or package an audit trail.

A durable platform can provide:

• independently verifiable receipts
• assurance labels for unilateral and countersigned evidence
• retention and access policy
• payment and order reconciliation
• linked reversals and corrections
• dispute-package export

Receipts do not prove the outside world was truthful. They prove the integrity of a signed record and show what its issuer attested was verified and recorded. The infrastructure still needs source quality, reconciliation and contractual rules.

Verified outcomes create a better learning asset than chat logs

Chat transcripts contain intent and language. They often lack the result. Did the item arrive on time? Was it returned? Did the negotiated discount improve contribution margin or simply subsidize a buyer who would have purchased anyway?

The more useful trajectory is:

state + action + predicted outcome + verified actual outcome

With consent and strict isolation, outcome data can improve retrieval, routing, fraud detection and merchant recommendations. It can also create serious governance problems. Cross-merchant data use needs purpose limitation, aggregation and explicit rights. A signed receipt does not grant training permission.

This is where network effects may appear, but only after the platform can verify outcomes. A routing score trained on clicks alone will favor attention. A routing system informed by delivery, returns and disputes can optimize for transaction quality, provided it remains contextual and appealable.

The infrastructure moat has four parts

Code alone is not enough. A durable position compounds across:

Normalization

Canonical product, offer, mandate, transaction and outcome models reduce the cost of adding protocols and merchant systems.

Operational trust

Key lifecycle, revocation, replay, tenant isolation, failure handling and evidence retention are difficult to bolt on after launch. Production exercises and external review matter more than a polished sandbox.

Outcome coverage

The platform learns which transactions completed, failed, reversed or disappointed the buyer. Those labels improve routing and simulation when data rights permit their use.

Ecosystem conformance

Open schemas, SDKs and exact test vectors let other implementations verify compatibility without buying the commercial platform. The company earns revenue from managed operation, integration and assurance rather than keeping verification proprietary.

None of these moats appears after one API integration. They compound only if the platform resists customer-specific policy forks and turns deployments into reusable product capability.

What not to build first

The infrastructure thesis can become an excuse to build everything. Avoid it.

Do not start with a universal merchant marketplace, a proprietary payment rail, a global reputation score or a world model trained on data you do not yet have. Do not require both sides of every transaction to adopt a new identity system before either gets value.

Start with one bounded workflow and preserve the larger architecture:

one merchant or API connector
-> one canonical action
-> one bounded mandate
-> one deterministic decision
-> one existing execution provider
-> one verifiable receipt
-> one reconciled outcome

Prove onboarding time, denial accuracy, reconciliation time and operational value. Add connectors only when repeated paid demand justifies them.

Where Intelliger actually stands

Intelliger's implemented foundation is OATI's developer-preview trust layer. It includes public schemas, canonical signing, TypeScript, Python and Go SDKs, deterministic mandate evaluation, Commerce constraints, middleware, lookup and discovery, receipts and a shared 73-case conformance suite. A hosted trust and discovery vertical slice exists, and local sandboxes demonstrate Commerce and RWA flows.

This is not the complete infrastructure company described above. The independent security review remains open. Durable bilateral evidence, audit export and dispute handling are incomplete. Customer gateway operations still require production outage exercises.

The Commerce Graph, connector platform, Merchant Agent Runtime, Agent Search Console, resolver, contextual reputation, Outcome Ledger, World Model and negotiation engine are target-state components in the August 2026 blueprint. They are sequenced after current OATI release gates and customer evidence. They should not be described as deployed products.

The current commercial wedge is narrower: control one supplier-invoice payment through an existing payment provider without becoming a bank, custodian or treasury platform. Agent-readable merchant diagnostics are a proposed commerce wedge, not a settled replacement for that plan.

Implementation checklist

• Keep model and protocol providers replaceable.
• Normalize protocols into stable internal commerce actions.
• Separate indexed product facts from live transaction state.
• Preserve merchant systems as authoritative execution sources.
• Verify organization, agent and delegated authority at the boundary.
• Bind every consequential request to deterministic policy.
• Use idempotency and reconciliation for external writes.
• Issue receipts with explicit assurance levels.
• Connect predictions to verified outcomes before training on them.
• Govern cross-merchant data with consent and purpose limits.
• Turn integrations into reusable connectors and conformance tests.
• Start with one workflow that works when one company deploys it.

Shopping assistants will be important interfaces. They may also become features inside browsers, merchant apps, bank apps and operating systems. The harder, less visible work remains underneath: making thousands of merchant systems legible, callable, authorized and accountable to whichever agent the buyer chooses.

That infrastructure starts with protocol-neutral agentic commerce adapters, becomes measurable through AI search optimization, and remains accountable through signed AI audit trails.