Once a grocer accepts that AI shopping is coming, the conversation moves to a single slide with three options on it. The slide is usually wrong, because it compares the options on cost and timeline and skips the thing that actually separates them.
Here is a more useful version of the same slide.
Option one: build it
The instinct to build is strongest at grocers with capable engineering teams, and the instinct is not wrong about capability. It is usually wrong about scope.
What a demo requires is a language model and your catalog API. What a production grocery agent requires is a longer list: matching plain-language requests to a messy catalog, quantity and unit math, substitution logic when items are out of stock, dietary and allergen filtering when the tags are missing from the product data, budget handling, cart refinement across turns, an evaluation harness so that changes to the prompt do not silently break last month’s behavior, and the operational work of keeping all of it correct as the catalog moves.
The build is not the chat interface. The build is everything under it, plus the evidence that it works. Teams that ship the demo in three weeks routinely spend the next four quarters on the rest, and the four quarters are the expensive part.
Build is the right call when AI shopping is intended to be a durable competitive asset that you will keep investing in, and when you have the appetite to staff it permanently rather than as a project.
Option two: bolt it on
Adding an AI assistant to your existing storefront is the cheapest option, and for some grocers it is genuinely sufficient. It is also the one most often oversold internally.
Two constraints matter. The first is architectural: an assistant bolted onto a storefront can generally only do what that storefront lets it do. If your platform does not expose the cart, the assortment logic, or the layout, the assistant ends up as a smarter search box next to an unchanged store.
The second is who controls it. If your storefront is a third-party platform, then the pace, the roadmap, and often the ranking rules belong to that vendor. You are adding a capability to an asset you do not fully control.
Bolt-on is the right call when you own your storefront outright, the platform is genuinely extensible, and the goal is incremental improvement to a funnel that already works.
Option three: run a standalone AI storefront
The third option is a separate storefront, in your brand, connected to your catalog, inventory, and pricing, handing every order to the checkout you already operate. It runs alongside the store you have rather than replacing it.
The advantage is that it sidesteps the platform constraint entirely. You are not asking a locked-down storefront to become something it was not built to be, and you are not rebuilding the store that currently takes your orders. Both stores point at the same catalog. Shoppers who want to browse still browse.
The honest cost is that it is not zero integration. Connecting catalog, inventory, pricing, cart, and orders is real work with real scoping. Anyone promising an instant launch is describing a demo, not a deployment. What it avoids is the replatform, not the integration.
Standalone is the right call when your storefront is locked down or vendor-controlled, when you want an AI channel that carries your brand and reports to you, and when you would rather test the channel than commit to building the capability.
The five questions that actually decide it
Skip the feature comparison. These five separate the options faster.
Can you change your storefront? If the answer involves a vendor ticket queue, bolt-on is weaker than it looks on the slide.
Who needs to own the shopper data? If the answer is you, rule out anything where the intent lands in someone else’s system.
Is this a capability or a channel? Capabilities get built. Channels get run. Confusing the two is how build projects overrun.
What would change your mind? If no result from a pilot would change the internal decision, you are not evaluating, you are ratifying. Say so and save the quarter.
What does doing nothing cost? Sometimes the honest answer for a given grocer is: not much, this year. That is a legitimate outcome of this framework.
Our position, and its limits
We build the third option, so treat this as an argued position rather than a neutral survey. What we would defend is narrower than “buy from us”: for most regional and mid-market grocers, the ownership question is more consequential than the technology question, and it is cheaper to answer through a contained pilot than through a build.
We also would not claim the category is ours alone. Several companies build agentic grocery shopping, including at national banners. Our evidence is one pilot with one grocer, reported directionally. If a build or a bolt-on fits your situation better, the framework above should tell you that, and it is a better use of this article than a sales conversation.