I handed Claude Code the receipts that Shufersal, one of Israel’s largest supermarket chains, texts me, and it rebuilt my weekly cart at a different chain: 25 lines, 422.12 shekels, under 1% off the same basket priced from my receipts. At Wonderful I worked on several agentic e-commerce projects and I thought they were a bad idea. Recently I changed my mind — not about the assistant on the website, but about when it is worth anything.
Why it looked silly to me
At some point the big global retail groups decided that the pushy floor rep who asks “can I help you?” — the one we answer on autopilot with “just looking” — deserved a virtual version on their website.
That struck me as worse UX than browsing, even when the agent shows product photos. I also assumed it would shrink the average basket: someone browsing runs into things they were not looking for, someone in a conversation gets exactly what they asked for.
What changed my mind
An agentic experience helps mostly when it does not replace browsing but eliminates it — when it completes full automation on the customer’s side. That only happens in what you could call zero-click adoption.
The rule is simple: if I as a user have to work for the agent, nothing has been achieved. It has to work for me, and simply know what I need.
Usually that is impossible, because knowing what I need takes data nobody has. But sometimes it is just sitting there. Household groceries are a convenient extreme: my purchase history exists, and it is remarkably consistent. Nothing else is needed.
That also explains why most categories fail the test. A sofa or a laptop is bought once every few years, the history says nothing about the next time, and without history the agent has to ask — which hands the work back to the customer. Finding the categories where zero clicks is achievable is, to me, the most worthwhile part of the work, and it is a business question, not a technical one.
What actually happened
I gave Claude Code 73 links to green invoices — the digital receipts Shufersal sends as an SMS link. 62 had already expired, because Shufersal deletes them after roughly six months, leaving 11 receipts spanning 31/05/2026 to 22/06/2026. Three weeks, or about three small shops a week.
From those it built a product table with frequency: in how many of the 11 receipts each item appeared. Eggs in 6 of 11, hard cheeses in 6 of 11, tofu in 3. It also inferred a profile nobody fed it — vegetarian, kosher, heavy on dairy and eggs. Vegetarian it got from an absence: no meat, poultry or fish appeared on any receipt. Kosher came from the brands themselves, mehadrin cottage cheese and badatz-supervised cornflakes.
Then it took that list to online supermarkets to compare prices — a comparison that also has to account for the discounts I get through consumer clubs at some chains, but that is a separate post. The one I documented end to end is Victory, another Israeli chain, and that is where it got interesting.
What the site actually exposes
Victory’s online store runs on a white-label grocery platform called ZuZ/Prutah. It is an older AngularJS single-page app. Product search is a fully public endpoint, no login, returning per product an id, name, brand, whether it is sold by weight, its kosher certification and the branch price. Kosher status is a field, not a guess from the product name.
The cart is a different story: it needs a login — phone plus a one-time code, or Google/Facebook — and then a bearer token on every call. And here is the rule easiest to get wrong. Items sold by weight go in as grams, and their unit price is the price per kilo divided by a thousand; packaged items go in as unit counts. Miss the second half of that rule and a one-kilo banana line gets billed as a thousand.
Where it broke
The catalog is not the same thing as deliverable stock. Eight of the 25 lines were swapped: six because the exact SKU could not be shipped to a Tel Aviv address — spelt pita became spelt rolls, one brand of tofu became another — one was re-added, and one was the coconut correction.
One of those eight is the case where it refused to guess. A receipt line read נוזל אגוזי קוקוס — literally “coconut-nut liquid”, which in Hebrew covers both a coconut drink and coconut cooking milk. It mapped it to a drink and flagged it for confirmation — correctly: the first pick was wrong, and the final one was a can of Thai coconut for cooking.
Those two things are the whole job of the order-builder: it does not search for a product, it adjudicates between matches. Which brand is close enough, what to do when an item will not ship, when to stop and ask instead of deciding. That is precisely the part a chain does not need to build for me.
The result: 25 items at ₪422.12, after ₪41 came off in promotions. The same basket at Shufersal, priced off my receipts, came to roughly ₪424 — a gap of about two shekels, under 1%. I stopped before checkout and payment; the login was mine, not the agent’s.
The business plan was sitting on the architecture diagram
Trying to work out how to wrap this into production, I looked at the architecture diagram and saw the business model in it. It had been written there all along, in the names of the boxes:
| Stage | What sits there |
|---|---|
| Input | My current store — automatic, from receipt history |
| Extractor agent | Reads every receipt, decides each product’s frequency |
| Databases | Products + frequency, and order history |
| Order-builder agent (weekly) | Decides between product matches, substitutes missing items |
| Output | The cheapest store, with a cart ready |
Input: the store I shop at now. Output: the cheapest store. This is, functionally, a machine that converts a shopper from their current supermarket to the cheapest one.
And that is already worth the effort to the cheapest supermarket. My assumption is that acquiring a new customer costs a chain far more than the margin it gives up on one basket; here the machine delivers one, with a full basket on day one. It could also make the market a little more efficient, and hand some power back to us as consumers.
What this means for the retailers
The corporations can settle for building an MCP server, or even just a decent API. They do not need an agent of their own.
Notice where the intelligence sits in the table above: in the two agents, and both are mine. The chain does not have to pick between two cheeses for me or guess at a substitute. It needs a catalog you can search and a cart you can write to. At Victory the search side already qualifies, without anyone intending it; what is missing is a cart side that is documented and authorized rather than reverse-engineered out of a browser.
That is the difference between investing in a chat widget and investing in an interface. The widget competes with your customer’s browsing; the interface plugs into your customer’s agent. My guess is the second is cheaper to build, and it certainly is not limited to whoever lands on your site.
What I take from it
I still think a sales agent on a website is usually a worse experience than browsing. What changed is that I stopped treating that as the question. The question is how much work the customer does before anything happens — and if the answer is not “none”, there is no value there.
Honest status of the project: what has run so far ran mostly by hand, against Claude Code, from scratch each time. The extractor and the order-builder do not yet exist as components that run themselves every week. There is a difference between proving a machine is possible and operating one.
The same pattern shows up inside organizations: quite often the business plan is lying on the architecture diagram and nobody has read it. This is how I work with organizations.