The conversation around agentic commerce has moved quickly over the past twelve months. New protocols are emerging, seemingly every week. AI agents are becoming capable of product discovery, comparison and the arms race continues in which LLM has the edge. The industry is rightly excited about what this means for search, marketplaces and content-driven shopping.

What is striking, however, is how much of the debate stops just before the most important moment: how does an agent actually place a real order?

I’m not talking about a demo pretending and simulating an order. I’ve sat through plenty of demos showing what can only be described as vapourware. I’m talking about a real, merchant-approved transaction that flows into inventory, finance, fulfilment and post-purchase systems without breaking anything.

This is where agentic commerce becomes difficult and the response I hear time and time again is that APIs will solve that or even more absurd that Agents will solve that. 

Discovery is not the hard part

Exposing products and distributing product catalogues is not new. Product feeds have existed for years. Retailers already publish catalogues into Google Shopping, marketplaces, affiliate networks and comparison engines. APIs for products, variants, pricing and availability are commonplace across any ecommerce platform whether that be Shopify, Magento, BigCommerce or custom stacks.

Admittedly it can be and often is a complete mess. There is still work to be done around normalisation and schema consistency, but that is solvable and just engineering focus. AI will certainly help here and some of the protocols are looking to provide unified standards.

The hard part begins the moment intent turns into actually placing the order.

An agent selecting a product is interesting and useful. An agent completing a transaction is operational, some say alarming but a lot of focus by the payment companies is going into the rails and guardrails to achieve this. But payments are not orders. An order only exists when it is created inside the merchant’s system of record with pricing, tax, inventory, fraud and fulfilment logic validated in real time.

Why “Just Create a Cart” is not a strategy

There is a growing assumption that once an agent has selected a SKU, the rest is relatively straightforward. Create a cart somewhere. Apply price and shipping logic externally. Pass the order downstream into the merchant stack once it looks complete. On paper, and by paper I mean some flashy Powerpoint slide, this feels logical and easy.

In practice, it misunderstands how commerce systems actually work.

Every retailer’s stack contains complicated and embedded operational logic. Promotion rules shipping matrices, tax calculations, fraud scoring, inventory reservation, refund handling, settlement reconciliation.

Recreating that logic reliably inside a third-party agent framework would mean duplicating years of operational complexity across thousands of merchants. It would introduce many inconsistencies and reconciliation issues between pricing, stock, tax, promotion, shipping systems. Commerce platforms are the system of record for a reason. Orders need to be created there or at least built in and around them, not simulated elsewhere.

The execution gap

We see agentic commerce in three layers: The first is discovery and intent. The second is decision making. The third is execution.

The first two are receiving enormous attention. The third is being treated as a technical footnote or waved away as something not to worry about. It’s this third layer where shopthru focuses.

Execution determines who remains Merchant of Record. It determines where attribution is captured. It determines how payment is authorised and settled. It determines whether inventory is correctly reserved and whether refunds reconcile cleanly. Without a robust execution layer, agentic commerce remains theoretical.

This is the gap ACEL is designed to address.

What ACEL is

ACEL stands for Agentic Commerce Execution Layer.

It is not a protocol. It does not attempt to replace UCP, MCP, ACP or any emerging standard. It does not compete at the discovery layer. It is deliberately protocol-agnostic and sits downstream of intent.

Its role is to take validated purchase intent from an agent and turn it into a real, compliant order inside the merchant’s own commerce platform. The merchant platform remains the system of truth. Pricing, promotions and inventory are validated live. Payment runs through existing enterprise PSP rails. The order flows into the merchant’s OMS and fulfilment stack as normal. Attribution is captured deterministically at the moment of transaction.

There is no shadow checkout engine. No external tax calculator. No duplicated promotion system living outside the merchant’s control. ACEL is an orchestration not a simulation, not an imitation.

The commercial impact of owning the execution

In redirect-based commerce, and by that I’m talking about the traditional affiliate model, attribution is always a step removed from the transaction. It’s inferred, often overwritten, sometimes hijacked, and increasingly constrained by browser and cookie policy.

But if AI commoditises discovery and checkouts begin to sit inside agent frameworks, the links disappear. And when the link disappears, so does the traditional tracking model.

The real battleground then becomes the moment the order is created.

That moment determines who captures attribution, who controls margin, and who owns the customer relationship. If order creation is abstracted into someone else’s infrastructure, merchants become suppliers to an external checkout. The execution layer is where power settles.

Why Shopthru is building this layer

Shopthru was originally built to solve a related problem. Embedded checkout required us to complete real orders inside publisher environments without breaking the retailer’s operational stack. That meant integrating directly with commerce platforms, respecting merchant-of-record status and using existing payment rails. It meant ensuring orders flowed cleanly into fulfilment and reconciliation systems.

In other words, we had to solve execution before it became fashionable to call it agentic.

ACEL is a natural extension of that work. It formalises the execution layer required for AI-initiated commerce. It abstracts merchant complexity without replacing it. It provides a stable bridge between agent protocols and real commerce infrastructure.

Protocols will continue to evolve. Standards will compete. Discovery models will change. Execution, however, must remain coherent.

Agentic commerce does not need another way to describe products. It needs a reliable way to create orders that merchants trust. ACEL is our answer to that problem.

And in the long term, we think it will prove to be the layer that matters most.