AXD Protocol Lab · v1.0 · April 2026
Protocol Lab
Implementation guide for the agentic commerce protocol stack. From protocol awareness to protocol deployment in 90 days.
Step-by-step walkthroughs for UCP, ACP, MCP, A2A, Visa Intelligent Commerce, and Mastercard Agent Pay. Decision frameworks, vendor selection guidance, and a sequenced adoption roadmap for teams moving from awareness to deployment.
The agentic commerce protocol stack is no longer theoretical. In January 2026 Google launched the Universal Commerce Protocol at NRF. OpenAI's Agentic Commerce Protocol has been live inside ChatGPT since late 2025. Visa Intelligent Commerce is accepting sandbox registrations. Mastercard Agent Pay rolled out to all US cardholders in November 2025.
The question is no longer whether your organisation should integrate with these protocols. It is which protocol, in what sequence, using what integration strategy, and with what measurement framework in place to know whether the work is delivering.
The AXD Protocol Lab answers those questions. It sits at the intersection of the AXD discipline's theoretical foundations and the urgent practical need to implement. Where the AXD Observatory builds the vocabulary and the 12 AXD Practice Frameworks define the design architecture, the Protocol Lab provides the implementation engine: walkthroughs, decision tools, vendor selection guidance, and a sequenced 90-day adoption roadmap.
Who This Is For
Product and engineering teams
Teams building or configuring the technical integration of agentic commerce protocols into existing commerce infrastructure.
Commerce and digital strategy leaders
Leaders making investment and sequencing decisions about agentic commerce readiness, who need a framework that connects technical choices to commercial outcomes.
Compliance, risk, and regulatory teams
Specialists in regulated industries (financial services, healthcare, insurance) who need to understand the trust, identity, and audit requirements that accompany protocol adoption.
The agentic commerce protocol landscape
Six protocols now define the communication infrastructure of agentic commerce. They operate at different layers of the stack, solve different coordination problems, and are not competing alternatives. In a mature agentic commerce deployment, all six are active simultaneously.
How the Protocols Relate
| Protocol | Layer | Core Question | Commerce Phase |
|---|---|---|---|
| UCP | Full commerce journey | How does an agent discover, evaluate, and purchase from a merchant catalog? | Discovery through checkout |
| ACP | Transaction execution | How does an agent initiate and complete a checkout inside a conversational AI surface? | Checkout and payment execution |
| MCP | Agent-to-infrastructure | How does an agent access the external tools, APIs, and data sources it needs? | Tool and data connectivity |
| A2A | Agent-to-agent | How does one agent delegate a task to another specialist agent? | Multi-agent coordination |
| VIC | Payment authentication | How does a merchant verify that an agent-initiated payment is legitimate? | Identity and fraud prevention |
| Agent Pay | Payment tokenisation | How does a payment network bind an agent to a specific user's authority? | Token-based authorisation |
Build, aggregate, or platform?
The first and most consequential implementation decision is not which protocol to implement. It is how to implement: direct protocol integration, use of an aggregation layer, or reliance on a commerce platform's native agentic storefronts. Each approach has a different cost, capability, and risk profile.
Approach 1
Direct Protocol Integration
Build native integration with each protocol's API and SDK.
Best for: Enterprise teams with dedicated engineering capacity, organisations requiring full control over data flows and trust architecture, businesses in regulated industries where auditability is a first-class requirement.
Investment: High. Expect 3-6 months for full multi-protocol integration with a dedicated team of 2-3 engineers.
Advantages
- • Full auditability
- • Maximum customisation of trust and consent architecture
- • No intermediary in the data flow
- • Compliance demonstrability
Risks
- • Protocol versioning maintenance burden
- • Potential lag behind platform-native integrations as protocols evolve rapidly in 2026
Approach 2
Aggregation Layer
Use a middleware platform (Firmly, eLLMo, similar) to normalise and distribute across multiple protocols via a single integration.
Best for: Mid-market merchants without dedicated protocol engineering capacity, teams needing rapid deployment across multiple AI surfaces, organisations prioritising time-to-market over maximum customisation.
Investment: Medium. Typical deployment 2-6 weeks. Platform costs vary; expect revenue share or subscription plus setup.
Advantages
- • Single integration delivers multi-protocol coverage
- • Faster time to agent visibility
- • Aggregator handles protocol versioning as the stack evolves
Risks
- • Intermediary in the data flow raises compliance questions in regulated sectors
- • Aggregator platform risk
- • Less control over trust architecture customisation
Approach 3
Platform-Native Agentic Storefronts
Rely on Shopify Agentic Storefronts, Salesforce Agentforce, or SAP's agentic catalog infrastructure to handle protocol integration automatically.
Best for: Merchants already on Shopify Plus or comparable enterprise platforms, teams with minimal engineering resource for agentic integration, organisations prioritising lowest friction path to initial agent visibility.
Investment: Low. Platform configuration rather than engineering. Shopify Agentic Storefronts are available to Plus merchants with minimal setup.
Advantages
- • Fastest path to technical integration
- • Platform maintains protocol compliance as the stack evolves
- • No engineering overhead for merchants on supported platforms
Risks
- • The platform solves connectivity, not data quality
- • A Shopify store with incomplete product data will remain invisible to agents despite having the technical integration enabled
- • This is the most common failure mode
Decision Framework: Which Approach for Your Context?
| Context | Recommended Approach |
|---|---|
| Regulated industry (FS, healthcare, insurance) | Direct build or platform-native with compliance audit. Aggregation layers require careful due diligence on data flows. |
| Enterprise, own platform | Direct build. Full auditability and trust architecture control justify the investment. |
| Mid-market, Shopify Plus | Platform-native first. Invest engineering time in data quality, not protocol plumbing. |
| Mid-market, custom platform | Aggregation layer to achieve rapid multi-protocol coverage, with a migration roadmap to direct build if volume justifies it. |
| Startup or early-stage | Aggregation layer or platform-native. Preserve engineering capacity for differentiated product, not protocol maintenance. |
| B2B or procurement context | Direct build. Agent-to-agent negotiation and enterprise trust requirements exceed what aggregation layers currently support. |
Data quality requirements by protocol
Technical protocol integration is necessary but insufficient for agentic commerce success. Products with incomplete data do not appear in agent recommendations. Products with stale inventory create failed transactions. Data quality is the variable that determines whether protocol integration produces agent visibility or agent invisibility.
The AXD Data Maturity Score provides a scored assessment of your product data against these requirements. Products with attribute completeness below 70% are rarely included in agent recommendations, even when technically discoverable. Products above 90% completeness consistently outperform those in the 70-90% range.
| Data Field | UCP | ACP | MCP | A2A |
|---|---|---|---|---|
| Product name | Required | Required | Required | Required |
| SKU / product ID | Required | Required | Optional | Optional |
| Real-time price | Required | Required | Optional | Required |
| Availability / inventory status | Required | Required | Optional | Required |
| Product description (50+ chars) | Required | Required | Optional | Optional |
| Google product category taxonomy | Required | Optional | Optional | Optional |
| Product attributes (material, dimensions) | Recommended | Required | Optional | Optional |
| Structured review aggregate (schema.org) | Recommended | Recommended | Optional | Optional |
| Return and exchange policy (machine-readable) | Required | Required | Optional | Optional |
| Fulfilment options with lead times | Required | Recommended | Optional | Optional |
| Images with alt text | Required | Recommended | Optional | Optional |
| GTIN / barcode | Recommended | Recommended | Optional | Optional |
Agent identity, authentication, and trust
The trust architecture requirements of agentic commerce are not addressed by protocol integration alone. Protocols define how agents communicate; trust architecture defines whether agents should be trusted to communicate at all.
The Agent Identity Stack
Platform identity
Which AI platform is making the request?
Protocol-level authentication via OAuth 2.0, agent registry lookup
User authority
Which human principal has authorised this agent to act?
Agentic tokens (Visa VIC, Mastercard Agent Pay), session-scoped delegation tokens
Transaction legitimacy
Is this specific transaction within the authority granted?
TAP verification, Cloudflare Web Bot Auth, real-time fraud scoring
All three layers must be functional for a production agentic commerce deployment. An agent with verified platform identity but no user authority signal is a bot. An agent with user authority but no transaction legitimacy check is a fraud vector. The architecture is only as strong as its weakest layer. See the Visa Intelligent Commerce and Mastercard Agent Pay walkthroughs for implementation details.
90-day protocol adoption roadmap
A sequenced implementation plan for teams moving from protocol awareness to live protocol deployment. Assumes a mid-market organisation with a custom commerce platform, moderate engineering capacity, and no existing agentic protocol integrations. Adjust phase timing and sequencing using the decision framework above.
This roadmap assumes integration alongside your team's existing workload at approximately 40% engineering capacity allocation. Teams able to dedicate full-time engineering resource should expect to complete the full roadmap in 45-60 days rather than 90.
Foundations
Weeks 1-3
| Week | Activity | Description | Protocols |
|---|---|---|---|
| W1 | Data Quality Audit | Run the AXD Data Maturity Audit (/tools/data-audit). Score your current product catalog. Identify the gap between current maturity and the Transactable threshold (Level 3). | All |
| W1 | AIR Baseline | Run your first Assistant Inclusion Rate test panel (100+ queries, 3 AI surfaces). Establish the discovery baseline before protocol integration changes it. | All |
| W1-2 | Integration Strategy Decision | Apply the decision framework from Section 3.2. Select direct build, aggregation layer, or platform-native. Define your engineering resourcing. | All |
| W2-3 | Schema Markup Completion | Implement or remediate JSON-LD schema markup across your product catalog. Achieve 90%+ required field completeness before proceeding to protocol registration. | UCP, ACP |
| W3 | MCP Tool Audit | Complete the tool and API surface audit from Section 4.3. Define which tools will and will not be exposed via MCP. Document the decision for compliance purposes. | MCP |
First Protocol Live
Weeks 4-7
| Week | Activity | Description | Protocols |
|---|---|---|---|
| W4 | UCP Sandbox Registration | Submit UCP registration. Begin sandbox integration in parallel with registration review. | UCP |
| W4-5 | MCP Server Build | Implement MCP server endpoints for your approved tool surface. Begin with read-only tools before implementing write/transact tools. | MCP |
| W5-6 | UCP Endpoint Build | Implement discovery, cart, and checkout session endpoints. Complete all five mandatory UCP sandbox test scenarios. | UCP |
| W6 | VIC Sandbox Registration | Submit Visa Intelligent Commerce sandbox application. Begin TAP integration review. | VIC |
| W7 | UCP Production Activation | Activate UCP in production. Implement AIR and AACR measurement for UCP-attributed traffic from Day 1. | UCP |
Commerce Protocol Expansion
Weeks 8-12
| Week | Activity | Description | Protocols |
|---|---|---|---|
| W8 | ACP Partner Application | Submit ChatGPT commerce partnership application or enable Shopify Agentic Storefronts if on Shopify Plus. | ACP |
| W8-9 | TAP / Web Bot Auth Integration | Implement Trusted Agent Protocol or Cloudflare Web Bot Auth based on your PSP (Visa or Mastercard network primary). | VIC, Agent Pay |
| W9-10 | ACP Endpoint Build | Build or validate ACP product endpoints. Configure Stripe agent payment rails. Complete ACP sandbox test scenarios. | ACP |
| W10 | CSAS Infrastructure | Stand up server-side event collection and surface-specific UTM parameters for cross-surface attribution. Validate attribution for UCP traffic before ACP goes live. | All |
| W11 | ACP Production Activation | Activate ACP in production. Begin AACR tracking across both UCP and ACP surfaces. | ACP |
| W12 | Full Stack Review | Review AIR, AACR, and CSAS across all live surfaces. Identify optimisation priorities for the next 90-day cycle. | All |
Success Metrics for the 90-Day Roadmap
The following AXD Metrics Standard KPIs should be in place by the end of Week 12:
Assistant Inclusion Rate (AIR)
Baseline established Week 1. Measurable improvement from pre-integration baseline by Week 12. Target: 25%+ (Proficient tier).
Measurement timing: Weeks 1, 7, 12
Agent-Assisted Conversion Rate (AACR)
First measurement Week 7 (post-UCP activation). Target: 0.5%+ by Week 12 (Developing tier), rising to 2%+ within 90 days of ACP activation.
Measurement timing: Weeks 7, 12
Cross-Surface Attribution Score (CSAS)
Infrastructure in place by Week 10. Initial measurement Week 12. Any score above 20% is a valid starting point at this stage.
Measurement timing: Week 12
Regulated industry considerations
Protocol implementation in financial services, healthcare, insurance, and other regulated sectors requires additional design work beyond the standard integration walkthroughs. Regulation was written for human-initiated transactions. Agentic commerce is a genuinely new transaction model, and the regulatory frameworks are catching up in real time.
FCA Consumer Duty and agentic commerce
FCA Consumer Duty requires firms to deliver good outcomes for retail customers. When an AI agent is the entity taking action on behalf of the customer, the question becomes: whose duty is it? The AXD position, consistent with the FCA's emerging thinking on AI: Consumer Duty obligations follow the customer relationship, not the channel. Firms deploying or integrating with agents retain Consumer Duty obligations for outcomes delivered by those agents.
SM&CR and agent authority
Under SM&CR, Senior Managers bear individual accountability for decisions in their area of responsibility. The current UK regulatory position treats agent-initiated decisions as falling within the accountability of the Senior Manager who approved the deployment. The delegation design of your agentic system is not just a UX question - it is an SM&CR accountability architecture question.
UK GDPR and the Data Use and Access Act 2025
Agents that accumulate personal data about consumers across sessions create data retention obligations, right-to-erasure obligations, and data minimisation requirements. For MCP implementations in regulated contexts: tools accessing personal data must implement explicit consent architecture, agent memory data must be subject to DSAR access rights, and cross-border data flows through non-UK servers require data transfer safeguards.
Post-purchase agentic design
The current protocol ecosystem is primarily optimised for the discovery-to-checkout journey. Post-purchase agentic design - returns, disputes, subscription lifecycle management, loyalty redemption - is the next frontier and is significantly underspecified in current protocol documentation.
Agent-initiated returns
Three design questions arise: authority verification (does the agent have return authority, or was only purchase authority delegated?), return reason attribution (structured return reason signals for product quality analysis), and refund routing (refunds back to agent-initiated payment tokens require the same tokenised infrastructure as the original purchase).
Agent-initiated disputes
Both Visa and Mastercard are actively working on dispute resolution frameworks for agent-initiated transactions. Agent-initiated transactions are subject to the same dispute rights as human-initiated transactions, and firms must not design systems that waive consumer dispute rights as a condition of using an agent checkout.
Related resources
AXD Metrics Standard
Seven canonical KPIs for measuring agentic commerce performance.
AXD Data Maturity Score
Five-level scored assessment of product data readiness for agent commerce.
Protocol Tracker
Real-time tracking of protocol specification versions across all six protocols.
12 AXD Practice Frameworks
The complete suite of AXD design frameworks referenced throughout this document.
The Four Pillars of AXD Readiness
Strategic readiness framework: Signal Clarity, Reputation via Reliability, Intent Translation, Engagement Architecture.
AXD Manifesto
The founding principles of Agentic Experience Design.
Frequently asked questions
About This Document
AXD Protocol Lab v1.0 - April 2026. Written by Tony Wood, Founder, AXD Institute, Manchester, United Kingdom.
This document will be revised as the agentic commerce protocol stack evolves. Consult the Protocol Tracker for current specification versions. The AXD Institute makes no warranty regarding the continued accuracy of specific protocol specifications beyond the publication date.