Before the Wallet, There Is the Catalog

In the first part of this series, the conclusion was simple: the wallet is the last thing we hand over.

People may ask AI agents to search, compare, summarize and recommend long before they let those agents spend money without approval. That does not make agentic commerce less important. It tells us where it starts.

It does not start at payment.

It starts at the catalog.

Before an agent can buy the right product, it has to understand what the product is. Before it can build a cart, it has to know which variant exists. Before it can recommend an alternative, it has to compare attributes, price, stock and constraints without guessing.

This is the quieter layer of agentic commerce. It is less dramatic than autonomous checkout, but it is the part most merchants need first.

The first mistake is starting from checkout

When people talk about agentic commerce, the conversation often jumps straight to the final scene: an AI agent buying something on behalf of a user.

That is understandable. Payment is visible. Checkout is measurable. A completed order is the cleanest proof that something happened.

But for most buyers, full purchase delegation is not the first use case. The first use case is assistance:

• “Find me a waterproof jacket under €120.”
• “Compare these two products.”
• “Is this available in size 42?”
• “Find the cheapest compatible replacement.”
• “Show me alternatives that can arrive before Friday.”
• “Build me a shortlist, but I will decide.”

None of these requires the agent to hold the wallet.

All of them require the agent to read the catalog correctly.

So the merchant’s first practical question is not:

Can an AI agent pay on my site?

It is:

Can an AI agent understand my products well enough to help a buyer choose?

That is a different problem.

A product page is not a computable catalog

A product page is designed for a human.

It mixes description, persuasion, images, layout, reviews, urgency, cross-sells and brand language into a single experience. That is exactly what it should do. A good product page helps a person feel confident enough to continue.

But an agent reads differently.

An agent needs stable answers to operational questions:

• What is the product called?
• What category does the merchant use for it?
• Which attributes are filterable?
• Which attributes are only selectable after the product is chosen?
• Is the displayed price the current catalog price?
• Is the product actually in stock?
• Is stock known exactly, or only as an availability status?
• Is this a simple product or a variable product?
• Which variants exist?
• Which variant is purchasable?
• Are coupons already reflected in price, or only applied later at checkout?
• Is shipping policy known, estimated, or destination-dependent?
• Where should the buyer be sent to review the cart or complete checkout?

A human can tolerate ambiguity because humans infer context.

Agents infer too, but that is exactly the danger. If the catalog does not say enough, the agent fills the gap. Sometimes it fills it correctly. Sometimes it invents certainty where the merchant only exposed a hint.

That is how trust breaks.

WooCommerce has APIs. But how does an agent find and use them?

WooCommerce is not a closed box. It already exposes data through APIs, and those APIs are useful.

The WooCommerce REST API is designed for integrations that need access to store resources using JSON over HTTP. It is powerful, mature and appropriate for many back-office, sync, ERP, PIM, reporting and custom integration use cases.

It is also an authenticated API. The official documentation describes generating REST API keys and using consumer key / consumer secret credentials for requests. That is the right model for trusted integrations.

WooCommerce also has the Store API, which provides public REST endpoints for customer-facing product, cart and checkout functionality. Unlike the classic REST API, the Store API is unauthenticated and does not expose sensitive store or customer data. It exists to support storefront experiences.

So the point is not that WooCommerce has no APIs. It does.

The point is that native APIs are not, by themselves, an agent-facing catalog.

A developer can read documentation, decide which API is appropriate, authenticate if needed, map fields, learn the store’s taxonomy, handle variants, decide how to treat stock, and build business-specific logic around the response.

An external shopping agent needs a different starting point.

It needs the store to say, in public and in machine-readable form:

• here is the catalog entry point;
• these are the catalog capabilities;
• these endpoints are safe to call without credentials;
• these are the accepted filters and values;
• this is how search queries should be constructed;
• this is the authoritative price field;
• this is how stock and variants should be interpreted;
• this is where the agent must stop and hand the buyer back to WooCommerce.

That is the missing layer.

An API tells a developer what can be requested.

An agent-readable catalog tells an agent how to discover the store, what it is allowed to do, and how to avoid guessing.

That difference matters.

A simple way to frame it:

What an agent needs is a contract

An agent does not only need product data. It needs rules around the data.

For example, if a buyer asks for “blue men’s sneakers under €100,” there are at least two ways to translate that request:

One way is to push the entire phrase into a text search field:

q=blue men sneakers under 100

Another way is to split intent into a bare product noun plus structured filters:

q=sneakers
color=blue
gender=male
max_price=100

Both are “API calls.” Only one is a reliable agent instruction.

That is the kind of contract agents need:

• where discovery starts;
• which endpoints are public;
• which filters are accepted;
• which values are valid;
• how search queries should be constructed;
• how variants should be inspected;
• which price field is authoritative;
• how to treat coupons;
• how to reason about stock;
• when checkout is possible;
• when human selection is still required.

Without that contract, the agent may still call an endpoint. It may even get a response. But the burden of interpretation moves from the merchant to the model.

That is where errors become likely.

Product truth is more than product data

The useful phrase here is product truth.

Product truth is not just a title and a price. It is the set of facts and constraints an agent needs in order to avoid misleading the buyer.

For an agent, a product is not ready just because it exists in WooCommerce. It becomes usable when the surrounding meaning is explicit:

• This is the current catalog price.
• This product is in stock, out of stock, or on backorder.
• This stock value is exact, approximate, variant-dependent or unknown.
• This product has variants, and a variant must be selected before checkout.
• This coupon is a possible checkout saving, not a replacement for the listed price.
• This shipping information is declarative, while final destination-specific cost is confirmed at WooCommerce checkout.
• This URL lets the buyer review the cart before paying.

That last distinction is important.

The goal is not to make the agent sound confident. The goal is to make the agent know where confidence ends.

A good catalog interface should tell an agent what it can safely say, what it must verify, and where the human must stay in the loop.

So what does Bridge actually do?

An agent-readable catalog layer does not replace WooCommerce.

It does not replace the product page.

It does not replace checkout.

It sits between WooCommerce and agents, exposing the live catalog in a form that is easier for software to discover, query and reason about.

This is the layer KaliCart Bridge is designed for.

Bridge is a WooCommerce plugin that exposes the merchant catalog through structured REST endpoints for discovery, categories, search, products, shipping policy, coupon hints and catalog health. Its documentation describes public endpoints under /wp-json/kalicart/v1/, including /discovery, /catalog/meta, /catalog/categories, /catalog/search, /catalog/products, /catalog/product/{id} and an optional /checkout/session.

The important design choice is not merely that these endpoints return JSON.

WooCommerce already returns JSON.

Bridge’s role is different: it turns WooCommerce from a system with APIs into a store with an explicit agent-readable surface.

That surface adds four things native APIs do not try to provide as a single public contract:

1. discovery — the agent can find where to start;
2. normalization — product data is shaped for catalog reasoning, including variants, stock, filters, shipping policy and coupon notes;
3. instructions — the agent is told how to search and interpret the catalog;
4. boundaries — the agent knows when WooCommerce checkout remains the authority.

For example, the Bridge documentation states that the q parameter should contain only the bare product noun, while attributes such as category, color, gender, price range and stock should be passed as structured filters. That prevents the agent from treating a natural-language sentence as an unstructured search blob.

The same documentation distinguishes catalog price from coupon savings, exposes stock confidence, marks variable products as requiring variant selection, and treats WooCommerce checkout as the final authority for destination-specific shipping and payment.

That is the practical shape of a computable catalog:

not “here is everything,” but “here is what this data means, and here is how to use it safely.”

The checkout handoff should stay boring

There is a temptation to make the agent do everything.

Search the catalog. Choose the product. Create the cart. Pay. Confirm. Done.

In time, some flows will work that way. But for many merchants and buyers, the better near-term pattern is simpler:

1. the agent discovers the catalog;
2. the agent searches and compares products;
3. the agent selects a candidate or builds a cart;
4. the buyer reviews;
5. WooCommerce remains the payment authority.

Bridge’s optional checkout session model follows that pattern. The agent can create a cart session and receive URLs that send the buyer to the merchant’s cart or checkout. The buyer completes payment on the storefront. The agent does not capture payment credentials, and the merchant does not have to give an external agent broad write access to the store.

That may sound less futuristic than fully autonomous payment.

Good.

At this stage, boring is a feature.

Trust is built by making the dangerous part smaller, clearer and more reversible.

Where UCP enters the picture

This does not make broader commerce protocols unnecessary.

The opposite is true.

The Universal Commerce Protocol describes a wider agentic commerce lifecycle, including catalog search and lookup, cart building, identity linking, checkout and order management. The public UCP GitHub repository describes capabilities such as Checkout, Identity Linking, Order and Payment Token Exchange, with discovery mechanisms that let platforms understand what a business supports.

That is a bigger layer than a WooCommerce catalog bridge.

And that is exactly why the distinction matters.

For a WooCommerce merchant, a computable catalog layer and a full commerce protocol should not be framed as enemies. They answer different questions:

• the catalog layer answers: “What products exist, what do they mean, and how can an agent safely reason about them?”
• the protocol layer answers: “What commerce capabilities can this business expose across identity, cart, checkout, payment and order flows?”

Catalog truth comes before commerce authority.

An agent cannot safely complete a checkout if it has already misunderstood the product.

A merchant checklist for agent-readable catalogs

A useful way to test readiness is to ask whether an external agent can answer these questions without scraping and without guessing:

• Where is the machine-readable catalog entry point?
• Which categories and filters are valid?
• Which product attributes are normalized?
• Which products are simple, and which require variant selection?
• Which variants are in stock?
• Is the price current?
• Are sale prices and coupon savings clearly separated?
• What shipping information is known before checkout?
• What still needs to be confirmed by WooCommerce checkout?
• Is there a safe cart or checkout handoff?
• Can the merchant revoke or disable agent-facing capabilities?

If the answer is “the agent can probably figure it out from the page,” the catalog is not really agent-readable yet.

If the answer is “the agent has a discovery document, accepted filters, normalized product payloads and explicit boundaries,” then the store is much closer.

The practical sequence

For most WooCommerce merchants, the path toward agentic commerce does not need to begin with a complete rebuild.

It can be staged:

1. expose the catalog in a structured, public, read-only form;
2. make discovery explicit;
3. normalize the product facts agents need most;
4. declare filters, variants, stock and price semantics;
5. provide a safe checkout handoff;
6. later, connect broader protocol capabilities where they make sense.

This is not a rejection of native WooCommerce APIs. It is a separation of responsibilities.

WooCommerce remains the system of record.

The storefront remains the human experience.

Checkout remains the payment authority.

The agent-readable catalog becomes the computational surface.

The first advantage is being understood

Agentic commerce will not arrive all at once.

Buyers will not hand over the wallet on day one. Many will not hand it over for a long time.

But they are already willing to delegate parts of discovery, comparison and choice. That means the first competitive advantage is not necessarily accepting autonomous payments.

It is being understood by the agents that help buyers decide.

The stores that prepare for that moment do not need to predict every future protocol, platform or assistant. They need to expose product truth in a way machines can compute and humans can still control.

Before the wallet, there is the catalog.