What agentic delivery changes in e-commerce and retail

After several industries where the answer is “carefully, and start away from the core,” retail is a relief. There is no regulator approving your changes, most failures are recoverable, and the estate is largely modern software that your own teams wrote.

So the useful question is not what holds you back. It is why, given all that freedom, retail engineering organisations so often find that a large throughput increase produces a disappointing revenue effect. The answer has to do with three constraints that are not about safety at all.

The freeze is a hard boundary, and it is longer than the calendar says

Every retailer has a period where change stops. The exact window varies but the pattern does not: several weeks around the peak trading season during which only critical fixes ship.

The naive reading is that this costs you a few weeks. The real cost is larger in both directions. Ahead of the freeze there is a rush to land work before the gate closes, which is the worst possible time to be merging aggressively. Behind it there is a backlog that lands together, which is the second worst.

Agentic delivery interacts badly with this by default. Higher production throughput against a fixed freeze produces a bigger pre-freeze rush and a bigger post-freeze batch, and batch size is one of the most reliable predictors of failure there is.

Throughput without freeze planning

• Larger pre-freeze rush into the riskiest window
• Backlog accumulates behind the gate
• Post-freeze batch lands together
• Batch size predicts failure, and it rose

Throughput with freeze planning

• Capability work moved forward, not compressed
• Flags let code ship dark before the gate
• Post-freeze release staged deliberately
• The freeze constrains exposure, not merging

The move that resolves this is separating deployment from exposure. If a feature flag controls whether customers see a change, then code can continue to integrate during the freeze while nothing changes for shoppers. That decoupling is worth building regardless, and it turns the freeze from a hard stop on engineering into a control on customer impact, which is what it was always meant to be.

Experiments break the definition of done

Retail runs on experimentation, and this creates a genuine conceptual problem for everything in this series.

The definition of done in an experiment-heavy organisation is not “the code does what the ticket said.” It is “the code does what the ticket said, and the variant performed.” Those are different claims, separated by weeks, and only the first is checkable at merge time.

This matters because it puts a ceiling on what criteria verification can tell you. A change can satisfy every acceptance criterion perfectly and be reverted a fortnight later because it reduced conversion. The pipeline will record it as done and correct, and it was, on the only question the pipeline can answer.

The honest position is to keep the two verdicts separate and say so. Criteria establish that the thing was built correctly. The experiment establishes whether it should exist. Conflating them produces either a team that thinks passing criteria means success, or one that concludes criteria are pointless because things pass and still get rolled back.

Built correctlyCheckable at merge. Criteria answer this and nothing else.

Exposed safelyFlag configuration, ramp, kill switch. An operational property, not a code one.

PerformedSettled weeks later by the experiment. No pipeline verdict applies.

KeptA product decision. The flag and the dead branch both need cleaning up either way.

That last row is where retail codebases rot. Flags accumulate, losing variants stay in the code, and after two years the checkout path has eleven dead branches nobody dares remove. Higher change throughput accelerates this considerably, and flag cleanup is exactly the kind of well-specified tedious work agents are good at, which makes it the most obvious place to point them.

The catalogue is code that is not in your repository

The third constraint is structural. A large share of what determines customer experience in retail lives in systems that are not source control: merchandising rules, pricing and promotion configuration, category and search tuning, content in a CMS.

These change constantly, they are edited by people outside engineering, and they break things. A promotion configured wrongly can be more damaging than a bad deployment, and it will not appear in any delivery metric, incident count or change record the engineering organisation maintains.

I do not think there is a tooling answer to this and I would rather say so than pretend. What is achievable is an honest coverage map: knowing which behaviour-changing surfaces are visible to your delivery record and which are not, and not reporting metrics as though they covered everything. A change failure rate computed over deployments, in an organisation where promotions cause a third of customer-visible incidents, is a number that describes a minority of the risk.

Where the throughput actually pays

Retail has an unusually good match between what agents do well and what the business needs a lot of.

Integration work, which is endless: payment providers, carriers, marketplaces, tax services, fraud vendors, warehouse systems. Each has its own interface, its own edge cases, and its own tedious adapter. Data and reporting pipelines. Internationalisation and localisation. Migration work off whichever platform is being replaced this year. Performance work on the storefront, which is directly revenue-linked and unusually well-specified.

And the operational tooling that nobody ever staffs: the internal admin screens, the customer service tools, the bulk operations that someone currently does with a spreadsheet and a database client. This work has clear requirements, low risk, real value, and it never reaches the top of a roadmap. It is the single best first target in a retail organisation.

Where this breaks down

Peak is genuinely unforgiving and I have been relaxed about it. An outage during peak trading costs a determinate and large amount of money, and the conservatism around it is earned. Decoupling deployment from exposure is the right answer and it requires flag discipline that many organisations do not have yet, in which case the freeze should stay exactly as it is.

Experiment infrastructure is a prerequisite, not a detail. Everything above assumes you can ship dark and ramp. Organisations without that capability cannot separate the four verdicts and should build the flag layer before increasing throughput, not after.

Flag debt is created faster than it is cleaned. Pointing agents at cleanup helps, and the generation side still creates flags faster than anyone retires them. This needs an owner and a policy, typically an expiry date on every flag, and it is a discipline problem rather than a tooling one.

And personalisation and ranking are not code changes. A meaningful share of what a modern retailer ships is model behaviour, and no acceptance criterion evaluates whether a ranking change is an improvement. That needs its own evaluation discipline, and the criteria machinery here has nothing to say about it.

The takeaway

Retail can adopt almost all of this immediately, which makes the interesting question what to do with the throughput rather than whether it is safe.

Separate deployment from customer exposure so the freeze constrains what shoppers see rather than what engineering integrates. Keep the four verdicts on a change distinct, because criteria answer only the first and treating a green pipeline as commercial success is a category error. Be honest that the catalogue and promotion surfaces sit outside your delivery record, and stop reporting metrics as though they did not.

If you take one thing into next week: count the flags in your checkout path and find out how many are older than a year. That number is the cost of the last throughput increase, and the next one will be larger.