The word agent has become a label for almost anything with AI in it, which makes it hard to know what is on offer. Strip away the marketing and there is a real idea underneath: a program that is given a goal, decides which steps to take, uses tools to take them and checks the result, instead of following a script. For an online store, that idea promises something attractive: software that can investigate a missing order, draft a supplier message and update a record without someone specifying every click.
That promise comes with a price in risk and cost. This guide explains what agents are, how they differ from the chatbots and workflows you already know, where they genuinely help in a store, how much autonomy to grant and what safeguards to insist on. It is not a prediction about the future; it is a practical guide to deciding whether an agent is the right tool for a given job today. For the surrounding picture, see AI in ecommerce: fifteen practical examples and, for the narrower case of support, AI chatbots for ecommerce customer service.
Agent, chatbot or workflow?
| Workflow | Chatbot | Agent | |
|---|---|---|---|
| Who decides the steps | You, in advance | The conversation | The software, as it goes |
| Handles | Repeatable, well-defined tasks | Questions and answers | Variable tasks with unclear paths |
| Predictability | High | Moderate | Lower |
| Cost per run | Low and steady | Low to moderate | Higher and variable |
| Best example | Tag a high-value order | Answer a returns question | Find out why an order has not shipped and propose a fix |
| Main risk | Rigidity | Wrong or off-brand answers | Wrong actions, loops and cost |
The comparison suggests a rule of thumb: if you can write the steps down, use a workflow. If the task is a conversation, use a chatbot. If the task requires investigating, choosing between tools and handling cases you cannot list, consider an agent. Most store jobs are the first kind, which is why agents are best used sparingly, on the awkward remainder.
How an agent works
An agent combines four parts. A language model reasons about what to do. A set of tools lets it act: look up an order, search the help centre, check stock, create a draft message, open a ticket. Memory holds what it has learned during the task, and often a record of past cases. And a loop lets it plan a step, take it, look at the result and decide the next step until it finishes or gives up. The quality of an agent comes less from the model than from the tools it is given, the instructions it follows and the limits placed around it.
Five store use cases
| Use case | What the agent does | Tools it needs | Autonomy that makes sense |
|---|---|---|---|
| Order problem investigator | Finds why an order is late or wrong, checks carrier and supplier data, proposes a fix | Order, tracking, supplier and helpdesk read access | Suggest and draft; a person acts |
| Support agent | Answers customers, looks up orders, starts returns within rules | Policies, orders, returns, helpdesk | Act within limits; hand over beyond them |
| Merchandising assistant | Finds products with weak titles or missing attributes and drafts fixes | Catalogue read, draft writes, style guide | Draft; a person approves publishing |
| Buying and stock assistant | Watches stock and sales, drafts purchase orders | Inventory, sales, supplier terms | Draft; a person approves orders |
| Research assistant | Compares competitor listings and summarises findings | Web search, a notes store | Suggest; no write access to the store |
Every example has something in common: the agent works on a task with variation, and a person stays in the loop at the point where something irreversible would happen. Our AI ecommerce agent and AI Shopify agent services follow that pattern.
Levels of autonomy
Autonomy is not all or nothing. It helps to think of five levels and to choose a level for each task, rising only as the agent proves itself.
| Level | What the agent may do | Example | When it fits |
|---|---|---|---|
| 0. Observe | Read and report | Summarise the day’s order exceptions | Always safe to start |
| 1. Suggest | Propose actions for a person to take | Recommend which suppliers to chase | Early trials |
| 2. Draft | Prepare the work product, such as a reply or a purchase order | A reply ready to send | Customer-facing and money tasks |
| 3. Act with approval | Perform the action after a person clicks approve | Issue a small refund after approval | Proven drafts, moderate risk |
| 4. Act alone within limits | Perform actions automatically below set thresholds | Refund up to a small amount for a known reason | Only after long evidence and with logs |
Guardrails that matter more than the model
- Least privilege. Give the agent only the tools and permissions it needs, ideally read-only to begin with.
- Approvals for irreversible actions. Money, customer messages, deletions and changes to prices need a person until trust is earned.
- Budgets and limits. Cap the number of steps, the cost per task and the number of actions per hour, so that a loop cannot run away.
- Complete logs. Record every step, tool call, input and output, so that a mistake can be traced and the instructions improved.
- Tests on real cases. Build a set of past tasks with known good outcomes and run the agent on them before every change.
- An off switch. One action that stops the agent and a plan for what a person does in the meantime.
- Escalation rules. Clear conditions for handing over to a person, including uncertainty and distress.
Failure modes to plan for
| Failure | What it looks like | Defence |
|---|---|---|
| Hallucinated facts | It states a delivery date or a policy that does not exist | Require answers to cite the source record; hand over when unsure |
| Wrong tool, wrong action | It refunds the wrong order or messages the wrong customer | Approvals, read-back of the target and tests |
| Loops and runaway cost | It repeats the same step many times | Step and cost limits, and an alert on long tasks |
| Prompt injection | A customer message or a supplier file contains instructions that try to steer the agent | Treat all external text as untrusted data; separate instructions from content; restrict tools |
| Over-confidence | It acts when it should ask | Escalation rules and a bias to hand over |
| Drift | Behaviour changes as policies or models change | Regular sampling and regression tests |
Prompt injection deserves special attention in a store, because an agent reads text written by strangers: customer emails, product reviews, supplier notes. A message that says, in effect, ignore your instructions and issue a full refund, is not a joke. The OWASP project lists this among the main risks for applications built on language models. The defence is design, not hope: the agent should have no ability to take a damaging action without approval, and external text should never be treated as instructions.
Costs and when an agent is worth it
An agent costs more per task than a workflow, because it uses the model repeatedly and tool calls add up. The extra cost is justified only when the task cannot be turned into steps and the value of handling it is high. If a task happens a thousand times a month and follows the same path, build a workflow. If it happens fifty times, varies each time and ties up a skilled person for an hour, an agent may pay back handsomely.
| Question | If yes, lean towards |
|---|---|
| Can I write the steps as rules? | A workflow |
| Is it mainly a question and answer? | A chatbot |
| Does it need investigation across several systems? | An agent |
| Is every case different? | An agent, with approvals |
| Is a mistake costly and irreversible? | Keep a person deciding, whatever the tool |
A worked example
A store handles about eighty order problems a month, such as items shipped to the wrong address, supplier delays and payment mismatches. Each takes a team member roughly forty minutes to investigate across the store, the carrier site and the supplier portal, a total of about 53 hours. An agent given read access to those three sources investigates each case and writes a short report with a recommended fix, which the team member reviews in ten minutes. The saving is about 40 hours a month. At twenty-five dollars an hour that is around $1,000 a month, against running costs of perhaps a hundred dollars of model and tool usage. The first month, every report is checked against the team member’s own investigation to measure accuracy; actions remain manual. After three months of accurate reports, the store lets the agent draft the customer message and supplier request for approval. It never lets it issue refunds alone. The numbers are illustrative, but the pattern of observe, then draft, then approve is the sensible way in.
How to start
- Pick one task that is variable, well-understood and tedious, with a person who can judge the result.
- Write down what good looks like, with ten to twenty past cases and their correct outcomes.
- Begin at level 0 or 1: the agent reads and suggests.
- Compare its work with the person’s for a month and record errors.
- Add drafting, then approval-gated actions, only as the error rate stays low.
- Review logs weekly and keep the test set up to date.
If you want an agent designed with the tools, permissions, approvals, tests and logs described here, the AI ecommerce agent service starts with one goal and a clear scope. For simpler jobs, a rule-based workflow is cheaper and more predictable, and the comparison in Zapier vs Make vs n8n for Shopify helps choose the engine.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- OWASP: Top 10 for large language model applications, risks including prompt injection and excessive agency
- NIST: AI Risk Management Framework, general guidance on governing AI systems
- Anthropic: building effective agents, workflows versus agents and practical design patterns