Last week @benjifisher published a sharp piece on agentic commerce's messy middle — the trust, verification, and liability layer between "found it" and "bought it." His conclusion: the middle is mostly unbuilt.

We have 30 days of production data that says otherwise. Not a demo. Not a sandbox. A live Dutch perfume store with 40,000 SKUs, real pricing, real tax, real wallet debits. Here is what actually happened.

The numbers

• €1,269 in AI-driven revenue — last 30 days
• 39 completed orders via AI agents
• €32.54 average order value per AI transaction
• 76.5% session conversion — 39 of 51 agent sessions resulted in a completed order
• 1.5 average calls per session — the spec benchmark is 4 (list → create → update → complete)

That last number is the one I want to focus on.

1.5 calls per session means agents are skipping steps

The UCP spec optimised benchmark is 4 tool calls for a complete purchase: list products, create checkout, update checkout, complete checkout. Our agents are averaging 1.5.

That is not agents failing — it is agents that have already done discovery in a prior session arriving with intent and going straight to checkout. The /agents.md instruction layer we shipped two weeks ago is working: agents are reading the operating manual on first visit and not re-reading it on every subsequent transaction.

The messy middle does not look messy when the protocol is clean and the instructions are explicit.

Who is actually buying

Eight distinct agents hit the store in 30 days. Here is what the agent table shows:

The most interesting row is Unknown Agent — 13 sessions, 2.2 avg calls, at or below target. An agent we cannot identify by name is transacting against the store efficiently and repeatedly. It found the /.well-known/ucp manifest, parsed the capability declarations, and is completing purchases without any integration work on our side.

That is the protocol working exactly as designed.

UCP Playground is the only agent above benchmark at 5 calls — that is Ben's testing environment running full end-to-end validation sessions including the identity linking flow. Expected noise, not a problem.

What the messy middle actually looked like

Building to this point was not clean. The first fully autonomous purchase — WooCommerce order #82251 on March 25 — took 24 hours of debugging across two people. The failures were specific:

Idempotency key formatting. Claude kept sending meta as a stringified JSON object instead of a proper nested object. Fixed at the orchestrator level by auto-injecting the key shape.

Wallet instrument ID vs handler name. The store's validator accepted com.terrawallet.store_credit (the handler name) but rejected terrawallet-1 (the instrument ID). Two different identifiers, one lookup path, one silent failure mode.

Stale OAuth sessions. Merchant-side token revocation was not being detected. Agents were holding expired Bearer tokens and getting 401s with no clear recovery path. Fixed by adding token validation on connect and auto-clearing on 401.

MCP endpoint override. Our Shopify storefront probe was overriding the manifest endpoint. OAuth tokens were stored against /api/mcp but MCP calls were going to /wp-json/ucpready/v1/mcp. One endpoint mismatch, zero successful completions until found.

Each of these was a real failure that blocked real purchases. The protocol did not hide them — the session data captured every one. Observability is what made them fixable.

What 76.5% conversion means in context

Human checkout conversion on e-commerce averages 2-4%. Mobile is lower. Even high-performing stores rarely exceed 5% on cold traffic.

76.5% is not comparable to human checkout conversion — agent sessions are intentional by definition, not browsing. But it does tell you something about friction. An agent that reaches create_checkout on a well-implemented UCP endpoint completes the purchase 76.5% of the time. The failures are mostly discovery sessions (UCP Directory Verifier, UCP Checker) that never intended to purchase.

Strip out the pure discovery sessions and the completion rate is higher.

The small retailer readiness tax — revisited

Paul do Forno at Deloitte posted last week that smaller retailers face a "hidden agentic readiness tax" — perfect catalog data as table stakes, deep system access creating data leakage risk.

The data above is from a small Dutch retailer. Not a platform. Not an enterprise. A WooCommerce store. The tax is real — it took months of development to get here — but the output is 39 AI-driven orders and €1,269 in revenue in 30 days that would not have existed otherwise.

The readiness tax is a one-time cost. The revenue is recurring.

What comes next

The 13 Unknown Agent sessions are the most interesting data point we have right now. An unidentified agent found this store, parsed the protocol, and is transacting repeatedly. We do not know where it came from. That is the network effect of an open protocol — you do not have to be listed anywhere specific. You publish a conformant /.well-known/ucp manifest and agents find you.

The next milestone is identifying that agent and understanding its mandate scope. If it is running AP2 autonomous purchasing without an explicit buyer confirmation step, the audit trail is the only thing standing between "it worked" and "it bought the wrong thing." That is the observability layer Ben is right about — not a theoretical need, a live operational requirement.

The middle is not unbuilt. It is early, it is messy to get right, and it generates real revenue when you do.

---

UCPReady is the WooCommerce plugin behind this data. The AI Agent Analytics dashboard is a Pro feature. houseofparfum.nl is the live reference store — the manifest is at houseofparfum.nl/.well-known/ucp.

If you want to see where your WooCommerce store stands: ucpchecker.com