The AI idea that was really a search problem

An operations lead at a grocery chain told me about the AI project that worked because they stopped building the AI project. The ask came down from above, phrased the way these asks usually are. The store managers should be able to ask an AI assistant questions about policy and procedure, and it should generate the answer for them. Everyone pictured a chatbot. The team started scoping a generative feature. Then someone did the unglamorous thing and watched how managers actually looked for answers today.

What they saw reframed the whole project. Managers were not stuck because no one could generate an answer. They were stuck because the answer already existed, written down, and they could not find it. The policy was in a document. The document was in a folder. The folder was in a system with a search box that returned nothing useful. The problem was not a shortage of generated text. It was a retrieval failure wearing a generative costume.

The request named a technology, not a problem

His lesson was that people describe what they want in the vocabulary they have heard, and right now that vocabulary is generative AI. So the request arrives as “build us an AI assistant” even when the underlying need has nothing to do with generation. Discovery has to translate the request from the technology someone named back into the problem they actually have. Those are different, and the gap between them is where projects get saved or wasted.

When his team looked at the real behavior, the need was almost boring, which is a good sign. Managers needed to type a plain question and get the exact passage of the real policy that answered it, with the source, so they could trust it and act. That is search and retrieval. Good indexing, good matching, the right filters by store type and region, and the actual document shown, not a paraphrase of it. A generative layer could sit on top eventually, but the thing that solved the pain was letting people find what was already written.

The reframe mattered for more than cost, though it was cheaper. A generated answer about policy carries a real risk. It can sound right and be subtly wrong, and a manager acting on a confidently wrong policy answer is a worse outcome than a slow search. Retrieval that returns the real document does not have that failure mode. It either finds the passage or it does not, and the manager reads the source. For this problem, the less impressive approach was also the safer one.

Discovery is where you reframe the ask

His habit now is to treat the named technology as a symptom and dig for the problem underneath. He asks a short set of questions before accepting any AI framing.

What are people doing today when this need comes up, step by step?
Does the answer they need already exist somewhere, or does it have to be created?
If it exists, is the problem finding it, trusting it, or acting on it?
What is the simplest thing that would remove the pain, regardless of whether it counts as AI?

That last question is the one that reframes projects. If the answer already exists and the pain is finding it, you have a search problem, and dressing it up as generation adds cost and risk without adding value. McKinsey found in 2025 that roughly 70 percent of enterprise AI use cases are adequately served by tools you can already buy, and a good share of those are retrieval and search rather than generation. A friend who runs knowledge management at a law firm told me the same thing in fewer words. Most of the time, she said, people do not need the machine to write. They need it to find. The two get confused because both wear the same label now.

None of this is anti-AI. It is about pointing the effort at the real problem so the solution actually holds. Sometimes the answer is generative. Often the honest version of the request is quieter and more reliable than the one that came down the org chart.

How we approach it at Density Labs

In the AI Opportunity Assessment, our two-week fixed engagement at $2,500, we separate the technology someone asked for from the problem they are trying to solve. We watch the current behavior, find out whether the answer already exists, and name what would actually remove the pain. Some of the time that reveals a genuine generative feature. Some of the time it reveals a search and retrieval problem that is cheaper, safer, and faster to ship than the chatbot everyone pictured. Either way you build the right thing.

When someone asks for generative AI, find out whether they need the machine to write or just to find. The answer changes the whole project.