DEV Community: Almin Zolotic

The Inventory Bug Hiding in Every AI-Facing Store (And in Every LLM)

Almin Zolotic — Tue, 14 Jul 2026 18:38:22 +0000

At Zologic we build UCPReady, the WooCommerce implementation of the Universal Commerce Protocol. It's the infrastructure that lets AI agents like Claude, Gemini, and ChatGPT discover, search, and check out on a WooCommerce store autonomously. Most of what we write about is protocol compliance, checkout funnels, agent behavior. This one's different. It's about a bug we found in a customer's store that has nothing to do with AI agents on the surface, and everything to do with them underneath.

The incident

One of our customers runs a fragrance dropshipping store with a catalog north of 53,000 SKUs, synced nightly from a wholesale supplier's API. Standard architecture: pull the vendor feed, match by SKU, update price and stock.

One night, a customer ordered a product. The order came through, payment cleared, and the product didn't exist anymore. Not out of stock. Deleted upstream. The wholesaler had quietly removed the SKU weeks earlier after it sat unsold for over a month. The store's sync script had no way of knowing, because it was never built to ask.

Why this matters more than it looks

Here's the part that made us stop and think harder than a routine sync bug usually warrants: at 53,000+ SKUs, a store like this isn't just serving human shoppers anymore. It's a surface AI agents crawl, index, and reason over, through UCP manifests, MCP tool calls, product schemas. When an agent (or a human, for that matter) asks "is this in stock," the honest answer your system should be able to give is "as of the last time I confirmed it." Most systems don't track that distinction. They track "the last value I stored," full stop.

That's the bug. Not a missing if statement. A wrong mental model. The store's database wasn't holding "the inventory." It was holding a cached copy of what the vendor said, last time anyone asked. And a cache with no expiry policy isn't a cache. It's a slowly rotting assumption.

What we found once we fixed it

We rebuilt the sync to track presence, not just values: every SKU the vendor's feed actually returns gets marked as reconfirmed this run. Anything previously published that's absent from a full feed read gets quarantined, not deleted, just pulled from the storefront, ready to snap back the instant the vendor restocks it.

Running it for the first time against a catalog that had never had this check before surfaced the scale of the accumulated drift:

~2,700 products (over 11% of the published catalog) had been silently stale, some for months
151 new products picked up automatically in the same pass
Total catalog stock units moved from 921,786 to 955,594 in a single sync: a +33,808 unit correction
Published stock alone: 676,169 → 698,153 (+21,984 units)
Draft-side stock: 245,617 → 257,441 (+11,824 units) That's not a rounding error. That's tens of thousands of stock units that were wrong, on a store an AI shopping agent could have been confidently quoting availability from, minutes before check-in.

The paradigm shift

Physical inventory feels like it should be a stable, durable fact. A bottle either exists in a warehouse or it doesn't. But from your system's point of view, that's never something you observe directly. It's an inference from the last API response you got, and every inference like that has a shelf life whether you model it or not.

Anything your system ingests from an external source is perishable by default. Freshness has to be actively reconfirmed, never assumed from silence. "The feed didn't mention it" and "the feed confirmed it's fine" have to be different states in your data model. Collapsing them into one is exactly the bug we found.

Where this converges with everything else we build

This is the same failure shape we deal with constantly on the UCP side. An AI agent operating on stale product data doesn't just annoy a customer. It makes a purchase decision, or tells a shopper a store carries something it doesn't, based on a snapshot nobody re-verified. Multiply that by every WooCommerce store that gets discovered and transacted with autonomously, and "is this data still true, or just still there" stops being a backend nitpick and becomes a trust question for the entire agentic commerce stack.

And if you work with LLMs directly, you already know this pattern under a different name. A model's training data is a frozen snapshot. "Who's the CEO," "does this product line still exist," "is this API still current" all fail the exact same way our customer's SKU did: not because the model is wrong, but because nothing tells it its answer has gone stale. That's why retrieval and web search exist. They reintroduce the "did I just reconfirm this" check that a frozen snapshot structurally can't perform on its own. Even RAG can quietly reintroduce the bug at a smaller scale: an indexed-once, never-recrawled document lets "it's in my vector store" stand in for "it's true," when it only ever meant "it was true whenever I last indexed it."

Same fix, every time: track last confirmed, not just last known.

Takeaway

If your store, or your product, or your model, holds any data it didn't generate itself, ask the unglamorous question up front: what tells you an entry has gone stale, and is "I haven't seen an update" quietly standing in for "confirmed still valid"? At 53,000 SKUs, that gap was worth tens of thousands of stock units and a very real risk of selling something that doesn't exist. At agent scale, it's worse. It's a trust failure nobody notices until an autonomous checkout completes on a product that isn't there.

Perishable by default. Freshness earned, not assumed. That's the standard we're building UCPReady to hold stores to as AI agents become a bigger share of who's actually reading your catalog.

The Missing Middleware for Autonomous Agents

Almin Zolotic — Sun, 05 Jul 2026 13:43:19 +0000

How frontier models turned privacy from an application concern into an infrastructure problem

Frontier models faithfully execute instructions. They also faithfully move data across system boundaries. That changes privacy from an application concern into an infrastructure concern — and most agent architectures have not caught up.

The problem isn't that models misbehave. The problem is that they behave exactly as instructed, which means every piece of data in the context window is a candidate for transmission to the next tool call. In banking, healthcare, legal, HR, and insurance systems, that is not a theoretical risk. It is a structural property of how agents work.

This post identifies where the risk actually occurs, explains why better models make it worse, and describes the middleware layer that has to exist between the agent and every tool it calls.

Travel booking is the domain we implemented first. The architecture applies everywhere.

Better Models, Bigger Problem

Everyone assumes more capable models reduce risk. The opposite is true for data handling.

GPT-3.5 accidentally protected some secrets because it was inconsistent. It would drop fields, misread nested structures, and fail to extract values cleanly. That unreliability was not a feature, but it occasionally functioned like one.

Frontier models have eliminated that accident. GPT-4o, Claude Sonnet, and Gemini 1.5 Pro will faithfully extract a passport number from a 3,000-token profile and pass it directly to a seat selection tool that has no use for it. They do this because the data is present and the instruction says "book the flight." The model is not doing anything wrong. That is the problem.

There are three failure modes, and all three require the model to be working correctly:

Over-sharing on tool input. An agent receives a full traveler profile to perform a search. The profile contains a passport number. The search tool does not need it. The model passes the whole profile because it was told to call the tool with the traveler's details, and the whole profile is the traveler's details. The passport number now appears in the tool's request log.

Credential leakage in context. A tool returns an API response that includes a session token or an authorization header in the body. The model incorporates it into its context. In subsequent tool calls, the model may reference or repeat that token. This is not a hallucination failure. It is a faithful reproduction failure.

PII in structured outputs. The booking confirmation tool returns a full object containing every passenger detail, payment method, and contact. The agent summarizes it for the user, but the full object is in the context window. If that context is logged, the log contains structured PII at booking confirmation density.

None of these require a malicious actor. They require normal model behavior operating on data that should have been scoped before the model saw it.

The Architecture Gap

Traditional systems have a well-understood control plane:

Application
    ↓
API Gateway
    ↓
Service

The gateway handles authentication, rate limiting, and policy enforcement. It is not optional. No one ships a production service by having the application call downstream services directly.

Agentic systems have reproduced the application layer and the service layer but skipped the control plane:

Agent
    ↓
[nothing]
    ↓
Tool Runtime
    ↓
Provider

The agent calls tools directly. Every tool call is a direct transmission of whatever the agent has in context, including data the tool was never intended to receive. The tool returns whatever the provider returns, including data the agent was never intended to see.

The missing layer is a privacy guard that sits at the tool boundary and enforces policy in both directions:

Agent
    ↓
Privacy Guard
    ↓
Tool Runtime
    ↓
Provider

This is the same architectural pattern as an Envoy proxy or an API gateway. The implementation is different because the data is structured JSON rather than HTTP traffic, and the policy is semantic rather than header-based. The structural role is identical: a mandatory chokepoint where policy is enforced before data crosses a boundary.

What the Guard Actually Does

The guard intercepts every tool call in both directions and applies four operations:

Scans the payload for known PII and secret patterns using deterministic detection: field name matching, regex patterns with validation (Luhn for card numbers, format validation for structured types), and domain-specific rules (booking references, passenger name records, loyalty identifiers in travel; account numbers and routing codes in banking; NPI numbers and diagnosis codes in healthcare).

Decides based on configurable policy: allow the data through, redact it with a placeholder, replace it with a deterministic cryptographic token, or block the call entirely. The policy is per-kind and per-severity. Secrets are blocked. High-severity PII is tokenized. Standard PII is redacted.

Audits every inspection, input and output, with a trace ID that correlates the two events. The audit event records what was found and what action was taken, without including the sensitive values or the paths to redacted fields.

Enforces by surfacing violations as structured errors the agent runtime can handle, rather than exceptions that crash the call.

The Implementation

We built this as a dependency-free Node.js package integrated at the invokeTool() boundary in the MCP runtime. One instance at startup, shared across all tool calls:

import { createPrivacyGuard } from "@ucp-travel/mcp-privacy-guard";
import { travelDetectors } from "@ucp-travel/mcp-privacy-guard/travel";

const guard = createPrivacyGuard({
  detectors: travelDetectors,
  policy: {
    tokenizeKey: config.privacyTokenizeKey,
    rules: [
      { match: { kind: "secret" },               action: "block"    },
      { match: { kind: "pii", severity: "high" }, action: "tokenize" },
      { match: { kind: "pii" },                  action: "redact"   }
    ]
  },
  audit: async (event) => logger.privacy(event)
});

Every tool invocation passes through the guard twice:

export async function invokeTool(runtime, toolName, payload, options = {}) {
  const requestId = options.requestId || randomUUID();

  // Sanitize before the tool sees the payload
  const safePayload = await runGuard(
    runtime.guard, payload, "input", toolName, requestId, tenantId
  );

  // Execute the tool on the sanitized payload
  const result = await dispatchToolCall(toolName, safePayload, context);

  // Sanitize the response before the agent sees it
  return runGuard(
    runtime.guard, result, "output", toolName, requestId, tenantId
  );
}

The input guard runs before the tool handler receives the payload. The output guard runs before the response reaches the agent's context. Neither the tool nor the agent is modified.

Per-Tool Output Allowlists

Not all PII in a tool response is a problem. A booking confirmation is supposed to contain the passenger name and contact email. Redacting them breaks the confirmation flow.

The solution is per-tool output allowlists that specify which paths are permitted through unredacted:

const OUTPUT_ALLOWLIST_BY_TOOL = {
  [MCP_TOOLS.COMPLETE_CHECKOUT]: [
    "$.booking.id",
    "$.booking.passengers[*].given_name",
    "$.booking.passengers[*].family_name",
    "$.booking.contact.email"
  ],
  [MCP_TOOLS.GET_BOOKING]: [
    "$.booking.id",
    "$.booking.passengers[*].given_name",
    "$.booking.passengers[*].family_name",
    "$.booking.contact.email",
    "$.booking.contact.phone_number"
  ]
};

Everything not on the allowlist for that tool is redacted or tokenized according to the global policy. The search tool never returns PII even if the provider response includes it. The confirmation tool returns exactly the fields the agent needs.

The same pattern applies in other domains. A banking agent's account lookup tool might allowlist account nickname and last-four digits. A healthcare agent's appointment tool might allowlist appointment time and provider name. The policy is domain-specific; the mechanism is not.

Tokenization and Key Rotation

For high-severity PII, redaction is not enough. You lose the ability to correlate data across audit events. Tokenization replaces the value with a deterministic HMAC-based token tied to a key ID:

{ "email": "TOKEN:pii/2026-q3:a3f8c2..." }

The token is deterministic: the same input and key produce the same token, so you can correlate across audit events without storing the original value. The key ID is logged in every event that produces or reads a token. When you rotate keys quarterly, old tokens are not orphaned; you know exactly which key was active when they were created.

Rotation is a two-line environment change. The guard adds under 50ms to any call on payloads below the 200 KB size limit.

The Open Question

Tokenization solves the audit correlation problem. It does not solve the agent reasoning problem.

When the agent receives TOKEN:pii/2026-q3:a3f8c2... in place of an email address, it cannot send a confirmation to that address. If the agent needs to act on a value rather than acknowledge it, tokenization breaks the flow.

The current design handles this by allowlisting output paths the agent needs to surface to the user. It does not handle the case where the agent needs to use a value internally across multiple tool calls without seeing the raw value.

That is a harder problem. Reversible tokenization with a delegated decryption endpoint is one approach. Restricting which tools can receive which token kinds is another. Neither is fully satisfying. We have not solved it yet.

Most engineering articles end by claiming the problem is solved. This one does not, because it is not. The missing middleware layer exists and is deployable today. The question of how an agent reasons about data it has never seen in plaintext is still open, and the answer will shape how agentic systems handle regulated data at scale.

Almin Zolotic is the founder of Zologic and the author of the ucp.travel autonomous booking infrastructure. The architecture described in this article — bidirectional privacy enforcement at the MCP tool invocation boundary, with per-tool allowlists, deterministic tokenization, and domain-specific detection — was developed as part of the ucp.travel infrastructure and is documented here as a reusable pattern for agentic systems handling regulated data.

ucp.travel is autonomous travel booking infrastructure for operators who want to remove the human agent from the booking loop without losing the compliance properties the human agent currently provides.

The Missing Layer in Agentic Travel: Why "The AI Can Book It Now" Isn't the Hard Part

Almin Zolotic — Thu, 18 Jun 2026 16:01:34 +0000

Something real shifted in commerce this year, and most of the commentary around it is focused on the wrong question.

Visa recently announced a strategic collaboration with OpenAI to bring secure, identity-verified payments directly into AI-driven shopping experiences. Major payment networks don't make moves like that on a hunch — they make them when a category has crossed from experimental into something worth building real infrastructure around. Agentic commerce, the idea that an AI assistant can discover, decide, and complete a purchase on someone's behalf, is no longer a thought experiment. It's a deployment target.

The industry conversation around this, though, keeps collapsing into one narrow question: can an AI agent successfully place an order? Increasingly, yes. New protocols for letting agents discover merchants and call their tools are maturing quickly, and "the agent created a cart and checked out" demos are everywhere.

That's the easy 80%. Travel is where the other 20% lives, and it's the part nobody's marketing slide wants to talk about.

Why travel breaks the standard playbook

Most agentic commerce infrastructure today assumes something travel doesn't have: a stable product. A SKU with a fixed price sitting in a catalog, waiting to be added to a cart. That model works beautifully for a t-shirt. It falls apart the moment the "product" is a seat on a specific flight that a human or an agent took eleven minutes to decide on.

A flight offer isn't a fact. It's a perishable claim with a clock attached. The price quoted at the moment of search can be different by the time checkout happens. The seat itself can simply not be there anymore. None of that is a bug in any individual system — it's how airline inventory has always worked, long before any of this involved an AI. The gap is that most of the emerging agent-commerce tooling was designed around retail's assumptions, not travel's, and there's an open, active conversation in the standards community right now about exactly this: contributors building merchant-facing protocols for AI agents have publicly flagged that the lack of a way to signal "this offer is only valid for the next N minutes" is one of the main reasons the leading agentic commerce standard isn't yet considered production-ready for travel specifically.

That's not a criticism of the standard. It's a fair description of how hard the problem actually is. Perishability is travel's defining trait, and almost nothing in the current agent-commerce stack was built with it in mind.

The part that actually matters: agents aren't naturally careful

Here's the thing that surprised us most while building toward this, and it's the part worth other teams hearing before they find out the hard way.

It is tempting to assume that a sufficiently capable AI model will just behave responsibly. It'll notice when an offer is about to expire. It'll flag a price that crept up between search and purchase. It'll hesitate before re-booking something that already exists. In practice, none of that can be assumed, and assuming it is where the real risk lives.

A language model calling a booking tool is making its best judgment call in the moment, based on whatever it's been told and whatever data happens to be in front of it. That's genuinely useful, and modern models are good at it. But "the model usually behaves well" is a completely different claim from "the system cannot be made to overspend, double-book, or silently swap one set of terms for another." The first is a tendency. The second is a guarantee. Only one of those is something you can actually stand behind when real money and a real traveler's itinerary are on the line.

The practical implication is that every meaningful safety property — a hard budget ceiling, a cabin-class policy, a rule that a flight has to be direct, a requirement that any meaningful airline-initiated schedule change gets a human's eyes on it before anything happens automatically — has to be enforced by the platform sitting between the agent and the booking, not hoped for from whichever model happens to be making the call that day. The agent should be free to reason, suggest, and act quickly. The guardrails need to exist completely independently of whether it chooses to respect them.

What "safe" actually requires, in plain terms

Once you take that seriously, the requirements stop being abstract and become very concrete.

Every offer needs an honest expiry, enforced server-side, not just displayed as a courtesy. A price has to be reconfirmed immediately before money moves, not assumed stable from however many minutes earlier it was first quoted. Spending limits, cabin policy, and routing preferences need to be checked against the actual final terms of a booking, not just the terms that looked fine at the moment of search. A booking attempt that looks like a duplicate of something already purchased needs to be caught before a second charge happens, not after. And critically: anything an airline changes after the fact — a schedule shift, a downgraded itinerary — has to surface to an actual human decision, because that's exactly the kind of judgment call that shouldn't be delegated to an agent acting alone, no matter how capable it is.

None of this is exotic engineering. It's the unglamorous, table-stakes work of building a transactional system that's actually trustworthy, applied to a domain — travel — where the standard agentic commerce tooling hasn't fully caught up yet. Every one of these properties has to be proven, not assumed. The honest way to know a guardrail works is to actively try to break it, watch it hold, and keep a permanent record that it did.

Where this is heading

The standards layer for agentic commerce is moving fast, and that's a good thing — a shared, open way for agents to discover and transact with any business, regardless of platform, is genuinely valuable infrastructure for the whole industry. Large travel technology players are already shipping their own agent-facing interfaces, and that's a healthy sign the category is real, not speculative.

What's still missing, broadly, is the execution layer underneath travel specifically: the part that takes "an agent can call a booking tool" and turns it into "an agent can be trusted to book within real constraints, with a permanent, auditable record of exactly what it was and wasn't allowed to do." That's the layer we've been building at Zologic, under the name ucp.travel — not a replacement for the emerging standards, but the travel-specific safety and policy infrastructure that sits on top of them, so that the convenience of "just ask the AI to book it" doesn't come at the cost of the control any business or traveler would reasonably expect to keep.

The easy part of agentic commerce is already here. The trustworthy part is what's actually being built right now — and travel, with its perishable inventory and real financial stakes, is as good a proving ground for that as any.

We're building ucp.travel, the policy and safety execution layer for autonomous travel booking. If you're thinking about similar problems in agentic commerce — perishable inventory, mandate-based spending controls, audit trails for autonomous transactions — we'd like to hear from you, and you're welcome to try ucp.travel directly at ucp.travel.

From Booking to Beyond: Making Autonomous Travel Servicing Work in Practice

Almin Zolotic — Tue, 09 Jun 2026 22:10:28 +0000

This is part of an ongoing series on building ucp.travel — an agentic travel stack that lets AI agents search, book, change, and cancel flights autonomously. Built by Almin Zolotic at Zologic.

Last time I wrote about getting an AI agent to autonomously book a flight: search, revalidate, pay, confirm. That was the exciting part.

This week was the less glamorous, but arguably more important, part: what happens after the booking.

Anyone who has built anything in travel knows the booking is only the beginning. The real complexity shows up afterward. The traveler wants to change their flight. The airline changes it for them. The traveler wants to cancel. Dates shift, prices reprice, confirmation windows expire. A real travel platform has to handle all of this without falling apart — and without making the traveler feel like they are operating blind.

That is what we spent the week building.

The three moments that matter after a booking

There are really three post-booking scenarios that define whether a travel platform feels like a product or a prototype.

Voluntary cancellation — the traveler decides to cancel and needs to understand the consequence before committing.

Airline-initiated change — the carrier reschedules or changes the trip, and the platform has to reflect that clearly instead of pretending the booking is still unchanged.

Voluntary change — the traveler wants a different flight, and the system has to guide them through a preview, a confirmation step, and any additional payment required, without ambiguity about what is final and what is not.

All three are multi-step flows. None should happen in a single call. And none should complete without the traveler knowing exactly what they are confirming.

Making irreversible actions feel safe

The principle we kept coming back to was simple: anything irreversible should be preceded by a preview.

The traveler should see what will happen, have a chance to pause, and only then confirm. If the preview expires before they act, the system should catch that and ask them to start again — rather than proceeding with stale information.

That sounds obvious, but implementing it correctly takes real discipline. There are a surprising number of places where a system can skip the preview, auto-confirm, or fail to communicate that a confirmation window has closed. We closed those gaps so a preview can never be skipped and a stale confirmation can never slip through.

The same principle applies to how the system talks about fare conditions. A fare being labelled refundable is a policy statement — not a guarantee that the system can execute a refund right now. We changed the platform to check live booking state before promising that change or cancellation is available. If a booking cannot be serviced through the current interface, the traveler now hears that clearly instead of getting a confusing error after the fact.

Airline-initiated changes were the hardest part

The scenario that took the most care was airline-initiated change.

When an airline changes a trip, the platform receives an event and has to decide what to do. The wrong answer is to handle it silently. Airline changes can involve new flight times, a different aircraft, or sometimes different routing — none of which the traveler has agreed to.

The right answer is to surface the change clearly, show what was originally booked versus what is now being proposed, and ask the traveler to review before anything is accepted or rejected.

We built that escalation path properly, made sure the platform re-fetches fresh booking state before presenting the change, and validated the full flow end to end against real provider behavior.

Honest language matters too

One smaller change that mattered a lot was how cancellations are communicated.

In many travel products, cancellation language quietly implies the traveler will simply get money back the moment they cancel. That's not always accurate, and saying it anyway is the kind of small dishonesty that erodes trust the first time someone notices the gap.

So the platform now communicates cancellation in terms of what's actually true: the booking is cancelled, and the traveler is told plainly what happens next with any refund or credit, rather than a vague promise that may not match reality.

Small wording change. Matters a lot for trust.

How we know it actually works

The thing I am most satisfied with this week is not just the feature list.

It is that we did not stop at "it works locally."

We exercised the full booking lifecycle — booking, changing, cancelling, and handling airline-driven changes — against live provider responses, step by step, until we had confirmed outcomes for every scenario.

That shifted the project from "we think this works" to "we know these core flows work."

There is a meaningful difference between code that looks correct and a system that has been proven to behave correctly under real conditions. This week we crossed that line for the servicing layer.

What is next

The immediate next track is operator tooling: giving the people running travel programs visibility into their bookings and the ability to manage their travelers with confidence.

The AI agent layer is now in a healthy place.

Now the work is turning that foundation into a full product for the humans operating on top of it.

More soon.

Almin Zolotic is the founder of Zologic and building ucp.travel — an agentic travel stack that lets AI agents search, book, change, and cancel flights autonomously. Follow the build here on dev.to.

We Just Completed a Live AI-Agent Flight Booking End to End

Almin Zolotic — Mon, 01 Jun 2026 14:25:44 +0000

An AI agent received a natural language instruction, searched for flights, selected an offer, passed authorization checks, and created a confirmed booking — autonomously, without human input after initial setup.

Today that went from architecture spec to production reality.

What actually happened

At 15:33 CET, on UCPPlayground, we ran the following prompt against our live stack:

"Use search_flights for ZAG to AMS tomorrow. Then immediately call complete_checkout on the first direct offer. Do not explain first."

Two tool calls. Eight seconds.

The agent searched. The agent booked. A confirmed booking reference came back. We opened the travel provider dashboard and the order was sitting there — confirmed, with a PNR, an e-ticket, passenger details, everything.

No human touched the booking flow after the initial traveler setup.

Why this is harder than it sounds

Anyone can wrap a travel search API in an MCP tool and call it "AI travel booking." That part is easy.

The hard part is everything that happens between search and confirmed booking:

Offers expire. Flight fares are perishable inventory. An offer returned from search may be gone in 15–30 minutes. No LLM checks this unprompted — it will try to book an expired offer and get a rejection it doesn't know how to recover from.

Prices change silently. A fare can reprice between the moment the agent sees it and the moment it tries to book. Without a revalidation gate, the agent books at the new price without telling anyone.

Bookings can partially confirm. A travel provider can return an async response — booking accepted, outcome pending. An agent that doesn't understand this state will retry, and retrying a booking call risks a double charge.

Identity and authorization matter. Who is this booking for? What are they allowed to spend? What cabin class? Are they direct-only? Without a mandate layer, an agent has no constraints. It will spend whatever inventory is available.

Document requirements gate certain routes. Some routes require passport details to be validated before an order is created. An agent that doesn't check this wastes a booking attempt and confuses the traveler.

These aren't edge cases. Every one of them will happen in production. None of them are solved by the travel API or the LLM — they have to be solved by the layer in between.

That's what we built.

The stack

We built UCP Travel — a travel transaction layer that sits between AI agents and travel inventory.

It implements:

UCP (Universal Commerce Protocol) — the open standard for agentic commerce, including the full checkout lifecycle
MCP (Model Context Protocol) — so any MCP-compatible agent can discover and call our tools
AP2 (Agent Payments Protocol) — cryptographically signed traveler mandates that enforce spending limits, cabin class ceilings, and booking constraints before any transaction The traveler sets up once: connects their AI assistant via OAuth, signs a mandate defining their booking constraints, stores their travel preferences. After that, every booking is autonomous within those constraints.

Our capability declarations are public at ucp.travel/.well-known/ucp and verified by UCPChecker — currently the only verified implementation of travel.ucp.mandate in the world.

UCPPlayground now recognizes ucp.travel as the reference pattern for travel-as-shopping — the travel.ucp.* namespace layered over dev.ucp.shopping is the model the ecosystem is converging on.

The UCPPlayground integration

The booking today happened through UCPPlayground — a live testing environment for the UCP ecosystem built by Ben Fisher. It connects real AI models to real UCP endpoints and runs end-to-end agent sessions.

Gemini 2.5 Flash connected to our MCP endpoint, discovered three tools (search_flights, complete_checkout, get_booking), and completed the booking in 3 turns:

Turn 1: search_flights(origin: ZAG, destination: AMS, departure_date: 2026-06-02, max_connections: 0)
Turn 2: complete_checkout(offer_id: off_..., checkout_id: chk_live_1)
Turn 3: [confirmed — PNR returned]

Outcome: purchase_completed. PNR confirmed in the provider dashboard.

What "traveler setup once" actually means

The autonomous booking only works because we solved the identity problem first.

During onboarding, a traveler:

Creates a profile with travel documents and preferences
Signs an AP2 Intent Mandate — their authorized booking constraints, cryptographically signed
Links their AI assistant via OAuth 2.0 Authorization Code flow From that point, every MCP tool call the agent makes carries a bearer token that resolves server-side to the traveler's identity, mandate, and payment profile. The agent never sees raw credentials, card numbers, or passport data. It just calls tools and gets results.

This is the architecture that makes autonomous booking trustworthy — not just technically possible.

What's live now

The multi-tenant operator platform is running. Operators onboard, configure traveler mandates, and connect AI assistants today. Flight booking is live.

Expanding next:

Stay (hotel) booking alongside flights
Post-booking servicing — changes, cancellations, ancillaries
Complete audit trail UI for operators and compliance teams If you're building an AI travel assistant, a travel management platform, or anything that needs to turn travel intent into confirmed bookings — we'd like to talk.

ucp.travel · contact@zologic.nl

Built by Zologic — zologic.nl

UCP spec: ucp.dev · MCP spec: modelcontextprotocol.io · AP2: ap2-protocol.org

30 Days of AI Agents Buying From a Real WooCommerce Store. Here's What the Data Says.

Almin Zolotic — Tue, 26 May 2026 15:32:55 +0000

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:

Agent	Sessions	Avg Calls	Status
UCP Directory Verifier	19	1	Discovery only
Unknown Agent	13	2.2	Transacting efficiently
UCP Checker	8	1.4	Validation + light transacting
UCPReady MCP	5	1.2	Internal testing
UCP Playground	2	5	+1 above benchmark
Claude	2	1	Clean
Ucptools.dev	1	2	At target
Generic Bot	1	1	At target

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

Shopify Just Gave AI Agents an Operating Manual. We Built One for WooCommerce.

Almin Zolotic — Tue, 26 May 2026 15:28:38 +0000

When Shopify shipped @shopify/ucp-cli last week, most of the coverage focused on the obvious part: AI agents can now browse and buy from Shopify stores using the Universal Commerce Protocol.

What got less attention was the file bundled inside the package — SKILL.md.

That file is not protocol. It's instructions. It tells AI agents how to behave when shopping on Shopify: start with discovery, sequence cart before checkout, render totals in the order the merchant provides them, treat escalation as a normal lifecycle step not an error. It encodes operational knowledge that the UCP spec alone doesn't cover.

Shopify proved something important: protocol + agent instructions is stronger than protocol alone.

We build UCPReady — a WooCommerce plugin that implements the full UCP stack. And until last week, WooCommerce merchants running it had the protocol layer but not the instruction layer. No file telling agents how to work with their store. No guidance surface beyond /.well-known/ucp.

We shipped that this week.

The gap Shopify exposed

UCP standardizes the transport and schema. Every conformant store — Shopify, WooCommerce, BigCommerce, custom — exposes the same protocol surface. That's the point.

But Benji Fisher at UCP Checker wrote a sharp breakdown of what Shopify's CLI actually does, and one line stuck:

It can buy from any UCP-compliant store on any platform. It can only find Shopify stores.

The discovery layer defaults to catalog.shopify.com. The transaction layer is pure, open UCP. Shopify owns the index; the protocol is shared.

That asymmetry matters. But there's a second asymmetry that's just as real: Shopify agents arrive at a store already knowing how to behave. Non-Shopify agents arrive and have to figure it out from the profile alone.

A SKILL.md bundled in a CLI is one way to solve that. But it only works for agents that installed that specific CLI. The more durable fix is publishing the operating manual on the merchant's own domain — discoverable by any agent, from any platform, the moment it finds the store.

What we shipped: the Agent Guidance Layer

UCPReady now auto-generates two public documents on every merchant site:

/agents.md — human and agent readable Markdown. Tells any agent:

Start with /.well-known/ucp, use the advertised endpoint, never assume /api/ucp/mcp
What capabilities this specific merchant supports (cart, checkout, orders, returns, identity linking, embedded checkout)
How to sequence checkout operations
What payment handlers are available
When to stop and escalate to the buyer
Whether return flows include retention/keep-offer decisions (KeepCard integration)

/llms-full.txt — compact, machine-oriented. Covers protocol version, supported transports (REST, MCP, Embedded), capability inventory, and explicit safe probing guidance.

Both are generated dynamically from live merchant capabilities. If cart is disabled, the cart section doesn't appear. If KeepCard isn't active, no keep-offer guidance is included. Nothing is hardcoded; nothing claims unsupported behavior.

Here's what it looks like for a real production store — House of Parfum, currently #1 on ucpchecker.com with a perfect 100/100 score:

# House of Parfum

This merchant uses UCPReady and publishes UCP-compatible shopping
endpoints for AI agents.

## Merchant Profile

- **Store:** House of Parfum
- **Description:** Van iconische parfums tot luxe skincare
- **Discovery:** https://houseofparfum.nl/.well-known/ucp
- **Shop:** https://houseofparfum.nl/shop/

## Start Here

- Discover this merchant from https://houseofparfum.nl/.well-known/ucp
- Use the service endpoint advertised in the profile.
- Do not assume /api/ucp/mcp.
- MCP endpoint: https://houseofparfum.nl/wp-json/ucpready/v1/mcp
- REST endpoint: https://houseofparfum.nl/wp-json/ucpready/v1

## Supported Capabilities

- Catalog browsing and product lookup
- Cart creation and update
- Checkout creation, update, and completion
- Order lookup
- Return flows
- Identity linking
- Embedded checkout

## Checkout Guidance

- Create checkout first, then update it with buyer, fulfillment,
  and payment data as needed.
- Read payment handlers from the live checkout response.
- If checkout reaches a completed state, use the final order as
  the source of truth for totals and discounts.
- Treat coupon failures as recoverable checkout issues, not as
  silent success.

## Returns Guidance

- This merchant supports return tooling.
- Return flows may include optional retention / keep-offer decisions
  when enabled by merchant integrations.
- Ask the buyer before accepting or declining any keep-offer outcome.

## Payment Handlers

- dev.ucp.delegate_payment
- com.terrawallet.store_credit

## Escalate to the Buyer When

- variant or quantity selection is ambiguous
- identity linking is required
- coupon validation fails
- the merchant response requires approval or additional buyer action

You can hit it live: houseofparfum.nl/agents.md

Why this matters more than it might look

When Google announced Universal Cart at I/O 2026, the commerce director described UCP as "a common language that lets agents reach businesses securely and seamlessly." Universal Cart, AI Mode checkout, YouTube Shopping — they all run on it.

The stores that benefit are the ones agents can actually work with reliably. A broken or ambiguous implementation gets abandoned. A store with a valid manifest, correct capability declarations, and clear operating guidance gets completed transactions.

Shopify's approach is to bundle instructions in a CLI. That works for Shopify's ecosystem. Our approach is to publish instructions on the merchant's own domain, discoverable by any agent from any platform.

The instruction layer is not optional anymore. It's part of what makes a store agent-ready.

That's the WooCommerce answer to what Shopify bundled in their CLI — platform-level agent guidance, open and accessible, not locked to a single discovery surface.

If you're running WooCommerce and want to see where your store stands: ucpchecker.com

UCPReady is at zologic.nl/ucpready.

Shopify Just Gave AI Agents an Operating Manual. We Built One for WooCommerce.

Almin Zolotic — Thu, 21 May 2026 22:45:41 +0000

When Shopify shipped @shopify/ucp-cli last week, most of the coverage focused on the obvious part: AI agents can now browse and buy from Shopify stores using the Universal Commerce Protocol.

What got less attention was the file bundled inside the package — SKILL.md.

Shopify proved something important: protocol + agent instructions is stronger than protocol alone.

We shipped that this week.

The gap Shopify exposed

UCP standardizes the transport and schema. Every conformant store — Shopify, WooCommerce, BigCommerce, custom — exposes the same protocol surface. That's the point.

But Benji Fisher at UCP Checker wrote a sharp breakdown of what Shopify's CLI actually does, and one line stuck:

It can buy from any UCP-compliant store on any platform. It can only find Shopify stores.

The discovery layer defaults to catalog.shopify.com. The transaction layer is pure, open UCP. Shopify owns the index; the protocol is shared.

What we shipped: the Agent Guidance Layer

UCPReady now auto-generates two public documents on every merchant site:

/agents.md — human and agent readable Markdown. Tells any agent:

Start with /.well-known/ucp, use the advertised endpoint, never assume /api/ucp/mcp
What capabilities this specific merchant supports (cart, checkout, orders, returns, identity linking, embedded checkout)
How to sequence checkout operations
What payment handlers are available
When to stop and escalate to the buyer
Whether return flows include retention/keep-offer decisions (KeepCard integration)

/llms-full.txt — compact, machine-oriented. Covers protocol version, supported transports (REST, MCP, Embedded), capability inventory, and explicit safe probing guidance.

Here's what it looks like for a real production store — House of Parfum, currently #1 on ucpchecker.com with a perfect 100/100 score:

# House of Parfum

This merchant uses UCPReady and publishes UCP-compatible shopping
endpoints for AI agents.

## Merchant Profile

- **Store:** House of Parfum
- **Description:** Van iconische parfums tot luxe skincare
- **Discovery:** https://houseofparfum.nl/.well-known/ucp
- **Shop:** https://houseofparfum.nl/shop/

## Start Here

- Discover this merchant from https://houseofparfum.nl/.well-known/ucp
- Use the service endpoint advertised in the profile.
- Do not assume /api/ucp/mcp.
- MCP endpoint: https://houseofparfum.nl/wp-json/ucpready/v1/mcp
- REST endpoint: https://houseofparfum.nl/wp-json/ucpready/v1

## Supported Capabilities

- Catalog browsing and product lookup
- Cart creation and update
- Checkout creation, update, and completion
- Order lookup
- Return flows
- Identity linking
- Embedded checkout

## Checkout Guidance

- Create checkout first, then update it with buyer, fulfillment,
  and payment data as needed.
- Read payment handlers from the live checkout response.
- If checkout reaches a completed state, use the final order as
  the source of truth for totals and discounts.
- Treat coupon failures as recoverable checkout issues, not as
  silent success.

## Returns Guidance

- This merchant supports return tooling.
- Return flows may include optional retention / keep-offer decisions
  when enabled by merchant integrations.
- Ask the buyer before accepting or declining any keep-offer outcome.

## Payment Handlers

- dev.ucp.delegate_payment
- com.terrawallet.store_credit

## Escalate to the Buyer When

- variant or quantity selection is ambiguous
- identity linking is required
- coupon validation fails
- the merchant response requires approval or additional buyer action

You can hit it live: houseofparfum.nl/agents.md

Why this matters more than it might look

The instruction layer is not optional anymore. It's part of what makes a store agent-ready.

That's the WooCommerce answer to what Shopify bundled in their CLI — platform-level agent guidance, open and accessible, not locked to a single discovery surface.

If you're running WooCommerce and want to see where your store stands: ucpchecker.com

UCPReady is at zologic.nl/ucpready.

I Replaced a Returns Portal with Five MCP Tools. Here's What Actually Happened.

Almin Zolotic — Thu, 30 Apr 2026 20:06:06 +0000

A live WooCommerce journey where a model searched products, completed a purchase, and handled a return with keep-offer logic — through UCPReady and KeepCard.io on the Universal Commerce Protocol.

Most "AI commerce" demos are still just chat layered on top of old flows.

Tonight we did something different.

We ran a live WooCommerce journey where a model:

searched products
helped complete a purchase
and then handled a return with keep-offer logic

Not on a mock store. Not with human agents behind the curtain. Not with Claude-specific business logic buried in the backend. And not by building "AI features" into the store itself.

This ran through UCPReady and KeepCard.io — two products I built — using protocol-native rails so the model could interact with the store as an agent.

The transcript in one line

This was the actual lifecycle:

Customer asked for a face cleanser
Model searched the live WooCommerce catalog
Customer bought two products
Checkout ran through UCPReady
Payment used wallet rails plus browser authorization
Order completed
Customer changed their mind about one item
KeepCard.io verified the order, surfaced the line items, collected the reason, and presented a keep offer
Customer accepted the offer
A real discount code was generated
A real confirmation email was sent

That is the entire commerce loop in one conversational journey.

What actually happened

The session started like a normal shopping flow. The model searched a live WooCommerce store, found products, built a checkout, selected fulfillment, selected payment, and moved through the purchase flow using UCPReady.

Then, in the same broader system, we tested returns through KeepCard.io.

The return flow did this:

Looked up the order by order number and email
Checked eligibility
Collected the return reason
Evaluated keep-offer logic
Presented the customer with a keep offer in chat
Accepted the offer
Generated a real discount code
Sent the confirmation email

We saw the discount code issued. We saw the email arrive. We saw the KeepCard dashboard record the return session as Kept.

That is not "AI-assisted support." That is a real agentic commerce lifecycle.

A real example from tonight

The customer started with:

I want to buy something to clean my face

The model searched the live catalog and found:

Rilastil Aqua Face Cleanser 200ml — €16.95
Shiseido Men Face Cleanser 125ml — €18.95

The customer then said:

buy me 2 of Rilastil Aqua Face Cleanser 200ml and 1 Shiseido Men Face Cleanser 125ml

The system created checkout, configured fulfillment and wallet payment, and moved the buyer into the final authorization step.

After the order completed, the customer came back with:

Oh no, I made a mistake — I want to return the item

The return flow asked for the order number, verified eligibility, and surfaced the exact purchased items:

Rilastil Aqua Face Cleanser 200ml (Quantity: 2)
Shiseido Men Face Cleanser 125ml (Quantity: 1)

The customer selected only the Shiseido item. Then gave the reason:

Other — I made a mistake

Instead of routing to a standard return portal, the system evaluated the return and offered a keep option:

You can keep the Shiseido Men Face Cleanser and receive €1.00 off your next order as a discount code.

The customer replied:

Accept

The result:

Keep offer accepted ✓
Discount code KEEP-3V9FNM generated in WooCommerce ✓
Confirmation email delivered via KeepCard's email stack ✓
No return shipment needed ✓

That is exactly the kind of post-purchase flow that usually lives inside rigid portals, manual support queues, or custom integrations tied to one model vendor. Tonight it happened conversationally on top of a live WooCommerce stack.

The architecture: what UCPReady and KeepCard.io actually are

UCPReady is a WooCommerce plugin that implements the Universal Commerce Protocol (UCP) — an open protocol for exposing store capabilities through structured, machine-operable interfaces. It turns a WooCommerce store into a UCP-compliant endpoint that AI agents can discover and transact with autonomously.

The MCP endpoint on houseofparfum.nl exposes these tools:

— shopping —
ucp_list_products       ucp_get_product
create_checkout         get_checkout
update_checkout         complete_checkout
cancel_checkout         create_cart
get_cart                update_cart
cancel_cart             convert_cart
ucp_get_order           ucp_list_orders

— returns (KeepCard) —
keepcard_check_return_eligibility
keepcard_select_return_items
keepcard_submit_return_reason
keepcard_accept_keep_offer
keepcard_decline_keep_offer

KeepCard.io is a standalone returns intelligence platform. It connects to WooCommerce via REST API and Shopify via app installation. It owns the decision engine — return eligibility, keep-offer thresholds, fraud signals, monthly caps, discount code generation, and email delivery. None of that logic lives in the LLM.

The UCPReady companion plugin for KeepCard exposes five MCP tools that let any agent drive the return flow conversationally, while KeepCard handles all the business logic and side effects server-side.

The important part: no AI in the business logic

This is the part worth repeating.

There is no hidden LLM orchestration inside the return engine. There is no model deciding business logic in the backend. There is no "if Claude says X, do Y" architecture.

The business logic is deterministic:

Return eligibility
Order verification
Keep-offer thresholds
Duplicate protection
Policy routing
Store credit and discount issuance

The model is only the interface layer.

That makes the system:

Model-agnostic — Claude, GPT-5, Gemini, Grok all work
Easier to audit — no prompt-based rules buried in a system prompt
Easier to harden — business rules are code, not inference
More future-proof — swap the model, the commerce layer stays the same

The same session ran successfully with both Claude Sonnet 4.5 and GPT-5. Neither needed store-specific prompting. The protocol carries the context.

How the return flow chains through UCPReady

The integration works server-to-server. When the agent calls keepcard_check_return_eligibility, UCPReady makes an HTTP POST to the KeepCard /api/mcp/init endpoint with the store slug, order ID, and email. KeepCard resolves the order directly against WooCommerce or Shopify using its own stored credentials — UCPReady never touches the order data.

The full call chain looks like this:

Agent → UCPReady MCP endpoint (WooCommerce)
      → KeepCard /api/mcp/* (cloud service)
      → WooCommerce or Shopify API (order verification)
      → KeepCard decision engine (keep-offer logic)
      → WooCommerce API (discount code creation)
      → KeepCard email stack (confirmation)
      → back through the chain to the agent

The LLM sees clean structured responses at each step:

// keepcard_check_return_eligibility response
{
  "eligible": true,
  "session_id": "...",
  "needs_item_selection": true,
  "customer_message": "I found order #85774. You have 30 day(s) left to return it. Which item(s) would you like to return?",
  "order": {
    "display_id": "85774",
    "items": [...],
    "currency": "EUR",
    "days_remaining": 30
  }
}

// keepcard_accept_keep_offer response
{
  "outcome": "kept",
  "discount_code": "KEEP-3V9FNM",
  "amount": 1.00,
  "currency": "EUR",
  "email_sent": true,
  "customer_message": "Done! Your discount code is KEEP-3V9FNM — worth 1.00 EUR off your next order. A confirmation has been sent to your email."
}

The customer_message field means the agent surfaces KeepCard's language directly — it does not have to infer what to say from raw API data.

Why this is different from what's already out there

Most of what is marketed today as "AI returns" falls into one of these buckets:

Approach	What it actually is
Chatbot on a returns portal	AI layer on top of an existing flow, still ends in a form
Custom automation project	Tied to one model vendor, one store, one integration
Shopify-first AI returns	Good tooling, but WooCommerce is a different ecosystem
Refund infrastructure for devs	Powerful but requires significant custom work

Those are real products. But they are still mostly AI applications sitting on top of commerce systems.

What we are building is different: the commerce system itself becomes operable by agents.

UCPReady exposes structured commerce capabilities through UCP and MCP. KeepCard.io exposes post-purchase capabilities through the same kind of machine-operable interface. The store does not wait for us to write Claude-specific code, GPT-specific prompts, or Gemini-specific workflows.

The model is replaceable. The protocol is the product.

Why WooCommerce specifically matters

A lot of public examples in this space are Shopify-first. That makes sense — Shopify has a louder app ecosystem and more visible AI tooling.

But what happened tonight was on WooCommerce.

WooCommerce powers a large share of the world's online stores. It has almost no public examples of protocol-driven, frontier-model, post-purchase flows. The combination of:

WooCommerce-native
Protocol-native (UCP)
Model-agnostic
Agent-executable
Post-purchase keep-offer logic

...is the category we are helping define. I have not seen a strong public proof of this combination before tonight.

What broke (because honesty matters)

Tonight was not a perfect demo, and that is exactly why it was valuable.

1. The keep-offer accept step was occasionally slow. The final keepcard_accept_keep_offer step sometimes exceeded the runner timeout budget. The business action still completed — coupon created, email sent, session marked kept — but the agent runner could report failure because the round trip took too long. This is a bridge latency problem, not a logic problem.

2. Duplicate finalization needed hardening. When the first accept completed but the runtime retried, we needed the system to treat the retry as a successful terminal state rather than an error. Repeated accept should return: already processed, discount code, final state. That is what resilient agent commerce looks like.

3. Mixed shopping and returns in one session exposed session contamination. In one test, we ran search → purchase → return inside a single session. That exposed a session-orchestration issue: return tools were receiving stale search arguments from the earlier shopping flow. Not a KeepCard logic problem. A session-context boundary problem. The kind you only discover once the stack is real enough to chain these experiences together.

Where we go next

The hardest question has been answered: can a model search, buy, and then resolve a return with keep-offer logic on a live WooCommerce store through protocol-native rails?

Yes. Tonight, it did.

The remaining work is hardening, not architecture:

Reduce latency on the post-purchase bridge
Keep terminal actions idempotent across retries
Isolate session state between shopping and returns flows
Test identity linking across multi-session journeys
Validate the same lifecycle across more stores

When the remaining problems are latency budgets, idempotency, and session context boundaries — you are no longer asking whether the concept works. You are refining a working system.

The bigger idea

The goal is not "AI can help with returns."

The goal is: stores should become operable by agents through standard protocols.

Search is one capability. Checkout is one capability. Payment is one capability. Returns are one capability. Keep-offers are one capability. Once those are exposed properly through open protocol rails, the model becomes interchangeable.

That is when agentic commerce stops being a gimmick and starts becoming infrastructure.

UCPReady: zologic.nl/ucpready — WooCommerce UCP implementation

KeepCard.io: keepcard.io — Returns intelligence platform

Session recording: ucpplayground.com/s/01KQFVJJK6HZF2Z58MVMZQ3WXP

Universal Commerce Protocol: ucp.dev

60 seconds to see if your webstore supports the latests UCP protocol. Give it a run!

Almin Zolotic — Thu, 30 Apr 2026 12:03:40 +0000

Benji Fisher

Apr 30

Is My Store UCP Ready? How to Check in 60 Seconds

#ecommerce #webdev #tutorial #ucp

5 min read

The 0.2% flawless rate from your April report is wild. Most stores have a manifest. Almost none actually work end-to-end. It's a conformance problem, not an infrastructure problem — and that's exactly what this score makes visible. Love what you built here

Almin Zolotic — Wed, 29 Apr 2026 11:29:46 +0000

Benji Fisher

Apr 29

Introducing the UCP Score: A 0–100 Agent-Readiness Grade for Every UCP Store

#ecommerce #ai #product #ucp

8 min read

AP2 Mandates Are Live on UCPReady — Here's What That Actually Means for Autonomous Payment

Almin Zolotic — Fri, 24 Apr 2026 19:42:29 +0000

Zero merchants in Ben Fisher's 4,024-merchant UCP dataset support native payment. I've been building toward closing that gap since March. Today it's done — at least on the business side.

This post is about AP2 Mandates: what they are, why they're the only spec-compliant path to autonomous card payment on UCP, and what it took to implement them correctly on WooCommerce.

Why every UCP checkout still ends with a browser redirect

When an AI agent completes a UCP checkout today, it gets a continue_url. The buyer clicks a link, lands on the WooCommerce checkout page, fills in their card, and pays. The agent handled discovery and session setup. The human handled payment.

That handoff exists because the spec requires it — unless one specific extension is active.

From the UCP checkout specification:

"The checkout has to be finalized manually by the user through a trusted UI unless the AP2 Mandates extension is supported."

That "unless" is the entire autonomous payment story in UCP. Not Stripe tokens. Not saved cards. Not wallet APIs. AP2 Mandates.

What AP2 Mandates actually are

AP2 is a cryptographic authorization framework. When it's negotiated between a business and a platform, the checkout session is "security locked" — neither party can revert to an unprotected flow.

The flow has two sides:

Business side: Every checkout response must include ap2.merchant_authorization — a JWS detached signature proving the checkout terms (price, line items, totals) are authentic and haven't been tampered with. The signature is ES256, JCS-canonicalized per RFC 8785, with the payload excluded from the JWS body (RFC 7515 Appendix F detached content format).

Platform side: When the user confirms the purchase, the platform generates a cryptographically signed mandate — an SD-JWT credential proving the user explicitly authorized this specific transaction. It submits that mandate at complete_checkout. The business verifies it. If valid, payment proceeds without a browser redirect.

The checkout mandate contains the full checkout response including the business's merchant_authorization. So the platform's signature covers the business's signature. It's a nested cryptographic binding: the business proves the terms, the platform proves the user consented to those exact terms.

What implementing this actually required

Getting the signing right

The spec says ES256 with detached JWS. In PHP, openssl_sign() on a P-256 key produces a DER-encoded ECDSA signature. JWS ES256 requires raw r||s — 64 bytes for P-256. Those are not the same format.

Every JWS library you'd use on the platform side (jose, python-jose, jsonwebtoken) expects raw r||s. A DER signature will fail verification silently or throw a malformed signature error. The fix is a DER-to-raw-rs converter:

// openssl_sign() → DER. JWS ES256 → raw r||s. Not the same.
openssl_sign( $signing_input, $signature_der, $private_key, OPENSSL_ALGO_SHA256 );
$r = substr( $der_inner, $r_offset, $r_len );
$s = substr( $der_inner, $s_offset, $s_len );
$signature_raw = str_pad( ltrim($r, "\x00"), 32, "\x00", STR_PAD_LEFT )
               . str_pad( ltrim($s, "\x00"), 32, "\x00", STR_PAD_LEFT );

The JCS canonicalization (RFC 8785) is the other non-obvious requirement. Before signing, the checkout payload is canonicalized — keys sorted recursively, Unicode normalized, numbers in IEEE 754 format. This ensures the signature is reproducible across systems that may re-serialize JSON differently.

Enforcing the mandate at complete_checkout

The spec is explicit: if AP2 was negotiated, complete_checkout MUST reject requests without ap2.checkout_mandate. This is the security boundary. Without it, AP2 is advertised but provides no protection — a platform could skip the mandate entirely and the checkout would succeed.

The enforcement block runs before order creation:

if ( $ap2_ext->is_ap2_configured() ) {
    $mandate_jwt = $body['ap2']['checkout_mandate'] ?? null;
    if ( empty( $mandate_jwt ) ) {
        // Return mandate_required error — session stays ready_for_complete
        return $this->mandate_error_response( 'mandate_required', $session );
    }
    $mandate_error = $ap2_ext->verify_checkout_mandate( $mandate_jwt, $session, $request );
    if ( null !== $mandate_error ) {
        return $this->mandate_error_response( $mandate_error['code'], $session );
    }
}

Verifying the mandate

When a mandate is present, the full verification chain runs:

Parse the SD-JWT structure (header.payload.signature~disclosures~keybinding)
Check expiry (exp claim)
Extract the embedded checkout from mandate claims
Re-verify merchant_authorization — confirm the platform wrapped our own signature, not a different checkout
Verify checkout ID matches the current session
Verify totals match — no bait-and-switch between what the user saw and what gets charged

Platform key verification

The final step: verifying the SD-JWT outer signature using the platform's public key. This is what proves the mandate is genuinely from the platform and not forged.

The flow: decode the JWS header → extract alg and kid → fetch the platform's UCP profile from the UCP-Agent header → pull signing_keys → find the JWK matching kid → build an OpenSSL public key from the JWK x/y coordinates → verify.

Building an EC public key from JWK coordinates without a library means constructing the SubjectPublicKeyInfo DER by hand in PHP — OID encoding, SEQUENCE wrapping, BIT STRING for the uncompressed EC point. It's ~80 lines but removes a runtime dependency and works on any WordPress host.

The platform profile is fetched over HTTPS and cached with WP transients, respecting Cache-Control max-age with a 60-second floor. Verification result is logged with kid, algorithm, and session ID for auditability.

The capability name that broke everything

Before any of this verification mattered, there was a simpler bug: the capability was advertised as dev.ucp.shopping.ap2_mandates — plural. The spec uses dev.ucp.shopping.ap2_mandate — singular.

Capability negotiation is a string equality check. The intersection algorithm finds no match between ap2_mandates and ap2_mandate. AP2 is never activated. Every checkout session falls back to delegate payment. No error, no warning — it silently never negotiates.

One character. Every implementation should validate capability names against the spec registry rather than trusting their own strings.

What's live now

When dev.ucp.shopping.ap2_mandate is enabled in UCPReady and a compatible platform connects:

Every checkout response includes ap2.merchant_authorization (JWS ES256, detached, JCS payload)
complete_checkout rejects requests without ap2.checkout_mandate
Verification runs: SD-JWT parse → expiry → embedded checkout extraction → merchant_authorization re-verification → ID and totals match → platform key verification
If all checks pass, payment proceeds — no browser redirect

The one remaining piece is ecosystem readiness: a platform that supports AP2 mandate submission and forwards the access token that proves identity linking. Ben Fisher's UCPPlayground is the logical first test. Once that's connected, UCPReady will produce the first confirmed AP2-mandate-verified autonomous purchase on WooCommerce.

Why this matters beyond WooCommerce

Ben's dataset of 4,024 merchants shows zero native payment support. Part of that is the SPT/ACS story — Stripe's Shared Payment Token is US-only right now and requires Stripe to host the checkout flow. That's a different architecture than UCP.

On UCP, AP2 Mandates is the spec's answer. It's protocol-agnostic — the mandate can cover any payment method handled by any PSP. The platform proves user consent cryptographically. The business verifies that proof and charges via their existing payment gateway. No card data crosses protocol boundaries. PSD2 SCA compliance comes from the mandate being platform-issued and buyer-authenticated at mandate creation time.

This is what autonomous agent commerce looks like when the merchant controls the checkout instead of delegating it to Stripe's infrastructure.

UCPReady is available at zologic.nl/ucpready.

If you're building a platform that supports UCP and want to test AP2 mandate submission against a live endpoint, reach out. houseofparfum.nl is running UCPReady 1.8.23 with AP2 ready to activate.