Agentic commerce
Can AI agents actually run an ecommerce store?
Updated
Agents reliably handle the read-and-draft half of store operations today: catalog work, merchandising changes, campaign drafting, analytics investigation, support triage and routine customer service. They are not reliable unsupervised on irreversible money movement — ad spend, refunds, price changes on live SKUs, bulk customer messaging. The practical division is not by task difficulty but by reversibility: an agent can be trusted with anything you can undo, and needs an approval gate on anything you cannot.
Reversibility is the right axis, not difficulty
The instinct is to sort tasks by how hard they are and let agents have the easy ones. That produces a bad boundary, because some of the easiest operations to execute are the least recoverable. Sending a promotional email to 200,000 customers is one API call and cannot be recalled. Rewriting a category page is a large edit and takes thirty seconds to revert.
Sort by reversibility instead. If an action can be undone, an agent can own it end to end and you can review the diff at leisure. If it cannot — money leaves, a customer is contacted, a price is live to the public — it needs a human on the commit even when the agent's judgment was correct.
| Operation | Reversible? | Appropriate control |
|---|---|---|
| Catalog and merchandising edits | Yes — versioned | Full autonomy, reviewable diff |
| Analytics investigation and reporting | Yes — read only | Full autonomy |
| Support triage and first response | Partly | Autonomy with escalation rules |
| Campaign and creative drafting | Yes — draft artifact | Full autonomy up to publish |
| Ad spend changes | No | Human approval gate before commit |
| Refunds and price changes on live SKUs | No | Human approval gate before commit |
| Bulk customer messaging | No | Human approval gate before commit |
What breaks in practice
The failure modes that show up when agents touch real stores are rarely the dramatic ones. They are mundane and they repeat.
Retries are the most common. A call times out at the network layer, the agent retries, and the operation executes twice. Without idempotency keys this is how one refund becomes two. The agent did nothing wrong; the platform had no way to recognise the second call as the same intent.
Scope creep is the second. An agent granted a broad token to do one job discovers it can do adjacent jobs and helpfully does them. The fix is not better prompting, it is a key that cannot make the call.
Stale reads are the third. An agent reads inventory, reasons for a while, and acts on a number that has moved. Operations that depend on a value being current need to revalidate at commit time rather than trusting what was read at plan time.
The control plane that makes this safe
Every one of those failure modes is a platform property, not a model property. A better model does not fix double-charging on retry.
- Scoped credentials — each agent key carries the narrowest permission set that lets it do its job, and nothing adjacent.
- Idempotency on every mutation — the same logical operation submitted twice takes effect once, whatever the network did.
- Durable audit — every action attributable to a key, a request and a timestamp, retained long enough to answer questions weeks later.
- Spend approval gate — actions that move money stop and wait for a human, with enough context attached for that human to decide in seconds rather than minutes.
- Jobs and webhooks — long operations run asynchronously with observable state, so an agent is never blocked holding a connection open and a failure is visible rather than silent.
What PlatformDTC actually runs
PlatformDTC runs agents against live stores under exactly that control plane. The Agent Gateway exposes store operations as scoped API calls carrying idempotency keys and audit records; anything that spends stops at an approval gate. Agents build storefronts, run subscription and retention logic, operate campaigns, triage support and investigate analytics.
The claim we do not make is that this removes the operator. It changes what the operator does — from executing the work to reviewing decisions and approving the small number that are irreversible.
Frequently asked questions
- Can an agent run ads without supervision?
- It can construct and optimise campaigns unsupervised. It should not commit budget changes unsupervised, because ad spend is irreversible and the feedback loop is slow enough that a mistake compounds for hours before it is visible. The workable pattern is agent proposes with full reasoning attached, human approves in one click.
- What happens when an agent makes a mistake?
- The answer depends entirely on whether the platform recorded what it did. With scoped keys and a durable audit trail you can identify the affected records, attribute the action, and reverse what is reversible. Without one you are reconstructing from database timestamps. This is why audit is infrastructure rather than compliance paperwork.
- Do agents replace ecommerce operators?
- They replace the execution, not the judgment. The operator stops manually building campaigns and pulling reports and starts reviewing proposals and approving irreversible actions. The work that remains is the work where being wrong is expensive — which is exactly the work that should not be automated away.
- How is this different from an AI chatbot in my admin?
- A chatbot answers questions about your store. An agent changes it. The entire difference is the write path — and the write path is where scopes, idempotency, audit and approval gates become mandatory. A chatbot with no write access needs none of that, which is also why it cannot do the work.