DEV Community: Almin Zolotic

Building the Only UCP Plugin for WooCommerce — Outside the Walled Garden

Almin Zolotic — Thu, 09 Apr 2026 17:50:45 +0000

When protocol compliance conflicts with platform policy, independence stops being a limitation and becomes a feature that enables full execution.

Two months ago, AI purchasing landed on Shopify, and within hours a WooCommerce store completed a fully autonomous transaction without any human interaction.

That store was running UCPReady, a plugin that turns WooCommerce into a Universal Commerce Protocol endpoint for AI agents to transact directly.

Today, UCPReady is the only WooCommerce plugin with full UCP 2026-04-08 compliance, running in production and processing real autonomous orders.

What Makes It Different

UCPReady is not a partial implementation or a demo layer, but a complete protocol-native system designed for real autonomous commerce flows.

Full Universal Commerce Protocol 2026-04-08 compliance across all required surfaces and behaviors
Support for REST, MCP, and Embedded Checkout transports without fallback compromises
Autonomous AI purchasing with no human confirmation step required at checkout
Schema Quality rating of A (99) verified through independent validation tools
Spec updates shipped within 24 hours from release to production deployment

This is production commerce running on an open protocol rather than a controlled integration.

Why It’s Not in the Marketplace

Open protocols sometimes introduce requirements that do not align with existing marketplace rules designed for traditional plugin behavior.

UCP requires that checkout execution completes fully when invoked, including payment processing, instead of redirecting to manual confirmation flows.

Marketplace policies, reasonably, enforce strict controls around autonomous payment execution for security and user protection reasons.

That creates a structural mismatch between protocol requirements and platform rules rather than a simple review outcome.

The decision becomes whether to adapt the protocol to fit the platform or preserve the protocol and distribute independently.

UCPReady chose to preserve the protocol as designed.

Core Difference in Approach

WooCommerce is building AI capabilities focused on merchants managing their stores through internal tools and administrative workflows.

UCPReady focuses on the opposite side of the interaction, where AI agents act on behalf of users to discover and purchase products.

These approaches are not competing implementations, but they operate at completely different layers of the commerce stack.

Why Independence Works Better

Operating outside the marketplace enables faster iteration cycles that match the pace of protocol evolution without external approval delays.

Full compliance can be maintained without introducing exceptions, fallbacks, or behavior changes that fragment the protocol surface.

Support becomes direct and immediate, without reliance on layered support systems or delayed release cycles.

Merchants get a transparent product with clear capabilities instead of features shaped by policy constraints.

The Trade-off

You do not get marketplace distribution, automatic updates, or official platform endorsement through the standard channels.

You do get full protocol compliance, rapid updates, direct support, and a system designed for autonomous AI commerce from the ground up.

This is a trade between convenience and capability rather than a limitation of the implementation.

Standards vs Platform Deals

Platform integrations are fast to deploy but inherently limited by agreements, approvals, and ecosystem boundaries.

Open protocols are slower to standardize but enable interoperability across platforms, agents, and implementations without restriction.

UCPReady is built on the assumption that standards will outlast individual platform deals.

What This Means

If you want your WooCommerce store to be accessible to AI agents for real autonomous purchasing, this capability exists today.

It does not require waiting for platform updates, partnerships, or future roadmap features to become available.

It requires adopting a protocol-first approach that operates outside traditional distribution models.

Final Note

Some innovations do not fit inside existing systems because those systems were designed for a different generation of use cases.

Autonomous AI commerce is one of those cases, and open protocols are where that shift is currently happening.

UCPReady exists outside the marketplace because that is currently the only place it can fully exist without compromise.

🔗 Try UCPReady

💼 Almin Zolotic on LinkedIn

WooCommerce Just Did What Shopify Did — Hours Later, Open Protocol, Full Autonomous Purchase

Almin Zolotic — Wed, 25 Mar 2026 09:31:08 +0000

Shopify announced AI-powered purchasing in ChatGPT this morning. Six hours later, a WooCommerce store completed a fully autonomous AI purchase — identity linked, wallet debited, order in processing — using an open protocol anyone can implement.

No partnership deal. No platform exclusivity. Just a spec, a plugin, and a real order.

What happened this morning

At 09:37 AM today, an AI agent (Claude Sonnet 4.5) completed an autonomous purchase on houseofparfum.nl, a 40,000 SKU WooCommerce perfume store.

Here's the full session replay:

UCPPlaygroundhouseofparfum.nl via Claude Sonnet 4.5 - UCPPlayground

Checkout Reached in 43.6s. Watch the full agent session replay.

ucpplayground.com

What the agent did, without any human intervention:

Searched for a perfume under €30
Created a checkout session
Selected the Terrawallet wallet payment instrument (surfaced from the linked identity)
Selected flat-rate shipping
Called complete_checkout with an idempotency key
The wallet was debited €22.93
WooCommerce order #82244 was created with status processing

8 turns. 79,152 tokens. Schema Quality: A (99).

The difference from Shopify

Shopify's ChatGPT integration is impressive. But it's a bilateral deal between two platforms. Shopify stores work in ChatGPT. That's it.

What happened today uses the Universal Commerce Protocol (UCP) — an open specification that any store, any agent, and any platform can implement independently.

The same flow that worked in UCPPlayground today will work in any UCP-compliant agent host. Claude, GPT, Gemini, Grok — any model. Any platform that implements the MCP transport binding can discover houseofparfum.nl's capabilities, link buyer identity, and complete a purchase.

No bilateral agreement required. No platform partnership. Just a spec.

What makes this technically interesting

Identity linking — the agent authenticated via OAuth 2.0 Authorization Code + PKCE against the store's own OAuth server (RFC 8414, RFC 7591). The bearer token resolved to WooCommerce customer ID 1. Name, email, phone, billing address, shipping address — all pre-populated from the WC account. The agent never asked for any of it.

Autonomous payment — Terrawallet store credit was surfaced as a payment instrument because the linked identity had a wallet balance. The agent selected it, called complete_checkout, and the wallet was debited server-side. No browser redirect. No payment form. No human in the loop.

UCP protocol compliance — every response carried ucp.capabilities in the correct keyed-object format. The MCP transport binding used bare tool names (complete_checkout, not ucp_complete_checkout). The idempotency store prevented duplicate orders on retry. Schema Quality A (99) from UCPChecker.

The stack

Plugin: UCPReady (FREE WooCommerce plugin by Zologic)
Protocol: Universal Commerce Protocol 2026-01-23
Transport: MCP (Model Context Protocol) JSON-RPC 2.0
Test platform: UCPPlayground by Ben Fisher / UCPChecker
Store: houseofparfum.nl (live production, 40k+ SKUs, Redis)

UCPReady was validated by Ben Fisher (UCPChecker) as "the most spec-complete non-Shopify UCP implementation tested." It also exposed 4 bugs in the UCPPlayground embedded checkout during interop testing — all fixed the same day.

What this means for WooCommerce merchants

If you run a WooCommerce store today, you are one plugin install away from being discoverable and purchasable by any AI agent that implements UCP.

Not "AI-assisted checkout." Not "AI product recommendations." Fully autonomous purchase — the agent finds the product, builds the session, collects buyer details from linked identity, selects payment, and completes the order. You get a WooCommerce order in processing status, attributed to the linked customer account, with full order history.

The same infrastructure that powers Shopify's ChatGPT integration — agentic discovery, session management, identity linking, autonomous payment — is now available to every WooCommerce store via an open protocol.

What's next

Ben Fisher is adding multi-item cart flow to UCPPlayground today. The cart capability (dev.ucp.shopping.cart) is already declared in houseofparfum.nl's /.well-known/ucp manifest and the tools are live. Once the Playground wires up the cart flow, agents will be able to browse, build multi-item carts, compare products, and convert to checkout — the full pre-purchase exploration flow.

The UCP Technical Committee nomination window closes April 3. If you're building on UCP or have a perspective on how the protocol should evolve, now is the time to get involved: https://github.com/Universal-Commerce-Protocol/ucp

Try it

Live store endpoint: https://houseofparfum.nl/.well-known/ucp
UCPPlayground: ucpplayground.com — connect houseofparfum.nl and run your own session
UCPReady: https://zologic.nl/product/ucpready-ai-agent-commerce-for-woocommerce/
UCP Spec: ucp.dev/latest/specification

UCPReady is built by Zologic. The autonomous purchase milestone was achieved in collaboration with Ben Fisher (UCPRails/UCPPlayground/UCPChecker) who has been validating UCP implementations across the ecosystem.

Why your WooCommerce AI Agent endpoint is slow (and how we fixed it in 30 lines)

Almin Zolotic — Tue, 24 Mar 2026 16:23:28 +0000

Published by Almin Zolotic — Zologic / UCPReady

We spent most of yesterday debugging an 8-second ucp_list_products response on a live WooCommerce store with 40,000+ SKUs. The fix was 30 lines of PHP. Here's the full investigation — every dead end included — because anyone building on WooCommerce + UCP is going to hit this.

The setup

houseofparfum.nl runs UCPReady — our WooCommerce plugin that implements the Universal Commerce Protocol (UCP) over REST, MCP, and Embedded Checkout. It's been running in production since February, and UCP Playground benchmarks consistently showed ucp_list_products taking 8,432ms.

That's not a typo. Eight seconds. On every cold session.

For context: Shopify's median MCP tool call latency is 146ms. An AI agent making 4-5 tool calls in a session at 8 seconds each is going to hit platform timeouts. Sessions fail. Purchases don't complete.

We needed to find and fix the root cause.

Eliminating suspects

Suspect 1: The database query

First thing to check — is the WooCommerce product query slow?

wp eval '
$start = microtime(true);
$results = wc_get_products([
    "status" => "publish",
    "limit" => 10,
    "paginate" => true,
]);
echo "Query: " . round((microtime(true) - $start) * 1000) . "ms\n";
echo "Total: " . $results->total . "\n";
' --allow-root

Result: 159ms for 38,433 products. Fast. Not the problem.

Suspect 2: Product transformation

UCPReady transforms WC_Product objects into UCP format on each request. How long does that take for 10 products?

wp eval '
$adapter = UCPReady\Adapters\ProductAdapter::get_instance();
$results = wc_get_products(["status" => "publish", "limit" => 10]);
$start = microtime(true);
foreach ($results as $product) {
    $adapter->to_ucp_list_format($product);
}
echo "Transform: " . round((microtime(true) - $start) * 1000) . "ms\n";
' --allow-root

Result: 10ms. Not the problem.

Suspect 3: Redis / object cache

The store has Redis installed. Checking if it's actually connected to WordPress:

wp cache type --allow-root
# Redis ✓

wp eval '
$found = false;
wp_cache_get("ucp_product_list_82192", "ucpready", false, $found);
echo $found ? "CACHED" : "NOT CACHED";
' --allow-root
# NOT CACHED

Redis is connected but product list cache keys aren't being populated. Separate issue — but not the 8-second culprit either.

Suspect 4: The taxonomy mapper

UCPReady maps WooCommerce categories to Google Product Taxonomy IDs. This involves loading a 482KB taxonomy file and building an inverted index. Was it rebuilding on every request?

wp eval '
$start = microtime(true);
$mapper = UCPReady\Taxonomy\TaxonomyMapper::get_instance();
$mapper->map_category(17, "en_US");
echo round((microtime(true) - $start) * 1000) . "ms\n";
' --allow-root
# 18ms

18ms cold. Fast. And we fixed the caching here anyway — the built inverted index now persists to Redis with a 6-hour TTL. But still not the 8-second culprit.

The real test: HTTP vs WP-CLI

At this point we noticed something odd. Every WP-CLI test was fast. The same operations over HTTP were taking 8 seconds. WP-CLI has WordPress already loaded in memory. HTTP requests boot WordPress from scratch on every call.

time curl -s -o /dev/null -X POST \
  "https://houseofparfum.nl/wp-json/ucpready/v1/mcp" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"ucp_list_products","arguments":{"limit":5}}}'

# real 0m8.101s

8 seconds over HTTP. 169ms in WP-CLI. The gap is WordPress boot time.

Finding the culprit

The store has 17 active plugins. Something in that list was making every MCP request boot WordPress for 8 seconds. We tested methodically:

wp plugin deactivate google-listings-and-ads --allow-root

time curl -s -o /dev/null -X POST \
  "https://houseofparfum.nl/wp-json/ucpready/v1/mcp" \
  ...

# real 0m0.651s

Google Listings and Ads was adding 7.5 seconds to every single MCP request.

Not because of the product query. Not because of anything UCP-related. The plugin registers expensive hooks during WordPress initialisation that fire on every request — including REST API requests that have nothing to do with Google Shopping feeds.

This isn't a UCPReady problem or even a UCP problem. It's a WooCommerce plugin ecosystem problem. Any plugin that does expensive work on init or similar hooks will slow down every MCP request on every WooCommerce store running it.

The fix: Partial Bootstrap Mode

The solution is a must-use plugin that fires before regular plugins load and removes the offenders from the active plugins list for MCP requests only. Everything else on the store — admin, storefront, Google Shopping feed generation — is completely untouched.

<?php
/**
 * UCPReady MCP Partial Bootstrap
 * Place in /wp-content/mu-plugins/ucpready-mcp-bootstrap.php
 */

if ( ! defined( 'ABSPATH' ) ) { exit; }

$ucpready_skip = array(
    'google-listings-and-ads/google-listings-and-ads.php',
    'query-monitor/query-monitor.php',
    'ajax-search-for-woocommerce/ajax-search-for-woocommerce.php',
);

$ucpready_uri    = $_SERVER['REQUEST_URI'] ?? '';
$ucpready_is_mcp = strpos( $ucpready_uri, '/ucpready/v1/mcp' ) !== false
    || strpos( $ucpready_uri, 'rest_route=/ucpready/v1/mcp' ) !== false;

if ( $ucpready_is_mcp ) {
    add_filter( 'option_active_plugins', function( $plugins ) use ( $ucpready_skip ) {
        if ( ! is_array( $plugins ) ) return $plugins;
        return array_values( array_diff( $plugins, $ucpready_skip ) );
    }, 1 );
}

That's the entire fix. The option_active_plugins filter with priority 1 fires before any plugin's code runs, so the offending plugins never register their hooks at all.

Results

time curl -s -o /dev/null -X POST \
  "https://houseofparfum.nl/wp-json/ucpready/v1/mcp" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"ucp_list_products","arguments":{"limit":5}}}'

# real 0m0.272s

Then we ran a full timing breakdown:

curl -w "DNS:%{time_namelookup} Connect:%{time_connect} SSL:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}\n" ...

# DNS:0.001 Connect:0.001 SSL:0.038 TTFB:0.038 Total:0.267

Server TTFB: 38ms. The remaining ~4.5 seconds in Playground benchmarks is geographic network latency from US/UK servers to the Netherlands — not fixable at the server level.

WooCommerce at 38ms TTFB matches Shopify's performance characteristics. The variable isn't the platform. It's plugin configuration.

What this means for the WooCommerce + UCP ecosystem

This finding applies to every WooCommerce UCP implementation, not just UCPReady. If you're building on WooCommerce + UCP and ucp_list_products is slow, run this diagnostic:

# 1. Baseline with all plugins
time curl -s -o /dev/null -X POST "https://yourstore.com/wp-json/ucpready/v1/mcp" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"ucp_list_products","arguments":{"limit":5}}}'

# 2. Deactivate plugins one by one and retest
wp plugin deactivate <plugin-name> --allow-root
# retest
wp plugin activate <plugin-name> --allow-root

# 3. Once you find the culprit, add it to the mu-plugin skip list

Common suspects beyond Google Listings: any plugin that runs expensive init hooks, external API calls during boot, or complex query modifications that fire on every request.

The broader lesson

AI agents make rapid sequential tool calls. A human tolerates a 3-second page load. An agent making 5 tool calls at 3 seconds each blows through platform timeouts and fails the session. Performance that was "acceptable" for human traffic becomes a hard blocker for agent traffic.

WooCommerce's plugin ecosystem is powerful but it was built for humans, not agents. Every plugin that does expensive boot-time work is a potential agent-killer. The mu-plugin pattern above is the pragmatic fix until the ecosystem catches up.

What we're working on next

The mu-plugin currently requires manual installation. We're adding a performance dashboard to UCPReady's admin settings that measures actual MCP response times, identifies problematic plugins automatically, and provides the mu-plugin as a one-click download when response times are above threshold.

We're also exploring whether it makes sense to report this to the Google Listings and Ads team directly. The fix on their side is a single is_rest_api_request() guard before registering expensive hooks. One line on their end helps every WooCommerce store, not just UCPReady users.

UCPReady is a WooCommerce plugin that implements the Universal Commerce Protocol — turning any WooCommerce store into a fully agent-executable commerce endpoint. Live demo: houseofparfum.nl | Plugin: zologic.nl

If your WooCommerce store is slow for AI agent traffic, I offer agent readiness audits. Reach out at contact@zologic.nl

How I Built Autonomous AI Purchasing on WooCommerce: OAuth 2.0, Identity Linking, and Wallet Payments

Almin Zolotic — Sun, 22 Mar 2026 12:57:11 +0000

An AI agent searched a 40,000-SKU store, identified a product, pre-populated the buyer's details from a linked identity, debited a wallet, and created a paid WooCommerce order — with zero human interaction after the initial consent screen.

This is what I built this week. Here's how it works.

The Problem: AI Agents Can't Authenticate as Customers

AI agents can already browse your store, read product listings, and build a cart. That part is solved by protocols like UCP (Universal Commerce Protocol) and MCP (Model Context Protocol).

But the moment an agent tries to actually complete a purchase, it hits a wall:

Whose account is this order going on?
What's the shipping address?
How does the agent pay without a browser redirect?

The standard answer is: surface a continue_url and make the human finish the job in a browser. That's not agentic commerce — that's just a fancy product search with extra steps.

The real problem is identity. The agent doesn't know who it's acting for, and the store doesn't know who the agent represents.

The Solution: OAuth 2.0 Identity Linking

The draft UCP spec (version 2026-03-14) introduces a capability called dev.ucp.common.identity_linking. The mechanism is OAuth 2.0 Authorization Code flow with PKCE, where the AI agent platform is the OAuth client and the WooCommerce store is the authorization server.

The flow in plain English:

Agent platform discovers the store's capabilities via /.well-known/ucp
Sees that the store supports identity linking via OAuth 2.0
Discovers the OAuth server metadata endpoint (RFC 8414)
Initiates an authorization request — the customer sees a consent screen
Customer approves once — agent platform receives a bearer token
Every subsequent API call includes that token
The store resolves the token to a WC customer account and pre-populates all buyer data automatically

After consent, every checkout session created with that bearer token automatically has the customer's name, email, billing address, shipping address, and available store credit surfaced as a payment instrument — without the customer doing anything.

The customer approves once. After that, the agent can complete purchases autonomously until the token expires or the customer revokes access.

What I Built: UCPReady

UCPReady is a WooCommerce plugin that implements the full UCP spec including identity linking. The key components:

A complete OAuth 2.0 authorization server inside WordPress — dynamic client registration, Authorization Code + PKCE S256, refresh token rotation, token revocation with cascade revocation on account events, and RFC 8414 server metadata. All rendered server-side, no external dependencies.

Identity resolution — bearer token resolves to a WC customer automatically. Checkout sessions created with a valid token have buyer data pre-populated without any additional calls.

Connected Agents tab in My Account — customers see every agent platform that has access, when it was granted, when it expires, and can revoke any of them with one click.

Automatic token revocation — tokens are cascade-revoked automatically when a customer changes their password, updates their account, or deletes their account. No stale access.

The Result

Here's what actually happened on houseofparfum.nl — a live WooCommerce store with 40,000+ SKUs:

Agent platform connected to the store via MCP
Customer linked identity via the OAuth consent screen (one click, one time)
Agent searched the catalog, found the product, created a checkout session
Buyer details pre-populated automatically from the linked account
Shipping method selected, wallet balance surfaced as payment option
Agent completed the purchase — wallet debited server-side
WooCommerce order created, status: Processing, customer: linked account, attribution: agent platform

No browser. No redirect. No human interaction after the initial consent.

What the Store Owner Sees

Orders placed by AI agents appear in WooCommerce exactly like any other order — but with full attribution:

Status: Processing (paid)
Customer: the linked WC account, not Guest
Order attribution: the agent platform hostname that placed the order
UCPReady Analytics: revenue breakdown by AI platform, order count, average order value

Every agent that has ever been granted access is visible and revocable by the customer. No black boxes.

The Wallet Payment

When a customer has store credit and their identity is linked, the wallet balance is surfaced automatically in the checkout response as an available payment instrument. The agent sees it, selects it, and calls complete_checkout. The payment is processed entirely server-side — no Stripe, no card network, no browser redirect.

This works with any WooCommerce wallet plugin that exposes a programmatic debit API. We tested with TeraWallet.

UCP Playground Validation

Ben Fisher's UCP Playground — the primary tool for testing UCP compliance — now has a "Link Identity" button. When pointed at houseofparfum.nl, it discovers the identity linking capability, triggers the OAuth flow, and renders our consent screen correctly.

Schema Quality score: A (98).

The Playground currently stops at checkout creation — full autonomous completion from the Playground requires Ben to add payment instrument selection to the runtime. That's the next step on his end.

What's Missing (Honest Assessment)

Playground autonomous completion — identity linking and checkout creation work end to end via the Playground. Full completion requires payment instrument selection in the Playground runtime, which isn't there yet.

Attribute-based disambiguation — the flow assumes the agent can identify exactly which product to buy. "The blue one, size M" requires variant resolution before checkout. That's an agent-side problem, not a protocol problem.

AP2 for non-wallet payments — for stores without store credit, completing payment without a browser redirect requires an AP2-compatible payment processor. Store credit / wallet is the cleanest path today. Card payments without browser redirect are the next frontier.

Try It

The live UCP discovery endpoint: https://houseofparfum.nl/.well-known/ucp

The OAuth server metadata: https://houseofparfum.nl/.well-known/oauth-authorization-server

If you're building an agent platform and want to test identity linking against a live WooCommerce endpoint, both are open. Point your runtime at the discovery endpoint and the rest is spec-compliant.

UCPReady runs on any WooCommerce store. Available at zologic.nl.

The Bigger Picture

Identity linking is the piece that turns AI agents from "helpful product finders" into actual autonomous purchasing agents. Without it, every agentic commerce flow ends with "here's the checkout URL, go finish it yourself."

With it, the agent can complete the entire transaction — discovery, identity, payment, order creation — without the customer ever opening a browser after the first consent.

The UCP spec is still in draft on this capability (2026-03-14). But the implementation is live and working today on a real store.

UCPReady is built by Almin Zolotic at Zologic. The live test store is houseofparfum.nl.

Want this on your store?

UCPReady is available at zologic.nl/ucpready — €149/year, instant download, works on any WooCommerce store.

Tags: #woocommerce #ai #webdev #opensource

Y Combinator validates ideas. Nobody validates adoption. Here's what I built instead.

Almin Zolotic — Sun, 15 Mar 2026 15:30:50 +0000

By Almin Zolotic — Founder of Zologic, City Shower, and Market Physics Engine

The validation that didn't save me

In 2020 I was living in a vacant school in Rotterdam after a divorce wiped out everything I had built. During that period I noticed something obvious that nobody was solving: tens of thousands of homeless people in the Netherlands couldn't access a shower. Not because showers didn't exist — because access was fragmented, gatekept, and invisible.

I built City Shower. A network of accessible hygiene facilities for people living on the streets.

I validated it the way every startup course tells you to. I talked to people. Social workers, shelter managers, municipal health officers, community leaders, entrepreneurs. Every single one said it was needed. Many said it was overdue.

I had positive signals everywhere.

And then I ran into a wall that no interview had prepared me for.

Regulatory friction. Switching costs embedded in institutional processes. Trust infrastructure that didn't exist yet between gyms, municipalities, and social services. The idea was sound. The adoption pathway was blocked.

Nobody's survey had told me that. Because surveys don't measure adoption. They measure intent. And Kahneman proved decades ago that intent and behavior are not the same thing.

That gap — between "people say yes" and "people actually adopt" — is where most startups die. And almost nobody is measuring it.

What traditional validation actually measures

The lean startup canon — customer interviews, problem validation, demand testing — is built on a flawed assumption: that what people tell you they will do predicts what they will actually do.

It doesn't.

Daniel Kahneman and Amos Tversky's Prospect Theory (1979) showed that human decision-making is not rational utility calculation. Losses loom approximately twice as large as equivalent gains. The friction of changing behavior is systematically underweighted by the people experiencing it — and almost completely invisible in an interview context, where social pressure to be supportive overwhelms honest friction assessment.

Y Combinator's application asks: "What do you understand about your business that other companies in it just don't see?"

It doesn't ask: "What structural friction stands between your idea and the people who will need to change their behavior to adopt it?"

Lean startup asks: "Have you talked to customers?"

It doesn't ask: "Have you modeled the regulatory environment your regulator is operating in, the switching cost your operator faces, or the trust infrastructure your early adopter needs before they convert?"

These are different questions. The first set measures whether your idea sounds good in a room. The second set measures whether it will actually spread in a market.

There's another problem nobody talks about: the people who will kill your idea don't show up to customer discovery sessions.

Regulators don't attend your user interviews. Risk officers don't fill in your survey. Institutional gatekeepers don't book a 30-minute call on Calendly. They show up after you've scaled — and by then you've already built the wrong thing in the wrong way.

So I built a simulator

After City Shower, after founding Zologic, after shipping UCPReady (an AI agent commerce plugin for WooCommerce, currently in WooCommerce Marketplace business review) — I kept running into the same pattern. Good ideas. Real problems. Structural friction that surveys didn't surface until after significant time and money had been spent.

So I built Market Physics Engine.

Not another survey tool. Not another AI that asks you questions and gives you generic feedback. A behavioral simulation engine that treats adoption as a physics problem — where perceived value competes against structural friction across a heterogeneous population of decision-makers.

Here's the conceptual architecture:

Step 1 — Generate the full stakeholder ecosystem

You submit your pitch. The engine generates 12 stakeholder personas covering every role that influences adoption: consumer, buyer, operator, supplier, regulator, investor, ecosystem partner, technical evaluator, early adopter, skeptic analyst, risk officer, and public stakeholder.

Each persona is scored across two competing forces:

Value drivers — functional utility, emotional motivation, social signaling, market timing, ecosystem readiness

Friction drivers — cognitive cost (switching effort, learning curve), perceived risk (financial, regulatory, technical), and regulatory burden

The scoring is role-specific and grounded in documented behavioral patterns for each archetype. A regulator looks nothing like an early adopter. A risk officer's friction profile is structurally different from a consumer's. The engine enforces this — it doesn't let every persona converge on the same generic scores.

Step 2 — Simulate a heterogeneous population

Each persona seeds a population of synthetic agents with behavioral variation drawn from the persona's scores. The population is designed to be heterogeneous — capturing the full distribution of real market behavior, including the resistant tail that single-point estimates miss entirely.

This is grounded in Monte Carlo simulation methodology. No single persona represents a market. The variance matters as much as the mean.

Step 3 — Run network diffusion across 12 market periods

Agents don't respond to a global market signal. They respond to their immediate network — consistent with Watts-Strogatz small-world topology research and how platform adoption actually propagates in the real world.

Adoption cascades locally before reaching the broader population. This produces tipping points rather than smooth growth curves — which is exactly what you see in every major platform market that has ever succeeded or failed.

The simulation runs across 12 sequential periods, separating innovator adoption from imitator adoption — consistent with Bass Diffusion Model dynamics documented across decades of empirical platform research.

Friction variables are weighted asymmetrically throughout — consistent with Prospect Theory. A blocker's resistance costs more adoption probability than an equivalent level of enthusiasm generates. This is not an assumption. It is empirically documented.

Step 4 — Output you can actually act on

Idea Fitness Index (IFI) — a composite behavioral fitness score
Adoption curve — 12-period S-curve with period-by-period growth rate overlay
Friction profile — Cognitive, Risk, and Regulatory breakdown per persona
Benchmark comparison — your curve overlaid against empirical anchors for Airbnb, Uber, Stripe, and Slack
Stakeholder sentiment — 12 personas classified as supporters, skeptics, or blockers with behavioral reasoning

What this looks like on a real pitch

I ran the Airbnb pitch through the engine:

"A two-sided marketplace where homeowners rent out spare rooms or entire properties to travelers seeking affordable, local accommodation alternatives to hotels."

Output:

IFI: 0.53 — Scalable opportunity
Adoption Probability: 78.5%
Majority adoption at: Period 6
Closest benchmark match: Airbnb
Dominant friction: Risk and Regulatory

The friction profile surfaces exactly what actually happened to Airbnb in their early years — not consumer demand failure (demand was high from day one), but regulatory and trust infrastructure friction that consumed enormous operational energy before the product could scale.

The personas that dragged the score were the regulator and the risk officer — both high on regulatory burden and perceived risk, both structurally resistant to a trust-dependent two-sided marketplace entering an unregulated category.

What traditional validation told founders about Airbnb in 2008:

Travelers want cheaper accommodation ✓
Homeowners would consider renting their space ✓
Waitlist filled up quickly ✓

What it missed:

The regulatory cascade that would define Airbnb's next decade. The trust infrastructure they'd have to build from scratch. The institutional friction that doesn't appear in any customer interview because the people carrying that friction don't attend customer interviews.

Market Physics surfaces that friction in 60 seconds, before you spend a cent building toward it.

The same friction model applied to my own work

I ran the UCPReady pitch through Market Physics before submitting to the WooCommerce Marketplace.

UCPReady makes WooCommerce stores transactable by AI agents via the Universal Commerce Protocol — REST, MCP, and embedded checkout in one plugin. It's the infrastructure layer that lets AI agents shop your store the way a human would, without scraping or hallucinating product data.

The simulation told me exactly where the friction would concentrate: the institutional regulator persona (WooCommerce's own review process), the technical evaluator (merchant-developers who need spec compliance proof before adoption), and the skeptic analyst (merchants who've heard "AI will change everything" too many times).

It concentrated there. The WooCommerce Marketplace business review has been ongoing since February. The technical evaluator friction resolved through independent third-party testing (UCPReady was cited as the most spec-complete non-Shopify UCP implementation tested across 180 real agent shopping sessions). The skeptic analyst friction is resolving through publishing — this article being part of that.

That's not a coincidence. That's the model working.

The honest comparison

	YC Application	Lean Startup	Market Physics
Measures stated intent	✓	✓	—
Measures behavioral adoption probability	—	—	✓
Surfaces regulatory friction pre-build	—	Rarely	✓
Models network diffusion dynamics	—	—	✓
Captures the resistant tail	—	—	✓
Requires access to real humans	✓	✓	—
Takes weeks	✓	✓	—
Takes 60 seconds	—	—	✓
Grounded in behavioral economics	Partially	Partially	✓
Benchmarks against empirical historical data	—	—	✓

Market Physics doesn't replace customer discovery. Talking to real humans is irreplaceable — you learn things about context, language, and emotion that no simulation captures.

What it replaces is the false confidence that intent data gives you. The "everyone I talked to loved it" that precedes so many failed launches.

Run the simulation first. Then go talk to the persona the simulation identified as your biggest blocker.

That conversation will be completely different from a generic customer interview — because you'll know exactly what friction to probe for before you walk in the room.

Try it

marketphysics.eu — free tier, 3 simulations. No credit card.

Run your own pitch. See where the friction concentrates before you build.

If the IFI comes back low, that's not a failure signal. It's a navigation signal. The simulation tells you which variables are dragging the score and which personas are the blockers. Fix those structural barriers, re-run, and watch the curve change.

That's the loop lean startup was always supposed to create. Market Physics just runs it in behavioral space instead of interview space — and it runs it before you've committed to building anything.

One last thing

I built Market Physics because I needed it. City Shower taught me what late-stage friction discovery costs. Every venture since has been shaped by the question I now run through the engine first:

Not "can I build this." Not "do people want this." But "will people actually change their behavior to adopt this — and what stands in the way?"

That's a different question. It deserves a different tool.

Almin Zolotic is the founder of Zologic (AI commerce infrastructure, Den Haag NL), City Shower (hygiene access for the homeless in the Netherlands), and Market Physics Engine (behavioral adoption simulation). UCPReady — the WooCommerce AI agent commerce plugin — is currently in WooCommerce Marketplace business review.

Launching on Product Hunt tomorrow — would mean a lot if you checked it out 👇

🚀 Launching on Product Hunt tomorrow — upvotes mean the world

Tags: startup entrepreneurship ai productivity

The "Efficiency Tax": Why Your AI Agents Are Failing at Checkout

Almin Zolotic — Thu, 05 Mar 2026 23:06:23 +0000

As we move from building simple RAG chatbots to deploying autonomous commerce agents, we are hitting a new kind of bottleneck.

It’s not a model reasoning problem.

It’s not a UI problem.

It’s a Protocol Stability problem.

In our latest research at Zologic, we benchmarked how AI agents (using 4–8 concurrent models) interact with a large-scale WooCommerce store (~42,000 SKUs). The results revealed a massive "Efficiency Tax" that most developers aren't accounting for.

The Problem: Protocol Exposure

When you give an LLM direct access to your commerce APIs ("Protocol Exposure"), you aren't just dealing with occasional hallucinations. You're dealing with high-frequency execution friction.

The Search Loop

Agents in exposed environments averaged 3–5 search retries per session just to find the correct SKU.

Parameter Mismatches

Models frequently generate arguments that don't perfectly align with strict database schemas, leading to immediate execution failure.

The "Handshake" Failure

The transition from a valid cart to a successful checkout is often non-deterministic, causing agents to lose session context and abandon the flow.

The Data: Measuring the Friction

We compared a baseline "exposed" environment against one utilizing an Execution Stabilization Layer (UCPReady + Pro).

Infrastructure impact at 100,000 monthly sessions:

Redundant Work

Exposed environments generated ~160,000 unnecessary tool calls per day.

Latency & Load

Every session averaged ~2 extra searches, significantly increasing server load and token costs.

The Bottom Line

This technical friction resulted in a 20% decay in conversion rates (from a 2% baseline down to 1.6%).

From "Base" to "Pro" Execution

To solve this, we moved away from raw protocol exposure toward Argument Normalization. By implementing a stabilization layer, we forced deterministic outcomes for the AI.

Argument Normalization

Ensuring model-generated arguments match protocol requirements before execution.

Deterministic Checkout

Creating a stabilized path that prevents session loss during the final transaction.

Efficiency Gains

Reducing search attempts to 2–3 per session and significantly lowering the Efficiency Tax on tokens.

The Economic Impact

For a store with an €80 Average Order Value (AOV), fixing this technical friction isn't just a dev task — it's a massive revenue lever.

Monthly GMV Delta: €32,000

Annual Revenue Impact: €384,000

Conclusion for Developers

If you are building for the agentic web, stop optimizing your prompts and start optimizing your execution environment.

As session volumes scale, the economic impact of protocol stability scales with it.

Full Technical Briefing:

https://zologic.nl/research/

Tags

webdev #ecommerce #ai #woocommerce #llm #infrastructure

Why SaaS Middleware Is the Wrong Architecture for Agentic Commerce

Almin Zolotic — Tue, 03 Mar 2026 22:30:18 +0000

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

Your WooCommerce Store Isn't Ready for AI Agents. Here's What That Costs You.

Almin Zolotic — Sun, 01 Mar 2026 16:27:14 +0000

The next customer to visit your WooCommerce store might not be human.

It might be a ChatGPT plugin, a Claude shopping assistant, a Gemini agent, or something your customer built themselves that wakes up at 2am, searches for what they need, and tries to check out — all without any human in the loop.

If your store isn't built for that, the agent doesn't rage-quit. It doesn't leave a bad review. It just stops. Silently. And the sale never happens.

The Problem Nobody Is Talking About

WooCommerce is the most widely deployed ecommerce platform on the web. It powers millions of stores. And almost none of them are machine-readable in a way that AI agents can actually transact with.

This isn't about product feeds or SEO metadata. Those are solved problems. This is about something different: structured, real-time, bidirectional communication between an AI agent and your store's commerce infrastructure.

When a human visits your store, they handle ambiguity. They click around, read descriptions, figure out which size they need, and eventually check out. They tolerate friction because they want the product.

Agents don't tolerate friction. They follow the tools available to them, and if those tools don't give them the right signals at the right moment, they stop — or worse, they loop, burning compute and your customer's patience before failing anyway.

The gap isn't your products. It's your infrastructure.

What UCPReady Does

UCPReady is a WooCommerce plugin that implements the Universal Commerce Protocol (UCP) — an open standard for AI-agent commerce interactions built on the Model Context Protocol (MCP).

In plain terms: it gives AI agents a clean, structured way to interact with your store. Search products. Inspect product details. Create a checkout. Complete a purchase. Every operation is exposed as a well-defined MCP tool with typed parameters and predictable responses.

The ten tools UCPReady exposes cover the full purchase lifecycle:

Product discovery (list_products, get_product)
Checkout management (create_checkout, get_checkout, update_checkout, complete_checkout, cancel_checkout)
Order visibility (get_order, list_orders)
Integration (register_webhook)

When an AI agent connects to a UCPReady store, it gets a manifest of what's available, connects via MCP, and can complete a purchase without any human-facing UI at all.

That's the baseline. That's what Core gives you.

Why "AI-Compatible" Isn't Enough

We ran controlled benchmarks with four frontier AI models — Claude Opus 4.6, Gemini 2.5 Pro, Grok 4, and DeepSeek v3-2 — on a live UCPReady store (houseofparfum.nl, a real fragrance retailer).

The test was simple: ask for a product, then say "buy me the first one."

Every model completed the purchase. UCPReady Core works.

But here's what we also found.

Model behavior is not uniform. The same purchase lifecycle cost 12,929 tokens with Gemini and 21,644 tokens with Claude — a 67% difference. That's not a bug. It's the nature of probabilistic inference across different model architectures. Different models reason differently about the same tool responses.

Token cost is the wrong optimization target. At typical LLM input pricing, the difference between the cheapest and most expensive model for a single checkout session is fractions of a euro cent. If you're at 10,000 AI-driven checkouts per month and you switch from Claude to Gemini, you save roughly €261/month in input tokens. That sounds meaningful until you realize that a 1% improvement in conversion rate at an average order value of €75 is worth €7,500/month on the same volume.

The real risk is silent failure. Not failed transactions that throw errors — those you'd catch. The risk is the agent that searches, finds nothing, and stops. The agent that tries to check out a variable product and gets a WooCommerce rejection it doesn't know how to handle. The agent that completes a checkout attempt that hits an escalation state and doesn't know what to tell the customer. These are the failure modes that don't show up in your WooCommerce logs. They show up as sessions that ended early and sales that never happened.

UCPReady Pro: The Behavioral Intelligence Layer

UCPReady Pro is a paid addon that sits on top of Core and addresses exactly these failure modes.

It doesn't modify Core's tools. It doesn't change the protocol. It doesn't touch your checkout flow or your WooCommerce configuration. It works entirely within Core's published filter API — additive by design, zero regression risk.

What it does: it adds a behavioral intelligence layer that shapes how AI agents interpret and respond to tool results. When certain conditions are detected in a tool response, Pro appends targeted instruction signals that guide the agent toward the correct next step.

We can't give you the full architecture here — that's the product — but the categories of failure it guards against are public:

Variable product resolution. WooCommerce requires a variation ID, not a parent product ID, to create a checkout for a configurable product. Agents that don't know this fail silently. Pro guards this.

Low-stock urgency. When stock is limited, agents that don't surface that information before checkout create a poor experience — or a failed one if stock depletes mid-session. Pro guards this.

Empty search recovery. Agents that hit a zero-result search and stop lose sales that a simple query adjustment could have recovered. Pro guards this.

Escalation handling. Some checkout attempts require human review. Agents that don't communicate this clearly leave customers without resolution. Pro guards this.

Ranked reference resolution. Phrases like "buy the first one" or "that one" are common. Mapping them deterministically to a product ID in context is not something all models handle reliably across all session states. Pro guards this.

None of these are exotic edge cases. They're the everyday surface area of a functioning ecommerce store — variable products, low inventory, search misses, payment escalations, conversational reference. Pro makes sure agents navigate all of it correctly.

What the Benchmark Actually Showed

We want to be specific here, because the AI-commerce space has no shortage of inflated claims.

Our controlled benchmark tested a clean purchase path: named product search, then ranked-reference buy intent. All four models completed the purchase in both directions — with Pro active and without it — on this specific scenario.

Pro's measured impact on that path: +28 to +68 prompt tokens per lifecycle. Zero behavioral change.

That's the honest result. For a smooth path through a simple product, Pro is transparent. It adds its signals and the model reaches the same outcome it would have reached anyway.

That's actually the correct result for a production reliability layer. You don't want a plugin that changes behavior on your happy path. You want one that catches the unhappy paths before they fail.

The failure modes Pro guards against require specific conditions to trigger: variable products, low stock, zero results, escalation states. We've validated the architecture. The stress-test benchmarks — the ones that actually trigger those conditions and measure whether Pro catches them — are the next phase of public documentation.

What we can say now: the plugin is architecturally sound, non-regressive, and in production on a live store with four frontier models confirmed compatible.

The Bigger Picture: Agentic Commerce Is Not a Future State

ChatGPT has had shopping capabilities for over a year. Gemini can complete purchases. Perplexity is building commerce features. The MCP ecosystem is growing rapidly, and the early pattern is clear: AI assistants that can take action on behalf of users will do so, and ecommerce is one of the highest-value action categories.

The stores that will benefit are the ones that are ready when agents arrive — not the ones scrambling to retrofit compatibility after their competitors already captured that traffic.

WooCommerce is uniquely positioned here. It's PHP, it's filterable, it's extensible, and the community knows how to build on it. UCPReady is built in that tradition: a clean plugin that works within WordPress conventions, hooks into WooCommerce properly, and exposes a standards-compliant MCP endpoint that any agent can connect to.

You don't need to rebuild your store. You need to add two plugins.

Getting Started

UCPReady Core is the foundation. Install it, configure your MCP endpoint, and your store is immediately discoverable and transactable by any MCP-compatible AI agent. It requires WooCommerce 8.5+ and WordPress 6.4+, and it's HPOS-compatible.

UCPReady Pro is the intelligence layer. It requires Core v1.7.24+ and adds the behavioral guardrails that keep agents on the right path through the full complexity of a real product catalog — variable products, inventory states, search edge cases, and checkout outcomes.

Both are built by Zologic, a Netherlands-based development studio focused on AI-commerce infrastructure.

A Note on Honesty

We've seen a lot of AI-ecommerce content that leads with conversion uplift projections, token savings math, and bold claims about what AI agents prefer. Some of that framing is legitimate — the underlying dynamics are real.

But we've benchmarked this ourselves, on a live store, with real models, and we know what the data actually says versus what sounds good in a pitch. The claims in this post are grounded in measurements we made and can reproduce. The claims we haven't made yet are the ones we haven't measured yet.

If you're evaluating this category seriously, that distinction matters. We'd rather earn your confidence with accurate information than win it with numbers that don't hold up.

UCPReady Core and UCPReady Pro are available at zologic.nl/ucpready. Questions, architecture discussions, and benchmark comparisons welcome in the comments.

If you're building AI agents that interact with WooCommerce stores, we'd especially like to hear from you.

Behavioral commerce prompting: the conversion layer hiding in your MCP tool responses

Almin Zolotic — Fri, 27 Feb 2026 12:42:55 +0000

Almin Zolotic — founder of Zologic

There's a prompt engineering layer in agentic commerce that nobody is talking about yet. Here's how it works and why it matters.

When an AI agent shops a UCP-enabled store, it calls a sequence of tools: search, get product details, create cart, generate checkout. Every one of those tool calls returns a JSON response. Most developers treat those responses as pure data.

They're missing something.

The UCP spec allows stores to include an instructions field in any tool response. That field lands directly in the agent's context window — it's not a system prompt, it's not a user message, it's store-injected behavioral guidance delivered at the exact moment the agent needs it.

That's a conversion funnel built into the protocol layer itself.

What it looks like in practice

The mechanism works by embedding behavioral guidance directly into tool response payloads — at the exact moment the agent needs it, for the exact stage of the funnel it's in.

Each tool response carries stage-specific instructions. A search response tells the agent how to present results and what to do next. A product detail response coaches it through variant resolution. A cart response guides it toward checkout without unnecessary detours.

The store is not just serving data. It's coaching the agent through a structured checkout funnel — stage by stage, tool call by tool call. The merchant controls agent behavior without touching the AI's system prompt.

Why this is different from system prompt engineering

System prompts are set at the agent level, before any store interaction. They're generic — they can't know which store the agent is visiting, what stage of the funnel it's in, or what the next correct action is.

Behavioral commerce prompting is:

Contextual — delivered at the exact moment of each tool response, not upfront
Stage-aware — different instructions per funnel stage (search vs product detail vs cart)
Store-controlled — the merchant owns it, not the AI platform
Dynamic — can vary per product, category, stock status, or business rule

A system prompt can say "help the user buy something." A tool response instruction can say "this product has three size variants — resolve the correct variation ID before creating checkout, or the cart will fail."

That's a fundamentally different level of precision.

The conversion impact

The biggest drop-off point in agentic commerce funnels is variant resolution. Agents that skip get_product_details and try to cart directly from search results guess at variant IDs, hit type errors, and fall off the funnel. In 180 real agent sessions across 11 models, this single failure mode accounts for most checkout drop-off.

Behavioral prompting fixes it at the source. Instead of hoping the agent follows the correct tool sequence, the store tells it to — at the exact moment it needs to know.

The agent follows it. Not because it was trained to. Because the store told it to, in context, at the right moment.

What this means for anyone building MCP servers

Your tool responses are not just data contracts. They're an interface between your business logic and the agent's reasoning loop.

Every tool response is an opportunity to:

Prevent the next likely failure mode
Route the agent to the correct next tool
Surface business rules the agent can't infer from schema alone
Reduce token waste from exploratory tool calls that go nowhere

The stores that perform best in real agent sessions — consistent checkout completion across multiple models — are the ones that treat tool responses as behavioral interfaces, not just data payloads.

Schema quality gets you in the door. Behavioral instructions close the sale.

The deeper point

Prompt engineering has been a discipline focused on what you put into the system prompt or the user message. Agentic commerce introduces a third surface: the tool response.

As MCP becomes the standard interface between AI agents and external systems, every server that returns tool results has the opportunity — and arguably the responsibility — to guide agent behavior at the moment of execution.

For commerce, that means conversion optimization at the protocol layer. Not in the UI. Not in the AI. In the store's responses.

That's a new discipline. It doesn't have a name yet.

I'm calling it behavioral commerce prompting.

UCPReady implements this across all tool responses for WooCommerce stores. If you're building MCP servers for commerce and want to compare notes, I'd like to hear what you're seeing.

https://zologic.nl/the-next-evolution-of-conversion-why-your-store-needs-to-be-agent-ready/

WooCommerce vs. AI Agents: Infrastructure Lessons From Real Tests

Almin Zolotic — Thu, 26 Feb 2026 20:02:43 +0000

Traditional WooCommerce hosting is architected around human behavior: deliberate page loads, visual browsing, and session-based cart interactions. Agentic commerce changes that model entirely.

AI agents do not browse—they query. They do not wait for CSS to render—they hit REST or MCP (Model Context Protocol) endpoints in high-frequency bursts. We recently ran 308 autonomous shopping sessions across live WooCommerce environments to quantify how this traffic differs from human users—and where the infrastructure snaps.

What’s Different About Agent Traffic?

The core difference is the request-to-action ratio. A human user might generate 10–15 requests over five minutes to purchase a product. An AI agent can generate 30+ structured API calls in under 15 seconds to achieve the same outcome.

Feature	Human Behavior	AI Agent Behavior
Interface	Visual (DOM/CSS)	Structured (JSON / REST / MCP)
Navigation	Sequential / Linear	Parallel / Recursive
Retries	Manual / Abandonment	Immediate / Programmatic
Data Usage	Selective scanning	Exhaustive schema parsing

When an agent encounters a schema mismatch or type validation error, it does not leave the site. It retries—often instantly. If your API schema is ambiguous, the agent may loop against the same endpoint dozens of times per minute, causing immediate CPU spikes and PHP worker exhaustion.

Real Data: The 308-Session Test

We analyzed 29 unique agent implementations across stores ranging from 1,000 to 50,000 SKUs.

1. Cart Endpoint Bursts

Agents averaged 3–6 consecutive tool calls within a 2-second window. This creates a "thundering herd" effect on PHP workers—particularly on shared hosting environments with limited process pools.

2. Variant Resolution Overhead

Agents often resolve every product variant (ID, SKU, size, color) before carting to ensure precision. This doubled the number of API calls per successful checkout compared to human sessions.

3. The Retry Loop Cost

Type validation errors (notably -32602) triggered by incomplete schema descriptions led to:

An average retry rate of 1.8 per failed call.
Measurable increases in database write pressure.
Higher memory churn during cart orchestration.

4. Concurrency Limits

On standard shared hosting, timeouts began appearing at just 15 concurrent agent sessions. This is far below what most stores assume is "safe capacity."

What Broke First?

Agentic commerce doesn’t break the frontend; it breaks the stack.

PHP Worker Exhaustion: Rapid API calls quickly occupy all available workers, leading to 504 Gateway Timeouts for both agents and humans.
Memory Spikes: Stores with 40k+ SKUs saw 512MB–1GB memory spikes during cart orchestration when pagination was not strictly enforced.
Unoptimized Search: If the first 100 results lack a required attribute, agents re-query. Without proper indexing, MySQL becomes the primary bottleneck.

VPS Implications & Practical Guidance

For agent-ready stores, a VPS is no longer optional. The tier depends on your catalog:

The 2GB RAM Threshold: Sufficient for < 200 agent sessions/day and < 10k SKUs, provided Redis object caching is enabled and rate limiting exists.
The 4GB+ Requirement: Necessary for 50k+ SKUs, real-time stock validation, or high-concurrency MCP traffic.

Why Redis Matters: Redis is the single most impactful optimization here. By caching product schemas and variant metadata, you stop the agent from forcing a fresh DB lookup for every validation cycle.

The Hidden Bottleneck: Checkout Orchestration

Checkout is the most write-heavy phase. Agents stress order creation, stock validation, and transaction commits simultaneously. Stores using legacy order tables frequently experience locking contention.

The Fix: Migrating to High-Performance Order Storage (HPOS) in WooCommerce significantly improves concurrency handling and reduces write lock bottlenecks under concurrent agent hits.

Modeling Agent Traffic (From Readiness to Infrastructure)

Understanding protocol readiness is only half the equation. A store can expose a valid .well-known/ucp manifest and still collapse under agent burst traffic if the underlying VPS is undersized.

To quantify this, we built a lightweight infrastructure simulator that models agent retry loops, variant resolution overhead, and worker pool saturation. The goal was to answer a practical question: How much VPS do you actually need for agent-driven commerce?

Based on our 308-session dataset, we published an interactive calculator to make this data actionable:

👉 AI Commerce Tool — VPS & Agent Readiness Calculator

It allows you to input your SKU count and session volume to receive VPS tier recommendations and estimate concurrency thresholds. Protocol compliance determines whether agents can interact with your store; VPS capacity determines whether your store survives that interaction.

Discussion: Are You Ready for Agents?

Are you seeing structured, non-human patterns in your API logs?
Have you stress-tested your cart endpoints for idempotency under retries?
Is rate limiting configured for legitimate AI agents versus malicious bots?

Agentic commerce is no longer hypothetical. The earlier stores adapt their infrastructure for concurrency over page views, the more stable their growth will be.

Gemini tried to shop my WooCommerce store. Here's how far it got.

Almin Zolotic — Wed, 25 Feb 2026 11:30:06 +0000

Almin Zolotic — founder of Zologic

I didn't set this up as an experiment. I typed a shopping query into Gemini and watched what happened. What followed is the clearest demonstration I've seen of why AI agent readiness matters for WooCommerce merchants right now — and what happens at every stage when it's missing.

Act 1: No UCP. Gemini sends your customer to your competitors.

I typed: "Gemini, I want to buy Vichy perfume from houseofparfum.nl"

Gemini's response had nothing to do with the store.

It questioned the site's legitimacy. It said houseofparfum.nl had no established reputation on Trustpilot. It told me Vichy doesn't make perfume. Then it redirected me to Notino, Farmaline, Etos, and DeOnlineDrogist — four competitors — with a comparison table and everything.

The customer was gone.

This is happening right now to WooCommerce stores across Europe. AI assistants field shopping queries, fail to understand the store, and route customers elsewhere. Not because the store is bad. Because the store is invisible to the agent.

Act 2: One UCP endpoint. Gemini understands the store.

I gave Gemini one thing: https://houseofparfum.nl/.well-known/ucp

That's the UCP discovery manifest — a machine-readable file that tells AI agents what a store sells, what protocols it supports, and how to interact with it. UCPReady generates and maintains it automatically.

The conversation changed immediately.

I asked: "What do they sell on houseofparfum.nl?"

The store went from "suspicious unknown website" to "specialist fragrance retailer" in one prompt. The customer was back.

I then gave Gemini a direct product URL and asked about it.

That's discovery working exactly as designed. One manifest URL transformed the agent's understanding of the entire store.

Act 3: No live endpoint. Gemini hallucinates the checkout.

Here's where it gets interesting — and dangerous.

I fed Gemini the raw UCP manifest JSON directly.

I then shared the ToolRegistry code that defines UCPReady's MCP tools.

Gemini has no live connection to the store. It learned the shape of the tools from the code I shared, but it has no ability to actually call them. What it does instead is simulate what the results should look like — convincingly.

I tested that checkout link. The server returned:

{"code":"rest_no_route","message":"Geen route gevonden die overeenkomt met de URL en aanvraagmethode.","data":{"status":404}}

The session ID was malformed. The signature was invented. The URL never existed.

A customer reading Gemini's order summary would have no reason to doubt it. They'd click the checkout link and hit a dead end.

This is the last-mile problem in agentic commerce. An agent that partially understands your store is almost worse than one that doesn't — it walks the customer to the door and hands them a key that doesn't fit the lock.

Act 4: Real UCP connection. Real checkout. Real order.

I ran the same store through UCP Playground — a third-party benchmarking tool that connects AI agents to UCP endpoints via live MCP connections.

That URL is a real UUID. That session exists in WooCommerce. That link opens a pre-filled checkout with iDEAL, Klarna, and credit card — ready for the customer to pay.

Two tool calls. 1,064ms for product search. 365ms for checkout creation. Done.

No hallucinated inventory. No fake session strings. A real order waiting to be completed.

The three states every WooCommerce store is in right now

State 1 — No UCP manifest: AI agents either ignore your store or actively redirect customers to competitors who are better understood. This is where most WooCommerce stores are today.

State 2 — UCP manifest only: Agents discover and describe your store accurately but fail at checkout. Customers get excited then confused. The manifest is a start — not a finish.

State 3 — Full UCP implementation: Agents complete the entire funnel. Discovery, product detail, cart, delegated checkout. Real orders. Real attribution in WooCommerce. This is what UCPReady delivers.

What surprised me most

The agent intent is already there. Gemini — with no UCP integration, no merchant approval, no platform partnership — got as far as finding real product pages and calculating free shipping thresholds for a small Dutch fragrance store it had never encountered before.

It just failed at checkout because there was no structured interface to connect to.

The demand exists. The agents are ready. The missing piece is the store.

A note on Gemini and ChatGPT specifically

Neither Gemini nor ChatGPT activates the full UCP checkout flow in their chat interfaces today. Google's implementation requires Merchant Center enrollment and is currently US-focused. ChatGPT's Instant Checkout is limited to select Shopify and Etsy partners.

But Google has already published UCP as their open commerce standard — co-developed with Shopify, Zalando, Mastercard, Visa, and 20 other partners. The infrastructure is being built. The protocol is public. The endpoint format is standardized.

UCPReady ensures your store is ready when they flip the switch. And right now, every UCP-native agent — the ones built on MCP, the ones in tools like UCP Playground, the ones being built by developers reading the spec today — can already complete the full funnel on your store.

The open path is real. The timing is early. That's the point.

UCPReady brings WooCommerce stores to State 3. If your store is currently in State 1 or 2, I'd like to hear from you.

https://zologic.nl/the-next-evolution-of-conversion-why-your-store-needs-to-be-agent-ready/