DEV Community: Giuseppe Socci

The website chatbot was a workaround, not a solution

Giuseppe Socci — Thu, 25 Jun 2026 09:27:31 +0000

Open almost any company website built in the last two years and a little circle pops up in the bottom-right corner. "Hi! How can I help you today?"

You already know how this goes. You type a real question, the bot hands back a help-center link you'd already found, and you end up emailing support anyway.

We've collectively decided that every website needs a chatbot. I think we added them for the wrong reason — and the reason is more interesting than the complaint.

The pattern we all recognize

The generic site bot has three problems, and they're structural, not cosmetic.

It only knows your site. It was trained or indexed on a narrow slice of your own content, so the moment a question steps outside that slice, it has nothing. Ask it something a human support agent would answer in one sentence by combining two facts, and it stalls.

It has no real capability. It can't check your actual order, can't see live stock, can't do the thing you came to do. It retrieves text and reformats it.

And it interrupts. It's a layer between you and the page, and most of the time you'd rather just read the page.

None of this is a knock on any particular vendor. The bots behave this way because of what they fundamentally are. Which is the part worth examining.

Why they're everywhere

Here's my claim: chatbots spread across the web not because users wanted them, but because they were the only way we had to put "AI" on a website.

Think about the actual sequence of events. A company decides it needs an AI story. The available, off-the-shelf, drop-in-a-script-tag option is a chatbot widget. So a chatbot widget is what gets installed. The technology answered a marketing question — "how do we show we have AI?" — not a user question — "how do I get my answer faster?"

That's the definition of a workaround: a thing you reach for because it's available, not because it's right.

How these things actually work

I recently asked a popular chatbot vendor — through their normal support channel — to explain in detail how their system ingests and answers from a website's data. The reply was polite, professional, and genuinely illuminating. I'll keep it anonymous, because the point isn't to single anyone out; this is how the whole category works today.

Three things stood out.

It answers from a snapshot, not from your live site. When a user asks a question, the bot does not read your website at that moment. It reads a copy it indexed earlier — refreshed on a schedule, daily, weekly, or monthly. For a blog that's fine. For anything that changes — prices, availability, terms — it means the bot can confidently cite information that's weeks stale, with no signal to the user that it's looking at an old photograph.

It can't follow a paginated feed. I asked how it walks through a structured catalog with multiple pages. It doesn't. The recommended workaround was to flatten everything into a list of separate static URLs and hand it an XML sitemap. In other words: to ingest a modern structured source, go back to the one-document-per-page model from twenty years ago, because the ingester can't traverse a feed.

The capabilities you'd need are upsells. Things like preserving query-string URLs, ingesting paginated feeds, and handling structured catalogs properly weren't standard. They were described as things they'd consider building for customers on a paid plan.

Sit with that. The entire architecture is designed around not looking at the live source. Snapshot, scheduled recrawl, flattened sitemap — every piece exists to avoid reading your site at the moment the question is asked. The bot doesn't read your website. It keeps a faded photocopy and answers from that.

What the user actually wanted

Step back to the person typing the question. They never wanted an assistant living inside your website. They wanted an answer. And increasingly they're getting it somewhere else entirely — by asking the assistant they already have open, before they ever land on your page.

That's the shift the chatbot misses completely. The chatbot assumes the AI should live on your site. But the AI users actually rely on doesn't live on anyone's site. It's the general assistant in their pocket — and it's perfectly capable of reading and reasoning over real, current information if the information is exposed in a way it can read.

From "AI on my site" to "my site readable by AI"

This is the reframing I think matters.

The chatbot approach brings a weak, sandboxed AI into your page. The opposite approach makes your content legible to the strong, general AI the user already uses. One traps a bad assistant on your site; the other frees your content to be read by a good one.

And the second one is where the platforms are quietly heading. Structured, machine-readable content. Standard protocols for agents to discover and read what a site offers. The shift is from optimizing a page for a human eye (and a search crawler) to also making it readable by an agent acting on a person's behalf — reading the current data, following the actual structure, reasoning over what's really there rather than a month-old copy.

That's the exact inverse of the snapshot-and-sitemap model. The agent reads the source, now. No photocopy.

This isn't free

I don't want to pretend the readable-to-agents direction is pure upside. It moves the hard problems rather than removing them, and two of them are worth naming honestly.

The first is the business model. If a customer's assistant reads your data and resolves the question — or even completes a purchase — without the customer ever landing on your page, what happens to everything that page was doing? The cross-sell, the brand experience, the related products, the ad you were going to show. Search engines already started this with zero-click answers; agents push it further. Making your content legible to an external assistant solves the information problem and sharpens a monetization problem that nobody has a clean answer to yet.

The second is liability. If an assistant misreads your data — even data you structured carefully and exposed correctly — and tells the user something wrong, who's responsible? The site that published it, the assistant that interpreted it, or the vendor behind the assistant? There's no settled answer, legally or in practice.

I'm not going to resolve those here, and I'd be suspicious of anyone who claims to. But notice they don't rescue the chatbot. A bot answering from a stale snapshot has the same exposure problems with worse information. The hard questions are real — they're just the hard questions of the right direction instead of the wrong one.

The takeaway

If you're responsible for a website and you're thinking about AI, the instinct is to add a chatbot. I'd push back on that instinct.

A bot trapped on your page, answering from a stale copy of your own content, is solving a problem your users don't have. The problem they actually have is that the assistant they're already talking to can't yet read your site clearly.

So the question isn't "which chatbot should I install?" It's "is my content readable by the agents people already use?"

Stop optimizing for a chatbot stuck in the corner of your page. Start making your content legible to the agents people bring with them.

Turn Woo catalog into an AI-ready API — now on WordPress.org

Giuseppe Socci — Thu, 18 Jun 2026 16:47:20 +0000

AI agents are starting to shop. Not in a sci-fi way — in a "your storefront is getting hit by something that parses HTML, recovers a price, and gets it wrong" way. If you run a WooCommerce store, the agent reading it today has to scrape the rendered product page and reverse-engineer what's for sale, what it costs, and whether it's in stock.

That's fragile, and it's the wrong layer. A catalog already knows all of this precisely. It should just say so, in a format built for machines.

That's what KaliCart Bridge does — a WooCommerce plugin (now on the WordPress.org directory, search "KaliCart Bridge") that exposes the catalog as a read-only, agent-oriented API with a discovery document. Below is how it's designed and why, with real responses from a live install.

Start with discovery, not endpoints

The entry point is a single discovery document. An agent fetches it first and learns the catalog's capabilities, endpoints, and rules before issuing a single product query:

GET /wp-json/kalicart/v1/discovery

{
  "document_kind": "kalicart_merchant_bridge",
  "schema_version": "1.0",
  "plugin_version": "1.0.101",
  "capabilities": {
    "search": true,
    "availability": true,
    "shipping_policy": true,
    "cart": false,
    "checkout": false,
    "payments": false,
    "mutations": false,
    "read_only": true,
    "mcp": true
  },
  "freshness": {
    "source": "live_woocommerce_database",
    "is_realtime": true,
    "is_sync_snapshot": false
  }
}

Two design choices worth calling out here:

It's read-only and says so explicitly. cart, checkout, payments, and mutations are all false. The Bridge is a read surface over the catalog — it never touches orders or money. Checkout authority stays with the WooCommerce storefront. An agent reading this knows immediately what it is and isn't allowed to assume.

Data is live, not a sync snapshot. Responses are read straight from the WooCommerce database at query time. There's no separate index to fall out of date — the price the agent reads is the price in the store right now.

The endpoints

Discovery advertises the read surface:

{
  "endpoints": {
    "discovery":  "/wp-json/kalicart/v1/discovery",
    "search":     "/wp-json/kalicart/v1/catalog/search",
    "products":   "/wp-json/kalicart/v1/catalog/products",
    "product":    "/wp-json/kalicart/v1/catalog/product/{id}",
    "categories": "/wp-json/kalicart/v1/catalog/categories",
    "meta":       "/wp-json/kalicart/v1/catalog/meta",
    "mcp":        "/wp-json/kalicart/v1/mcp"
  },
  "authentication": { "required": false, "scheme": "none" }
}

No API key. The public catalog is public — the same information a human sees on the storefront, just structured.

Query construction: the spine goes in `q`, attributes go in filters

This is the part most people get wrong when they design a search API for agents, so the discovery document is prescriptive about it:

{
  "query_construction": {
    "rule": "q must contain ONLY the bare product noun (the spine). Every attribute (category, gender, color, price) MUST go in its own structured filter, never inside q. Stacking attributes into q returns 0 results.",
    "correct": [
      "?q=t-shirt&gender=male&max_price=50",
      "?q=costume&gender=female&color=blue"
    ]
  }
}

Agents love to cram "blue men's t-shirt under 50" into a single search string. Against a real catalog, that returns nothing. By splitting the product spine (q=t-shirt) from structured filters (gender, color, max_price), search stays predictable and the agent gets results instead of an empty array. The contract tells the agent how to behave, so you don't depend on it guessing right.

A real search response

GET /wp-json/kalicart/v1/catalog/search?q=t-shirt&max_price=50

{
  "success": true,
  "total": 1,
  "products": [
    {
      "id": 460,
      "name": "T-shirt Nike Sportswear",
      "price": {
        "currency": "EUR",
        "encoding": "decimal_major_units",
        "regular": 22,
        "sale": 20,
        "current": 20,
        "on_sale": true,
        "discount_pct": 9.1,
        "display": "20,00 €"
      },
      "stock": {
        "availability_status": "in_stock",
        "in_stock": true,
        "quantity_tracked": false,
        "confidence": "availability_status_only",
        "agent_note": "Merchant does not expose numeric stock quantity. Treat as available for purchase, not as confirmed inventory count."
      },
      "categories": [
        { "id": 33, "name": "Uomo", "slug": "uomo", "path": "Moda > Uomo" }
      ]
    }
  ]
}

Notice what's modeled here that scraping can't reliably recover:

Price is unambiguous. current, regular, sale, and the on-sale flag are separate fields, plus a display string for humans and an explicit encoding so nobody confuses major units with ISO minor units.
Stock carries its own confidence. This merchant doesn't track numeric inventory, so the response says so and tells the agent how to interpret it — "available for purchase" is not the same claim as "47 in stock." That distinction is the difference between an agent making a safe statement and a wrong one.
Categories are the merchant's own. The Bridge doesn't force a global taxonomy onto the store; it exposes the merchant's native WooCommerce categories with their full path, and a /catalog/categories endpoint to enumerate them. The principle behind the whole thing is that the domain constrains the machine, not the merchant.

Evidence-required reasoning

The discovery document also ships a rule that's more about agent behavior than data shape:

{
  "evidence_required": {
    "rule": "Every product claim must be traceable to a catalog field.",
    "sources": ["product_url", "price.current", "stock.in_stock", "stock.confidence"],
    "note": "Do not present prices, availability or shipping estimates without citing the source field."
  }
}

The point is to make hallucination structurally harder. If every claim an agent makes has to map back to a concrete field, it can't invent a price or a delivery promise — it either has the field or it doesn't.

REST or MCP — same data

For agent runtimes that speak Model Context Protocol, the same read-only catalog is exposed as an MCP server over JSON-RPC 2.0:

{
  "mcp": {
    "enabled": true,
    "transport": "http-post-jsonrpc-2.0",
    "endpoint": "/wp-json/kalicart/v1/mcp",
    "tools": ["search_products", "get_product", "list_products", "list_categories", "get_meta"]
  }
}

Same catalog, same read-only guarantees — pick whichever your stack prefers. REST if you're calling HTTP directly, MCP if you're wiring it into an agent framework that already speaks the protocol.

Where checkout lives (and doesn't)

The Bridge deliberately stops short of payment. There's a defined contract for an optional checkout session — create a WooCommerce cart and hand back a checkout_url for a human to finish — but it processes nothing and creates no order. Full autonomous checkout (agent holds a pre-authorized mandate, completes the purchase end to end) is on the roadmap as an AP2-compatible contract, gated on WooCommerce/gateway support for programmatic payment confirmation. Until that exists, the safe boundary is: agents read the catalog, humans (or a redirect) own the money.

Try it

It's free on the WordPress.org directory — search "KaliCart Bridge" in your plugins page, activate, and your catalog gets a discovery document and the read endpoints above. Then curl your own /wp-json/kalicart/v1/discovery and point an agent at it.

Feedback from people who build agents or live in WooCommerce internals is exactly what I'm after — especially catalog edge cases and anything in the agent contract that reads ambiguously.

Your WooCommerce store is now readable by AI agents. It still isn't comparable — and that's the harder problem.

Giuseppe Socci — Sat, 13 Jun 2026 18:27:14 +0000

Your WooCommerce store is now readable by AI agents. It still isn't comparable — and that's the harder problem.

If you read my last post, you added an agent-readable API to your WooCommerce store — or you're counting on the WooCommerce MCP that shipped in 10.3. Either way, an AI assistant can now access more of your store data. But access is not the same as cross-merchant comparability.

You've solved visibility. You have not solved comparability. And comparability is the whole game.

Readable is not comparable

When someone tells an agent "find me a waterproof jacket under €150 in size M", the agent isn't shopping one store. It's lining up candidates from many stores and ranking them on the same axes: category, size, color, price including tax, availability right now.

To do that it needs every store to speak the same language for those axes. Reading one store is easy. Comparing fifty is the problem — because fifty WooCommerce stores describe the same product in fifty different ways.

The same t-shirt, fifty shapes

WooCommerce is open-source and composable. That's its strength for merchants and its liability for agents: there is no platform-enforced semantic model shared across stores, so every store invents its own.

The same cotton t-shirt, across three stores, looks like this to a machine:

size: M / Taglia M / 48
category: Apparel > Men > T-shirts / Magliette / Abbigliamento/Uomo
price: 29.00 (tax included) / 23.77 (tax excluded) / "29,00 €" as a string
the "color" attribute: a taxonomy term in one store, a custom field in another, baked into the title in a third

None of these is wrong. They're all valid WooCommerce. That's exactly why it's hard.

And it gets worse below the surface. In one real catalog I audited, a single dimensions field was being populated in about ten mutually incompatible shapes, and roughly one value in six was physically impossible when read as centimeters. One store. One field.

This is WooCommerce's tax, not a bug

Shopify has less of this problem at the platform boundary, because it controls more of the product and checkout model. That control is — not coincidentally — why it keeps showing up as the launch partner for every agentic surface.

Look at who went live first. ChatGPT's Instant Checkout launched in September 2025 with U.S. Etsy sellers first, and OpenAI announced over a million Shopify merchants as the next channel. Google's Universal Cart was announced at I/O 2026; Google named Nike, Sephora, Target, Ulta Beauty, Walmart, Wayfair, and Shopify merchants among the brands for upcoming select checkout features. Notice what's on neither list: a single WooCommerce store.

That's not a snub. It's structural. Agentic commerce launches where the catalog is already uniform — managed platforms, and big retailers with dedicated integration teams. The 4.3 million live WooCommerce stores (StoreLeads, May 2026) are the long tail, and the long tail is heterogeneous by construction.

The three answers that don't close the gap

"WooCommerce MCP already makes my store agent-ready." The MCP that shipped in 10.3 is a thin wrapper over your store's existing REST API — product and order operations, still in developer preview, with consumer shopping listed as a future step. It transports your data faithfully. It does nothing to reconcile your data with anyone else's. Readable, not comparable.

"schema.org normalizes it." schema.org can express variants, size, and color — Google added ProductGroup support back in 2024. But the values are free text, not a controlled vocabulary, so M, Taglia M, and 48 stay three different strings — and there's no shared category tree. It was built to earn rich results in search, not to make catalogs comparable across merchants. It reduces the chaos; it doesn't resolve it.

"The agent's model will just normalize on the fly." It can, per request — but normalizing millions of SKUs at query time is slow, costs money, and is non-deterministic: is 48 a EU clothing size, a shoe size, or a waist in centimeters? Comparison needs a stable key that means the same thing on every query, not a fresh guess each time. That's why the platforms are standardizing on structured feeds instead of leaning on inference at runtime.

What actually closes it

Not a prettier API. Not a richer feed. A normalization layer.

Something that maps each store's idiosyncratic vocabulary onto one shared, governed semantic frame — categories reconciled to a common tree, sizes and colors and attributes canonicalized, price normalized to a tax-explicit encoding — and does it once, as a durable decision, instead of re-guessing it on every query. It's the unglamorous part. It's also the part that decides whether a store is comparable or merely readable.

That's the layer I've been building underneath KaliCart: a federated catalog where heterogeneous WooCommerce stores resolve to a single comparable surface an agent can query and rank. The store stays itself. The agent sees one language.

The honest scope

This bites hardest for cross-merchant work — discovery, ranking, a cart that spans stores. A single store talking to a single agent feels it far less. And yes, schema.org and platform feeds shrink the problem at the edges.

But they don't make it disappear, because someone still has to map each heterogeneous store onto the shared frame. For Shopify, the platform does it. For millions of WooCommerce stores, no one does — unless a layer is built for exactly that.

The agentic web doesn't reward the prettiest storefront. It rewards the most impeccable source of truth. And impeccable doesn't mean exposed. It means normalized.

Giuseppe Socci — creator of KaliCart Bridge
bridge.kalicart.com · github.com/giuseppesocci-bot/kalicart-bridge · global.kalicart.com

"A reality was not given to us": the web that is coming does not exist yet — an agent will build it for you

Giuseppe Socci — Tue, 09 Jun 2026 16:00:19 +0000

Because a reality wasn't given to us and is not there; but we have to make it ourselves, if we want to be; and it will never be one for ever, but constant and infinitely changeable.

Luigi Pirandello, One, No One, and One Hundred Thousand
Pirandello wrote this about the human condition. He didn't know he was describing the future of the internet.

The web we know is about to disappear
Not slowly. Not gradually. The web page, as the default unit of human navigation, is about to disappear: it will strip itself of everything we call "interface" and what remains will be only what it always was underneath — data, structure, instruction.

The enticing homepages. The banners. The product carousels engineered by UX teams to capture attention in the first second and a half. The brand colors. The call-to-action buttons optimized for conversion rate. All of this is designed for a human eye that navigates alone.

That eye is about to delegate.

The agent that browses for you
Imagine you want to buy a pair of shoes. Today you open a browser, search, filter, compare, go back, reopen the tab you closed, forget what you were looking for, start again.

In a few years — maybe less — you will tell the agent what you want. The agent will already know that you have wide feet, that you prefer leather to synthetic, that you're looking for something for a wedding in June but deep down you want something that works afterward too. It will know that today you're in a practical mood, not an aspirational one. That you've spent a lot this month.

The agent won't open a homepage. It will query a data structure. It will receive prices, availability, variants, return policies. It will build for you — and only for you, and only in that moment — a presentation tailored to measure. Colors that belong to you. Texts that speak your language. Images generated for your aesthetic sensibility of that day.

The same store. Five billion different versions. One for each person, one for each moment.

One, No One, and One Hundred Thousand — applied to the web
Pirandello imagined a man who discovers he has as many faces as there are people looking at him. Vitangelo Moscarda is not one — he is one hundred thousand, one for every other person's gaze. And he goes mad trying to understand which one is real.

The agentic web resolves this paradox by reversing it.

It's not you who has one hundred thousand faces in the eyes of others. It is the world that will have one hundred thousand faces in your eyes. Every site, every store, every piece of content will be built by the agent in your image and likeness — not fixed and identity-bound, but temporary, seasonal, mood-dependent. Faithful to who you are in that precise instant.

Because a reality wasn't given to us and is not there.

There is no "true" web page. There is no "right" interface. There is only the construction — continuous, personal, unrepeatable.

What remains when the frontend disappears
If the agent builds the interface, what must the merchant provide?
Not design. Not copy. Not a mobile-optimized WordPress theme. They must provide instructions.

Instructions about what they sell. At what price. With what constraints. What values the brand holds. What is available right now, in this moment — not what was available yesterday when the crawler last updated the index. What it means to buy from them — the story, the guarantee, the meaning.

The merchant of the future doesn't manage a storefront. They manage a source of truth — structured, machine-readable, always current. The agent does the rest.

This future will not be served by prettier landing pages. It will be served by APIs, product feeds, schema.org metadata, MCP-compatible interfaces, real-time availability endpoints, signed policies, and machine-readable brand constraints. The stack already exists in pieces — what is missing is the layer that makes it coherent and discoverable.
This is the collapse of the frontend. HTML, CSS, JavaScript as presentation layers become optional. What remains is raw data — and raw data must be impeccable.

The vehicle remains the web. But a stripped web.
There is an obvious objection: the web won't disappear. True.

The protocol remains. HTTP remains. URLs remain. But what travels on that protocol changes its nature.

Today a web page is a document — designed to be read by a human eye, built with layers of presentation over layers of content over layers of structure. Tomorrow a web page is an interface for agents — an endpoint that responds to structured queries, returns normalized data, declares its own capabilities in a discovery document.

The graphics don't disappear — they are generated downstream, by the agent, for the human. But they don't live on the merchant's server. They live in the agent, constructed at the moment, on measure.

The devices through which all of this will arrive have probably not been perfected yet. Glasses. Ambient voice interfaces. Surfaces we don't yet know how to imagine. The agentic web doesn't need a screen — it needs a connection and a structure.

The paradox of discovery
There is a question that keeps coming back to me as I think about all of this.

If the agent filters the world according to who I am, how will I find what I don't know I want?

Discovery — the accidental encounter with a store you weren't looking for, the book that changed your life found by mistake, the brand whose existence you didn't know — has always been a function of the web's chaos. Of the search engine's imperfection. Of the banner that for once caught something true.

A perfectly aligned agent is also an agent that protects you from surprise. From dissonance. From chance.

This is the paradox of total personalization: the more the world is built for you, the less it truly belongs to you. Because it is you who builds it — or rather, it is your past history that builds it, not who you could become.

This is the problem no one has yet solved. Perhaps it is the most human problem of all.

…reality is not a thing conferred upon us or which exists; it is something that we have to manufacture ourselves."
Luigi Pirandello, One, No One, and One Hundred Thousand

Pirandello was talking about the human condition. He was describing the internet.

Giuseppe Socci — bridge.kalicart.com | github.com/giuseppesocci-bot/kalicart-bridge

Your WooCommerce store is invisible to AI shopping agents. Here's how to fix it.

Giuseppe Socci — Mon, 08 Jun 2026 18:34:36 +0000

AI shopping agents are already buying things on behalf of real users. ChatGPT Shopping has been live since September 2025. Google announced Universal Cart at I/O 2026 — a persistent cross-merchant cart spanning Search, Gemini, YouTube, and Gmail. The underlying standard is UCP (Universal Commerce Protocol).
None of this works with a standard WooCommerce store.

What AI agents actually do when they shop
When a user asks ChatGPT "find me a waterproof jacket under €150 in size M", the agent doesn't open a browser and scroll through your homepage. It queries structured data sources — product feeds, APIs, discovery endpoints. If your store doesn't have one, it doesn't exist.
The agent needs to answer machine questions:

What's the exact current price?
Is size M actually in stock right now, or is it backordered?
Does this product have variants? Which ones are available?
Is there a discount I can apply at checkout?
How do I initiate a purchase session?

A standard WooCommerce store can't answer any of these questions in a machine-readable way. The data is there — buried in the database — but there's no structured API surface for an agent to consume.
This is the gap. And it's about to matter a lot.

What's shipping right now
ChatGPT Shopping — live since September 2025, 900M weekly users. Queries structured product feeds. Non-Shopify merchants need an ACP-compliant product feed to appear.
Google AI Mode — replaces the classic search results page with a structured product panel. Reasons over the Shopping Graph to match intent, not just keywords. Feed completeness and live data are the ranking signals — not SEO.
Google Universal Cart — announced at I/O 2026. Cross-merchant persistent cart across Search, Gemini, YouTube, Gmail. Powered by UCP. Initial rollout to Shopify merchants and major US retailers.
WooCommerce MCP — shipped in WooCommerce 10.3 (Oct 2025), finalized in 10.7. Lets AI assistants interact with WooCommerce stores via Model Context Protocol. Current focus: store management (products, orders). Consumer shopping via MCP is the stated next step.
The pattern is clear: every major AI platform is building a commerce layer, and they're all pulling from structured data. The stores with complete, machine-readable catalogs get surfaced. The rest don't.

The WooCommerce problem
WooCommerce powers ~28% of global online stores. Almost none of it is natively readable by AI agents.
The WooCommerce REST API exists, but it's designed for store management — not for agent consumption. It requires authentication, returns data in a format agents don't expect, and has no discovery mechanism. An agent landing on a WooCommerce storefront has no standardized way to find the catalog, understand its structure, or initiate a purchase.
Shopify solved this with their managed agentic stack. WooCommerce, being open-source, is taking the composable path — which means the solution space is open for plugins.

What a machine-readable WooCommerce store looks like
I've been building KaliCart Bridge — a free WooCommerce plugin that exposes your live catalog as a normalized REST API for AI agents.
Here's what it adds to a standard WooCommerce store:
Discovery signals — A <link rel="kalicart-agent"> in the page <head>tells any agent where to start. /.well-known/kalicart-bridge and /.well-known/ucp provide standardized discovery files. robots.txt explicitly allows the catalog endpoints.
Structured catalog API —/wp-json/kalicart/v1/discovery is the entry point. From there, agents can search with real filters (category, gender, color, on_sale, in_stock, price range), get paginated product lists, fetch individual products with full variations, and navigate the category tree.
Normalized product data — every product exposes:

{
  "price": {
    "current": 89.00,
    "regular": 110.00,
    "on_sale": true,
    "discount_pct": 19.1,
    "encoding": "decimal_major_units",
    "display": "89,00 €",
    "vat_included": true
  },
  "stock": {
    "in_stock": true,
    "availability_status": "in_stock",
    "quantity": 14,
    "quantity_tracked": true,
    "backorder_allowed": false
  },
  "variants": [...],
  "barcodes": [{ "type": "EAN", "value": "1234567890123" }],
  "metadata": {
    "purchase_readiness": "direct_cart_possible",
    "stock_confidence": "numeric_stock_quantity"
  }
}

UCP compatibility — /.well-known/ucp declares dev.ucp.shopping.catalog.search and dev.ucp.shopping.catalog.lookup capabilities. Stock uses UCP-standard availability_status values. Price encoding is explicit (decimal_major_units) with a conversion hint for UCP minor units.
Checkout sessions — optional. Agents can create multi-product sessions returning cart_url and checkout_url. The human pays on WooCommerce. The merchant stays Merchant of Record.
No LLM. No cloud. No API key. Everything runs on your server.

The discovery flow
An agent that encounters a KaliCart Bridge store follows this path:

1. GET page HTML → finds
GET /wp-json/kalicart/v1/discovery → reads capabilities, filters, UCP profile, checkout policy
GET /wp-json/kalicart/v1/catalog/search?q=waterproof+jacket&in_stock=true&max_price=150
GET /wp-json/kalicart/v1/catalog/product/{id} → full variants for variable products
POST /wp-json/kalicart/v1/checkout/session → returns cart_url + checkout_url Five requests from zero knowledge to checkout-ready. No scraping, no guessing, no hallucinated prices.

Catalog health
The plugin also adds a health dashboard in WP Admin. Products are scored 0–100 based on data completeness. Deductions: NO_TITLE (−25), NO_DESCRIPTION (−30), NO_CATEGORY (−30), ZERO_PRICE (−25), NO_IMAGE (−8), NO_SKU (−4).
Products with blocking issues are quarantined — they don't appear in agent responses until fixed. The dashboard shows exactly what's wrong and links directly to filtered product lists for remediation.
This turns out to be useful even outside the agent context — most WooCommerce stores have a tail of products with incomplete data that nobody ever audits.

Where things are headed
The checkout layer (UCP + AP2) is still early — autonomous checkout at scale is probably 12–18 months away for the average merchant. But the discovery layer is live now.
Google AI Mode is already routing product searches away from classic results. ChatGPT Shopping is already surfacing products from structured feeds. The stores that are machine-readable today will have indexed history, agent familiarity, and structured data quality by the time autonomous checkout becomes mainstream.
The window to get ahead is now, not when it's obvious.

Try it

Plugin + docs: bridge.kalicart.com
GitHub: github.com/giuseppesocci-bot/kalicart-bridge
Live discovery endpoint: project2209.com/wp-json/kalicart/v1/discovery

DEV Community: Giuseppe Socci

The website chatbot was a workaround, not a solution

The pattern we all recognize

Why they're everywhere

How these things actually work

What the user actually wanted

From "AI on my site" to "my site readable by AI"

This isn't free

The takeaway

Turn Woo catalog into an AI-ready API — now on WordPress.org

Start with discovery, not endpoints

The endpoints

Query construction: the spine goes in q, attributes go in filters

A real search response

Evidence-required reasoning

REST or MCP — same data

Where checkout lives (and doesn't)

Try it

Your WooCommerce store is now readable by AI agents. It still isn't comparable — and that's the harder problem.

"A reality was not given to us": the web that is coming does not exist yet — an agent will build it for you

Your WooCommerce store is invisible to AI shopping agents. Here's how to fix it.

Query construction: the spine goes in `q`, attributes go in filters