What WooCommerce released
On 16 September 2026, WooCommerce Engineering published its own adaptation of Anthropic’s Claude commerce-agent blueprint in the WooCommerce Agentic Tools repository. The project demonstrates both a customer-facing shopping assistant and a merchant assistant connected to a WooCommerce store.
WooCommerce is explicit that the code is for experimentation and growth and is not maintained as an official supported extension. That distinction matters. It is a technical reference that shows how the pieces can fit together; a production store still needs security review, infrastructure, observability, data controls and a deliberate deployment model.
How the shopper agent works
The shopper-side implementation can search the catalog, compare products, plan multi-item purchases, build a cart, answer policy questions and support order-related conversations. The conversational storefront runs separately from the normal WooCommerce theme and hands the customer back to the store for checkout.
A bridge plugin handles the cart transition. The assistant has a Store API cart token, while the shopper's browser has its own WooCommerce session. When the shopper proceeds to checkout, the bridge adds the selected items into the shopper's normal cart with WooCommerce stock checks and then redirects into the standard checkout flow.
This is a sensible trust boundary: the agent can help the shopper decide and prepare a basket, while WooCommerce remains responsible for the actual checkout, inventory validation, payment and order creation.
How the merchant agent works
The merchant side is designed for store operators. It can answer questions about sales, stock and problem orders, then prepare proposed changes such as price moves, restocks, listing copy or scheduled sales.
Crucially, WooCommerce's reference stages those changes for approval. The agent can reason and draft, but a person remains in the loop before consequential changes go live. That pattern is well suited to smaller stores where one operator may be managing catalog, merchandising and day-to-day ecommerce decisions.
For larger stores, BAGAI would treat the merchant agent as one layer inside a wider permissions and workflow model rather than granting a single assistant broad write access.
Important architecture details
The WooCommerce reference is more than a chat interface. It includes a self-hosted Python service beside WordPress, separate web applications for shopper and merchant experiences, and the bridge required to move a conversational cart into the shopper's WooCommerce checkout session.
WooCommerce notes that the reference uses Python 3.11+, Node 22 and Next.js, and recommends testing against a staging copy before pointing the agent at a real store. It also notes that product retrieval begins with keyword search and lets the model reason over the returned products. That creates a practical limitation: if keyword retrieval never returns the right product, the model cannot rescue the result by semantic reasoning alone.
For large or unusual catalogs, retrieval quality should therefore be treated as a first-class part of the project. Options include better searchable product attributes, improved indexing, structured filters, embeddings or hybrid retrieval—tested against real shopper language.
What a production WooCommerce build still needs
1. Security and permissions
Use least-privilege credentials, separate customer and merchant permissions, protect secrets outside the public web root and log all write attempts. Admin actions should be scoped to the specific tools the workflow needs.
2. Catalog grounding
Every price, variant, stock state and product identifier should come from WooCommerce or another trusted catalog system. The model should explain and compare; it should not manufacture commercial facts.
3. Checkout and attribution
Preserve the ordinary WooCommerce checkout and track whether the shopper arrived from the agent. That creates a clean measurement chain from agent interaction to cart, checkout and order revenue.
4. Human approval
Keep proposed catalog and promotion changes staged until the business has enough evidence to automate a narrow subset safely.
5. Evals and failure review
Build test cases for unavailable products, conflicting variants, policy exceptions, malicious prompts, ambiguous product requests and stale inventory. Conversation logs alone are not a sufficient quality system.
Who should assess the WooCommerce reference
It is particularly relevant to developers, agencies and merchants that already have a WooCommerce store and want to experiment with conversational product discovery or internal merchant workflows without replacing WordPress/WooCommerce as the system of record.
A practical BAGAI pilot would usually start with one bounded flow—for example product discovery plus cart handoff, or read-only merchant analytics—before introducing catalog writes or customer-account actions.
Primary sources
- WooCommerce Engineering: Running the Claude Commerce Agent on WooCommerce
- Anthropic: Claude for commerce
- Claude Platform Docs: Commerce agent guide
The WooCommerce implementation described here is experimental reference code, not a BAGAI product or a supported WooCommerce extension.