An AI agent for an ecommerce website is a chatbot that can take actions as well as answer questions, and the line worth caring about runs between reading your shop and writing to it. Reading an order status is a plumbing problem with a clean security boundary. Writing, cancelling an order or issuing a refund, is a decision with a financial consequence and, in Europe, one that can attract extra obligations under GDPR Article 22 when it is fully automated.
Almost everything being renamed an agent this year is doing the first while being sold as the second. That is not a scandal, but it does mean the question to ask is narrow: which actions, exactly.
What makes something an agent rather than a chatbot?
The ability to do something other than reply. There is a ladder here, and products sit on different rungs while sharing the word.
| Rung | What it can do | Risk if it is wrong |
|---|---|---|
| Answer | Quote your published pages | A wrong answer, recoverable |
| Look up | Fetch this customer’s order or stock level | Showing the wrong person’s data |
| Prepare | Draft a return, check it against policy | Nothing, until a human confirms |
| Act | Cancel, refund, change an address | Money moves, and it is yours |
Most shops want rungs two and three and are being sold rung four. The gap matters because the engineering, the failure modes and the accountability are different at each level, and a product describing itself as an agent may be doing any of them.
The third rung is the one that gets skipped in product design and is usually the right answer commercially. An agent that assembles the case, checks the policy, and presents a confirm button to a person removes nearly all of the tedium and none of the judgement.
Which actions are safe to delegate?
Reading is broadly safe with sensible scoping. Writing needs a reason each time.
| Action | Read or write | Sensible default |
|---|---|---|
| Order status for the current customer | Read | Automate it |
| Stock for a specific variant | Read | Automate it |
| Start a return within policy | Prepare | Draft it, a person confirms |
| Issue a refund | Write | A person, always, at least at first |
| Change a delivery address | Write | A person, because fraud lives here |
The delivery address row is worth spelling out. Address changes are a classic social engineering target: a convincing message, an order intercepted, goods delivered elsewhere. A human handling that has instincts a policy check does not, and the volume is low enough that automating it buys you very little.
Reading is not risk-free either, and the risk is identity rather than authority. An agent that can fetch any order by number will happily fetch one belonging to somebody else if a visitor types a number that is not theirs. The question to ask a vendor is what the agent is scoped to, and the correct answer involves the session, not the message.
How does it actually reach your shop?
Through your store’s API, with your own code in the middle, and never by handing a model database access.
The pattern is the same everywhere. Function calling lets you describe a small set of operations to the model, look up this order, check stock for this variant, and the model requests one by name when a question needs it. Your code receives that request and decides whether to run it, for which customer, and what to return.
That indirection is the entire security model and it is worth understanding rather than trusting. The model never touches your data. It asks, in structured form, and your code is free to refuse. An agent cannot exceed the operations you exposed, which means the security review is a review of a short list rather than of a model’s behaviour.
One practical consequence worth planning for: every action is another round trip. A plain answer is retrieve then generate. An answer involving a lookup is retrieve, generate, call your shop, generate again, and the visitor is watching a cursor through all of it. Stream the reply and say what is happening, because a chat window that goes quiet for five seconds while an agent works reads as broken rather than as busy, and people close it before the answer arrives.
The plumbing underneath is ordinary. WooCommerce and Shopify both publish REST APIs that cover orders, products and stock, and on WordPress the REST API covers the rest of the site. None of this is exotic. It is a day or two of work plus a careful conversation about scoping.
How does it know who it is talking to?
This is the question underneath every other security question here, and it is answered badly more often than anything else on this page.
There are three levels and they are not interchangeable.
Anonymous. The visitor is a stranger. An agent at this level can answer public questions and nothing else, which is a perfectly good product and what most shops should run. Nothing about their order is reachable, so nothing about their order can leak.
Weak verification. The visitor supplies an order number and the email address on it, and the agent checks that the two match. This is the common pattern and it is reasonable, with two conditions. Rate limit it hard, because otherwise it is a guessing machine. And never confirm a near miss: replying that the email does not match this order tells an attacker the order exists, which is half of what they wanted.
Authenticated. The visitor is logged in and the agent inherits that session rather than asking for anything. This is the strongest arrangement by a distance, and it is available to more shops than use it, because a customer who is already logged in should never be asked to prove who they are again.
The failure to check for is an agent that accepts an order number on its own. Order numbers are very often sequential, which means a visitor who types a number one away from their own can be shown a stranger’s address. That is not an exotic attack. It is somebody bored, and it is a reportable data breach.
Two questions settle this with any vendor, and both are short. What identifies the customer before an order lookup runs. And what happens if a visitor types an order number that is not theirs. An answer of “the model handles it” means nobody has thought about it, and the model is the wrong place for that decision anyway: identity checks belong in your code, before the lookup runs, not in an instruction the model is asked to follow.
What goes wrong when an agent acts?
Four things, in roughly descending order of how often they happen.
It acts on the wrong record. A customer gives an order number from a different shop, or mistypes, and the agent confidently reports on something unrelated. The fix is scoping to the authenticated session rather than to whatever the visitor typed.
It acts twice. A network hiccup, a retry, and the refund goes out two times. Anything that writes needs to be safe to repeat, which means each action carries an identifier the shop recognises as already done. This is standard practice in payments and frequently missing from a chatbot integration bolted on later.
It acts on a stale read. It checked stock, the customer took ninety seconds, and the item sold. Availability at the moment of asking is not a reservation, and an agent that treats it as one promises something your shop cannot keep. The honest phrasing is the fix: telling somebody there are two left right now is true and useful, while telling them the item is available implies a hold that nothing is enforcing.
Nobody can tell what it did. The worst one, because it makes the other three unfixable. Every action needs a log line naming the conversation, the customer, the operation and the outcome. If a vendor cannot show you that log, the agent is unauditable and you are the one accountable for it.
When should it not be an agent?
Whenever answering is enough, which for most shops is most of the time.
If your top support question is delivery times or the returns policy, an agent adds nothing that a well-written page does not. The whole apparatus exists to reach data that is not publishable, and if your questions are answerable from published content you are buying complexity for its own sake. What to automate first is in what an AI chatbot for a website actually is.
If the actions are rare, keep the person. Automating something that happens four times a week costs more to build, test and audit than it saves, and it introduces a failure mode where there was not one.
And if nobody will own the audit log, do not switch the writing on. Actions without review accumulate errors invisibly, and the first review happens during a dispute, which is the worst possible moment to discover that the log does not record what you needed.
The sensible sequence is answer, then read, then prepare, then, if the volume genuinely justifies it, act. Most shops stop at read and are right to. How the interface should behave around any of this is in making a widget that fits your site, and what we let ours do is on how it works, with the compatibility list on works with.
Before you decide: common questions
What is an AI agent for an ecommerce website?
A chatbot that can take actions as well as answer questions. Instead of only quoting your returns policy it can look up the specific order, check whether it is inside the window, and start the return. The word covers a wide range in practice, from a bot that can perform one lookup to a system with authority to issue refunds, so it is worth asking exactly which actions are included.
What is the difference between a chatbot and an AI agent?
A chatbot reads and answers; an agent also acts. In practice the line that matters is between reading your shop and writing to it. Reading order status or stock is a plumbing problem with a clear security boundary. Writing, cancelling an order or issuing a refund, is a decision with consequences, and most products calling themselves agents are doing the first while being marketed as the second.
Can an AI agent process refunds automatically?
Technically yes, and it is worth being careful about. A refund is a financial action, and in Europe a solely automated decision about a person can attract extra obligations under GDPR Article 22. The arrangement most teams end up happy with is an agent that gathers the facts, checks the policy and drafts the action, with a person confirming it in one click.
How does an AI agent connect to my shop?
Through your store’s own API, with your code in the middle. You expose specific operations, look up this order, check stock for this variant, and describe them to the model, which can then request one by name. Your code decides whether to run it, for which customer, and what to return. The model never touches the database directly, and that indirection is the security boundary.
Is an AI agent safe to let near my orders?
For reading, yes, with the usual care about which customer’s data it can reach. For writing, it depends on scoping: an agent that can only act within a policy you defined, on the order the customer is already authenticated against, is a different risk from one with general access. Ask what the worst case action is and whether anything prevents it, rather than whether it is secure.
Do I need an agent or is a chatbot enough?
A chatbot is enough for most shops, because most support volume is questions whose answers are already published. Agents earn their place when your top question is order status, which no amount of good writing answers, and when the lookup is genuinely repetitive. Start with answering, measure what is left, and add actions to the specific gap rather than as a category upgrade.
