What 15 years of e-commerce delivery taught me about shipping AI agents

I have spent fifteen years delivering e-commerce projects. Replatforming, mostly: moving a retailer from one commerce engine to another without breaking the business while the work is underway. I now spend a large part of my time building AI agents. Different technology, same job. And the way agent projects fail is the way replatforms always failed. The tools are new. The failure modes are old.

Integration edges are where projects die

On a replatform, the storefront is rarely the problem. The page renders, the catalogue loads, the design matches the mockup. The part that decides whether you ship on time sits at the edges — the PIM that owns product data, the ERP that owns stock and price, the payment gateway that owns money. Each is a system you do not control. Each has its own owner, its own release cycle, and its own idea of what a valid request looks like. The demo works because the demo talks to nothing. Production is hard because production talks to everything.

Agents have the same shape. The model is not where a project dies. It dies at the tool boundary: the function you let the model call, the data it is allowed to read, the permission it needs to write. A tool that returns clean data in a test returns something else entirely in the real world.

get_order(id) -> { total, currency, items }   // in the demo
get_order(id) -> null                          // guest checkout, partial refund, a currency nobody handled

The agent then reasons, confidently, over nothing. So I spend more time on the edges of an agent than on its prompt — for the same reason I always spent more time on the ERP integration than on the storefront. The clever words the model produces are cheap. The boundary where it meets a real system is where the cost lives.

The model is not where a project dies. It dies at the tool boundary.

Go-live is a process, not a date

No serious replatform goes live on a date someone picked in a planning meeting. It goes live when a checklist is green: order flow reconciled against the ERP, tax correct in every market, a rollback that actually works. You soft-launch to a slice of traffic. You watch. You widen. A date is an ambition. Go-live is a state you reach, and you can only claim it once.

Autonomy for an agent works the same way. You do not hand an agent write access on the day it demos well. You run it in the shadow first — it proposes, a human disposes, and you measure the gap between them. You build an evaluation set from real cases, not from the happy path you imagined at the start. Only when the agent is right often enough, and wrong in survivable ways, do you widen what it is allowed to do on its own. Eval is the soft launch. Autonomy is traffic you earn, not a date on a plan.

Stakeholders buy outcomes, not architecture

The quickest way to lose a commerce project is to sell the architecture. Nobody approving a replatform wants a lecture on headless, composable, or event-driven anything. They want conversion up, returns down, and the December peak survived. When I led delivery of Møbelringen's platform — Norway's largest furniture chain, seventy stores, an Adobe Commerce and Next.js build running headless on Vercel — the thing that mattered to the business was plain: a customer could begin online and finish in a shop without the two halves of the company contradicting each other. The architecture served that outcome. It was never the point of the conversation.

Agents fail the same way when they are sold as headcount arithmetic. "Replace three people" is a promise you cannot keep and a fight you do not want to start. The agents that survive contact with an organisation are sold as the fix to a specific, tiresome workflow:

• the invoice that gets rekeyed into four systems by hand
• the support queue nobody wants to triage at eight in the morning
• the report someone rebuilds from scratch every Monday

Same discipline as commerce. Sell the outcome. Let the architecture stay a private matter between you and the system.

Omnichannel taught me to degrade gracefully

Omnichannel retail forced me to design for the moment things break, not the moment they work. Stock is wrong. A card is declined. The in-store system is down while the website is up. A good omnichannel design degrades on purpose — it falls back to a slower path, tells the customer the truth, and keeps the sale alive instead of throwing an error and losing it.

An agent needs the same instinct, and few have it by default. The failure mode of a language model is not silence. It is a confident answer to a question it should have refused. That fallback has to be built, never assumed. The agent should know the edge of its own competence and hand off across it: escalate to a person, ask for the input it is missing, refuse and log rather than guess. I spent years working remotely, coordinating people across time zones before the tools for it were any good. That left me with a bias I still trust — the handoff between a machine and a person is where quality is won or lost, so you design it on purpose or you pay for it later.

The scarce skill is delivery, not building

None of this says building agents is easy. Tool use, MCP servers, the Claude Agent SDK, multi-agent orchestration on Microsoft Foundry — the engineering is real, and it gets harder as the systems get more capable. But building was never the scarce skill on the projects I have watched succeed or fail. Plenty of people can stand up an agent that demos well. Far fewer can put one inside an organisation — with its real data, its real permissions, its office politics and its very real opinion about being wrong — and have it still running, and still trusted, a year later.

That is the job. It was the job when the deliverable was a commerce platform, and it is the job now that the deliverable can think. The model is the easy part. Delivery is everything around it.