And what happened when I tested the alternative
The first wave of "AI commerce" products is arriving. And most of them are built on the wrong foundation.
I've spent the last few months building UCPReady — a WooCommerce plugin that implements the Universal Commerce Protocol directly on-site, with no external platform dependency. During that process I've been watching how others are approaching the same problem.
Last week I tested UCPhub's public demo at app.ucphub.ai/demo/chat.
Here's what I found.
The Demo
I asked it to find Chanel perfume. It returned: "No products found."
The demo catalog only contains UCPhub's own branded merchandise — a wristband, a lanyard, a sticker. So I asked it to buy a Ceramic Desk Mug instead. It got to checkout. Order created. Total $15.00. Buyer: X X / x@x.xxx.
Then this appeared in the UI:
Error: {"type":"error","sequence_number":2,"error":{"type":"tokens",
"code":"rate_limit_exceeded","message":"Rate limit reached for gpt-4o
in organization org-mJqVnYWAifRG1IXiIUrFvuSC on tokens per min (TPM):
Limit 30000, Used 24847, Requested 10827. Please try again in 11.348s."}}
A raw OpenAI rate limit error. Exposed directly in the production UI. On their own demo catalog.
This is not a criticism of UCPhub as a company — they're building in a genuinely hard space and they're early. But this error reveals something important about the architectural choice they've made.
Two Architectures
There are two ways to connect a WooCommerce store to AI agents.
Architecture 1: Platform middleware
AI Agent → SaaS Platform → Shared API Keys → Merchant Store
This is the UCPhub model. Your store's data is ingested by their platform, normalized, and served to agents through their infrastructure. The agent never talks directly to your store.
Architecture 2: On-site protocol
AI Agent → /.well-known/ucp → WooCommerce Store
This is the UCPReady model. The agent discovers your store's capabilities directly from your server via a protocol-compliant manifest. No intermediary. No shared infrastructure.
Why Middleware Creates Problems at the Agent Layer
The rate limit error in UCPhub's demo isn't a bug. It's a structural consequence of the architecture.
When you run a shared platform, every merchant's agents compete for the same API budget. At demo scale with a handful of users, you hit GPT-4o's TPM limits. At production scale — hundreds of merchants, each with agents running multiple sessions simultaneously — this becomes a fundamental capacity problem.
This is before considering:
Order caps. UCPhub's pricing tiers limit orders to 50, 200, or 500 per month via AI channels. An AI agent doesn't know it's about to exceed your plan limit. Your store just stops being agent-accessible.
Platform dependency. If UCPhub's infrastructure goes down, your store disappears from every AI agent that uses their platform. With on-site UCP, your store is only down when your store is down.
Merchant-of-record risk. When a third-party platform sits between the agent and your checkout, questions arise about who controls the transaction. UCPReady's delegate checkout model keeps you as merchant-of-record throughout. The agent creates a session; your WooCommerce checkout processes the payment.
Data residency. Your product catalog, pricing, and inventory leave your server and live on their platform. For merchants with contractual or regulatory data requirements, this matters.
Cost structure. $39.99–$299.99/month, recurring, with order caps. A WooCommerce plugin is a one-time purchase that runs on infrastructure you already pay for.
What the UCP Specification Actually Enables
The Universal Commerce Protocol was designed to avoid exactly this. The /.well-known/ucp manifest is a discovery mechanism — it tells agents what your store can do and how to interact with it directly.
{
"protocol": "ucp/1.0",
"transport": ["rest", "mcp", "embedded"],
"checkout": "delegate",
"signing_keys": "Ed25519"
}
When an agent fetches this manifest from your domain, it gets everything it needs to interact with your store — capability declarations, transport endpoints, signing requirements — without routing through a third party.
This is why on-site MCP transport matters. The agent connects to your store's MCP endpoint directly. Your store processes the request. The agent gets a response. Nothing in the middle.
UCPReady has been independently validated by Benji Fisher / UCPChecker as one of only 8 domains globally declaring REST + MCP + Embedded Checkout in a single manifest. In 32 agent sessions across 4 frontier models (Claude, Gemini, Grok, DeepSeek) on a 40,000+ SKU live store, we recorded a 94% end-to-end checkout success rate.
No rate limit errors. Because there's no shared API key. The agent talks to the store. The store responds.
The Right Question for WooCommerce Merchants
When evaluating any "AI commerce" product, the question isn't does it have a demo. The question is:
Where does the agent actually connect?
If the answer is "to our platform, which connects to your store" — you've introduced a dependency that sits between your business and your customers. That dependency has uptime risk, capacity limits, cost structure, and data implications.
If the answer is "directly to your store via a protocol-compliant manifest" — you own the infrastructure. You own the transaction. You own the relationship with the agent.
One More Thing
UCPhub's demo returned "No products found" for Chanel perfume because their demo catalog doesn't contain Chanel perfume. That's fair — it's a demo.
But it points to a deeper issue with the platform model: the agent is searching UCPhub's normalized representation of your catalog, not your catalog. Any gap between their normalization and your actual data is a gap between what agents can find and what you actually sell.
With on-site UCP, the agent queries your WooCommerce product database directly. There's no normalization layer. No gap. What's in your store is what agents can find.
TL;DR
- SaaS middleware for agentic commerce introduces platform dependency, order caps, shared API rate limits, and data residency issues
- The UCP specification was designed for direct store-to-agent communication
- On-site MCP transport eliminates the intermediary entirely
- UCPhub's live demo hit GPT-4o rate limits mid-session on their own test catalog — a predictable consequence of shared infrastructure
- UCPReady implements UCP directly in WooCommerce: no platform, no order caps, no shared keys, merchant-of-record throughout
UCPReady is a WooCommerce plugin implementing the Universal Commerce Protocol. It's currently in Business Review on the WooCommerce Marketplace. Zologic is an approved WooCommerce Marketplace vendor.
Benji Fisher's independent research: UCPChecker blog · 180 agent sessions study
Top comments (0)