Agentic Commerce: Where Should the Agent Actually Act?
Capability stopped being the constraint. The question worth answering is what happens when the agent is wrong.
Most conversations about commerce agents start by asking what the model can do. That was a useful question in 2023. It is not the binding constraint now.
The question that decides an actual deployment is narrower and less exciting: when this action is wrong, who notices, how fast, and what does undoing it cost? Ask that first and the work sorts itself into a spectrum rather than a yes or no.
Two properties do the sorting
Reversibility. Can the action be undone by the same system that took it, with nobody’s approval and no side effects? Sending a message again is reversible in practice. A captured payment is not. Refunding it is a second event with its own accounting, its own fees and its own trail.
Consequence. What does a wrong action cost the shopper? A restock alert fired at the wrong person is noise. An order cancelled at the wrong moment is a lost customer, a support call and, if it happens twice, a review.
Score an action on both and you have your answer. Reversible and low-stakes: let the agent complete it. Irreversible or financially consequential: the agent prepares the action and a person confirms.
Good agent territory
The tasks that pass both tests tend to be the dull, high-volume ones, which is exactly why automating them pays.
Order-status lookup is the clearest case. The agent reads a record and reports it. Nothing changes state, and a wrong answer is corrected by asking again.
Starting a return inside the published policy window is nearly as safe. It creates a request, not a refund. If the request should not have been raised, cancelling it costs a click.
A restock alert commits nobody to anything. So does a cart-recovery message, provided it respects your contact rules and frequency caps.
What these share is that being wrong is recoverable and cheap. That is the whole qualification.
Where a human confirms
Completing a payment. Changing a live price. Cancelling an order. Issuing a refund above a threshold you set. Editing stock. Touching stored payment details.
Each of these fails the reversibility test, the consequence test, or both. So the agent does the preparation, which is most of the labour anyway: gather the context, check the preconditions, draft the exact change, and present it for approval.
One clarification worth making, because it is where teams over-correct. A human confirmation step is not necessarily a colleague and a two-day queue. Often the confirming human is the shopper, clicking a button on a checkout the agent assembled for them. The requirement is that a person authorises the consequential act, not that an employee does.
The middle band is where thresholds belong
Some actions genuinely sit between the two ends, and pretending otherwise produces bad rules. Changing a delivery address is reversible right up until dispatch. Refunds are trivial at five pounds and serious at five hundred. Cancelling an order is a different act on a made-to-order item than on stock.
Write those as numbers and states you can change, not as judgement calls left to the model. “Refunds under a stated amount complete automatically, above it go to approval” is a rule you can tune next quarter. “Use discretion” is not a rule at all.
Six questions before an action goes live
- Can the agent undo this itself? If not, name who confirms it, and whether that person is your team or the customer.
- What preconditions must hold? Order not dispatched, item inside the returns window, shopper authenticated as the account holder. The agent checks these, rather than inferring them from the conversation.
- What is the worst case if it repeats? Every action needs a rate limit and a scope. An agent stuck in a loop should exhaust a small budget, not your stock file.
- Can the log reconstruct it? Inputs, decision, outcome and who or what authorised it. A disputed interaction should be readable, not argued about from memory.
- What happens when it cannot complete? Define the refusal and the handoff before you define the happy path. An agent with no exit invents one.
- Who reviews what it did? A weekly look at actions taken, refusals given and confirmations rejected will tell you within a month whether a boundary is drawn in the right place.
That last one matters most, because the line moves. Confirmations your team approves every single time are candidates for automation. Automated actions that keep getting reversed were on the wrong side of it.
The agents we build, and the assistant they sit behind, are described on the Generative Commerce page. The grounding work underneath them is covered in what “grounded” actually means for a shopping assistant. To talk through where your own line should sit, email office@mlart.biz.