Most conversations about agents in operations start in the wrong place. They start with capability: what can it do, how accurate is it, which vendor demos best. Capability is the easy half, and it improves every quarter without you doing anything.
The hard half is delegation. Which decisions are you willing to let software make without asking you first, and what happens the first time it is wrong at two in the morning with nobody watching?
That question has a structure, and it has very little to do with how clever the model is.
Start with what the benchmarks actually say
It is worth anchoring expectations before designing anything.
Published benchmark work puts the best single agents at roughly 61.7 percent task completion on WebArena, against about 78 percent for humans, with substantially lower figures on longer and more adversarial suites. Known failure modes are mundane rather than exotic: dynamic page elements break reading, interstitials and challenges stop flows, and long-horizon tasks lose the thread.
Read that honestly and it tells you two things. Agents are genuinely useful. And an agent left unsupervised on a task where failure is expensive will, eventually and reliably, fail in a way no one noticed in testing.
So the design problem is not "is it good enough". It is "what happens when it is wrong, and how quickly do we find out".
The three questions that decide delegation
For any operational task, ask these in order. They matter more than accuracy.
Is it reversible? If the agent is wrong, can you undo it in minutes without anyone outside the company noticing? Re-tagging an order is reversible. A refund is reversible but visible. A message to a customer is not reversible at all - you can apologise, but you cannot unsend.
What is the blast radius? Does a mistake affect one order, or every order placed after 6pm? Per-record tasks are safe to delegate early. Anything that writes a rule, changes a price, or updates many records at once is a different category, because a single wrong decision multiplies before anyone opens a dashboard.
Is it auditable? After the fact, can you see what the agent did and why, in a form a person can review quickly? If you cannot reconstruct the decision, you cannot debug it, and you certainly cannot defend it to a customer or an auditor.
A task that is reversible, narrow and auditable can be delegated early even if accuracy is unremarkable. A task that is irreversible, broad or opaque should stay supervised even if accuracy looks excellent, because the cost of the rare failure dominates the average case.
The delegation ladder
Three rungs, and tasks move up them with evidence rather than with enthusiasm.
In the loop - the agent proposes, a person commits. Nothing reaches a customer or a system without a human decision. The agent does the gathering, the drafting and the routing, which is where most of the time goes anyway. Start every new task here.
On the loop - the agent acts, a person samples afterwards. The agent completes the work and a human reviews a share of it, daily or weekly, looking for drift rather than checking every case. This is where most mature ecommerce automation should live.
Out of the loop - the agent acts, monitoring is the only check. Appropriate for high-frequency, low-stakes, highly reversible work with good alerting. Large retailers do run replenishment agents at this level across thousands of stores, but they got there with years of data and an alerting apparatus most brands do not have.
The promotion rule is the useful part: when an agent's error rate on a specific action falls below roughly five percent, that action can move up a rung. Per action, not per agent. The same system can be trusted to classify tickets and not trusted to issue refunds, and that asymmetry is a feature.
Applied to ecommerce operations
Delegate early, in the loop then on the loop: ticket classification and routing; drafting replies for a human to send; flagging address anomalies before dispatch; detecting a stock mismatch between two systems and reporting it; chasing courier exceptions and compiling what happened; assembling the daily operations summary; first-pass reconciliation of marketplace settlements against orders.
What these share: frequent, judgment-light, recoverable, and with an obvious correct answer most of the time.
Keep supervised for a long time: issuing refunds above a threshold; cancelling or re-routing an order after dispatch; changing prices or discounts; messaging an already-unhappy customer; deciding whether a return is accepted outside policy; anything that writes to a vendor or payment system.
What these share: either irreversible, or trust-damaging, or wide in blast radius.
Keep human, as policy rather than as a stage: goodwill decisions, escalated complaints, anything with compliance exposure, and the judgment call about whether a customer relationship is worth saving. These are not waiting for better models. They are choices about who carries the consequence.
The architectural question of whether a given task even needs an agent, rather than a deterministic rule, is a separate decision and usually resolves towards rules - we work through it in AI agent vs workflow automation. The prioritisation question of which process to start with is in what should you automate first. This piece assumes both are answered and asks only how much rope to give the thing once it exists.
The approval step that is worth paying for
A human checkpoint earns its cost only if it changes outcomes.
If your reviewer approves ninety-nine of a hundred agent drafts without edits, you have not built a safety mechanism, you have built a delay with a salary attached. Either the task is ready to move up a rung, or the review is being performed without attention - and both of those are worth knowing.
So instrument the checkpoint. Track how often the human changes what the agent produced, and what they changed. That number is the single best signal in the whole system: it tells you when to promote a task, and it tells you which failure patterns to fix. A review process that produces no data is just friction.
The failure mode to design for
The failure people plan for is a wrong answer. The one that actually causes damage is a confident loop.
An agent that cannot complete a task does not usually stop and say so. It retries, rephrases, picks a different path, and keeps going - which on a read-only task is harmless and on a write-capable task means the same action attempted six times. The published failure patterns are consistent on this: dynamic elements, interstitials and long-horizon tasks are where agents lose the thread, and losing the thread looks like persistence rather than like an error.
So build three things into any agent that touches a real system. A hard attempt limit per task, after which it stops and escalates rather than trying harder. Idempotency on every write, so the same action twice has the same effect as once. And a log a human can read in under a minute - what it was asked, what it decided, what it changed, what it saw.
That last one is the cheapest and the most often skipped. An agent without a readable trail cannot be debugged, cannot be promoted up the ladder with any confidence, and cannot be defended when a customer asks why something happened to their order.
What has to be true first
An agent is a very fast way to act on your data. If the data is quietly wrong, you have built a very fast way to be wrong.
This is why the order matters. Order state that two systems disagree about, stock figures accurate to the high eighties, revenue definitions nobody wrote down - put an agent on top of those and it will make confident decisions on bad inputs, at a rate no human would. The audit worth running first is in why your ecommerce numbers never match.
The brands that get value from operational agents in 2026 are not the ones with the best model access. They are the ones whose order state is trustworthy, whose exceptions are defined rather than improvised, and who decided in advance which decisions a machine is allowed to make alone.
Where to start this month
Pick one task that is frequent, reversible and currently done by a person who is overqualified for it. Run it in the loop for four weeks. Measure how often the human changes the output. If that number falls below roughly one in twenty, move it up a rung and pick the next task.
That is the whole programme. It is slower than a vendor roadmap and considerably faster than the alternative, which is an ambitious autonomous deployment that gets switched off after its first visible mistake and sets the conversation back a year.
If you want the delegation ladder mapped against your own operation - which tasks are safe to move now, which should stay supervised, and what the approval step should measure - book an architecture review. We come back with the task list by rung, the promotion thresholds, and the ones we would tell you to leave with people.
