Every store owner we talk to is already using AI to run their store. Usually it looks like this: copy a product description, paste it into ChatGPT, ask for a better one, paste it back. It works. It's also the least that's possible now.
The real question in 2026 isn't whether to use AI on your store — it's which of five very different setups fits you. They range from "free and blind" to "knows your store and can change it," and the differences come down to three questions worth asking about any of them:
- What can it see? Your live products, orders, and stock — or only what you paste in?
- What can it change? Nothing, drafts, or real prices on a live site?
- What stops it from breaking something? You, an approval step, or nothing at all?
1. The browser tab
ChatGPT or Claude in one tab, your store in another. No setup, no risk, and for pure writing work — descriptions, category copy, email drafts, translating policies into plain language — still unbeatable for the price.
Two habits make it materially better. First, keep a saved prompt that describes your brand voice, your audience, and two examples of copy you like; paste it at the top of every session instead of re-explaining yourself. Second, feed it exports rather than screenshots: WooCommerce's product CSV export drops onto the chat and suddenly "which of these 400 titles are weakest?" is answerable in one message.
The ceiling is visibility. The model knows nothing you didn't paste, so it will confidently discuss products you discontinued last year, and every answer ends with you doing the clicking. You are the API. That's fine at ten products and absurd at a thousand.
See: only what you paste · Change: nothing · Guardrail: you, on every keystroke
2. Wire it up with MCP
The power-user route, and the one that got real in the last two years. MCP (Model Context Protocol) lets a model like Claude or ChatGPT talk to your store directly — through a WooCommerce MCP bridge or WordPress's own AI tooling — authenticated with a WooCommerce REST API key. Ask "which products had no sales in 90 days?" and it queries the actual store instead of guessing. Ask it to update a price and, if you gave it a write-scoped key, it will.
That last sentence is the whole trade-off. WooCommerce API keys come in Read, Write, and Read/Write, and the single most important decision in this setup is which one you hand over. Our advice, without hedging: run read-only for the first month. A read-only key already covers most of the value — analysis, audits, finding problems — with a blast radius of zero.
When you do grant write access: scope it, test the workflow on a staging site first, and treat the AI like a new employee with admin access, because that is literally what it is. The failure mode isn't malice; it's a confidently wrong bulk edit at 11pm.
Best for: technical owners and agencies who want raw control and are willing to own the safety themselves.
See: everything the API exposes · Change: whatever the key allows · Guardrail: whichever you build
3. The AI already in your editor
WordPress and WooCommerce keep absorbing AI into the editor itself — product description generation, rewrite suggestions, image alt text, that class of assist. If it's in your install already, it costs nothing to try and can't touch anything beyond the field you're editing.
The honest assessment: these are writing aids, not management. They don't know your sales data, can't look across products, and won't answer a question. But "generate a first draft of this description while I'm standing in the product editor anyway" removes real friction, and the guardrail is the best there is — nothing happens outside the box you're typing in.
See: the field you're editing · Change: drafts you accept · Guardrail: total
4. The plugin aisle
Search "AI" in the plugin directory and you'll find hundreds of options — chatbots, content generators, "AI for WooCommerce" bundles of every description. Some are excellent. The category is uneven enough that the useful skill is vetting, not choosing a brand. Four questions before installing any of them:
- Where does your data go? Product data flowing to a third-party model API is usually fine; customer data needs a harder look at the privacy policy.
- Whose API key pays for it? Many plugins are thin wrappers where you supply your own OpenAI key — which can be cost-effective, but means the plugin's quality is its prompts.
- When was it last updated? The AI layer moves fast; a wrapper that hasn't shipped in a year is wrapping last year's models.
- What can it write to? The same read/write question as MCP, asked of a black box. If the answer isn't documented, assume the worst.
See: varies · Change: varies · Guardrail: varies — which is exactly the problem
5. An embedded store agent
The newest category, and — full disclosure — the one we build, so weigh this section accordingly.
An embedded agent lives inside your store's dashboard, already looking at your real products, orders, and analytics. You ask it things ("what got views but no sales last month?") and tell it things ("raise these three prices by 10%"), and it does the looking and the doing. No prompt engineering, no integration code.
Setup is real but small: you install a plugin and paste in a WooCommerce REST API key, the same key from option 2. What you skip is the plumbing around it, not the key itself.
Here's where we have to contradict our own advice, so it's worth being direct about it. We told you above to start read-only. Our own product won't let you: it requires a Read/Write key and rejects a read-only one during setup, because an agent that can only look can't do the half of the job people buy it for.
So the guardrail has to sit somewhere else, and the design question from the top of this post becomes the whole product question: what stops it from breaking something? Our answer is propose, then approve — every write tool creates a proposal rather than a change, and nothing reaches your store until you confirm it in the dashboard. That's a real mechanism rather than a promise, but it is the only thing standing between the agent and a live store, which is a fair thing to weigh before you hand any vendor that key.
The awkward cases are where this gets tested. Variable products, for instance: "set stock to 40" is ambiguous, because stock can be tracked on the parent or on each variation depending on how the product is configured. Guess wrong and you either do nothing or misstate availability across every size and colour. Our agent asks which variations you mean instead of picking one. An agent with write access accumulates exactly these scars, and an agent without them hasn't been used much.
Where this option loses: it's a subscription, it's less infinitely flexible than a raw model with an open prompt, and you're trusting a vendor's guardrails instead of building your own. If you enjoy owning the plumbing, option 2 is more yours.
See: your live store · Change: what you approve · Guardrail: built in — and worth interrogating before you buy, ours included
Side by side
| Sees your store | Can change it | Setup | Guardrails | Best for | |
|---|---|---|---|---|---|
| Browser tab | What you paste | Nothing | None | You | Writing, one-offs |
| MCP connection | Full API | Full API (key-dependent) | An afternoon, technical | Whatever you build | Technical owners, agencies |
| Editor AI | Current field | Drafts only | None | Total | Quick copy assists |
| AI plugins | Varies | Varies | Install + vet | Varies | Depends entirely on the plugin |
| Embedded agent | Live products, orders, analytics | Approved changes | Plugin + API key | Propose-then-approve | Store-aware help without plumbing |
Whatever you pick, start read-only
The advice that survives every option on this list:
Give AI eyes before you give it hands. Analysis, audits, and finding problems is where the value starts, and a read-only month teaches you exactly how much to trust the tool before its mistakes can cost anything.
Keep a human between AI and prices. Copy can be wrong and embarrassing. Prices and stock can be wrong and expensive. Whatever the mechanism — an approval step, a staging site, a proposal queue — don't let those two change without a person in the loop.
Judge tools by their worst edit, not their best demo. Every option here demos beautifully. The differences show up on the awkward cases — variable products, half-configured shipping zones, the category with 4,000 SKUs — and on what happens when the model is confidently wrong.
And if you're wondering whether any of this matters for a store your size: two in five shopper messages arrive after closing time. The store runs whether you're at the desk or not. The question is only how much help you have.
oomates builds an embedded store agent for WooCommerce — option five — which is how we know where each of these approaches shines and where it hurts.