Where AI wins and where rules win

Language models are strong when the input is messy and varied: free text in many phrasings and languages, photos of documents, long procedures. They help most when many answers are acceptable, such as a summary or a draft, and when "mostly right and quick to check" beats "slow". They also help when the variety is too large to write rules for. Nobody can list every way a store manager might ask about a stuck delivery.

Rules, code and spreadsheets win when:

• The logic is exact and stable. Mangrove's expiry procedure, EX-3, says items two days before expiry get a 30% markdown. That is one line of code in the Store app, right every time.
• The answer is arithmetic. Till totals, stock differences, margins. Models are unreliable at exact arithmetic unless they call a tool that does it.
• The data is already in tables. "Which stores have stock differences over $100?" is a query. A dashboard answers it for everyone at once.
• The same answer is required every time, with an explanation an auditor can follow.

"AI" is not one tool either. Forecasting tomorrow's demand from sales history is a prediction from structured numbers: a job for a forecasting model built by a data team and judged by forecast error. Spotting empty shelves in photos is computer vision. A chat model is the right tool for language. Ask which kind of AI a proposal means before anyone writes a plan.

A useful lens comes from the book Prediction Machines (Agrawal, Gans and Goldfarb, 2018): AI makes prediction cheap, meaning filling in missing information, such as which procedure answers this question. Judgement, deciding what to do given what you value, stays with people or with rules people wrote. For every idea, name the prediction and name who owns the judgement.

The cost of being wrong

Every AI feature is wrong some of the time. The question for a PM is what a wrong answer costs, how often it happens and who catches it before it does damage. Put it in one line:

Expected cost of errors = volume x error rate x share NOT caught x cost of one uncaught error

Then compare it with the value of the right answers. Do this separately for each type of question, because one average hides the case that sinks you. Here is the first pass Imran did for Ask Ops, per week, on today's volume:

Rule questions, 1,350 a week, split by what a wrong answer costs:
Most of them     1,200 x 8% wrong x 50% not caught x $6     = ~$288
  (a wrong markdown, a re-done task; citations let managers catch half)
  value: 1,200 x ~$1.10 (6 desk minutes + 5 manager minutes) = ~$1,320
Customer data      150 x 8% x 50% x $2,000 (an incident)    = ~$12,000
  value: 150 x ~$1.10                                        = ~$165

The same 8% error rate is fine for procedure questions and unacceptable for customer data. The fix is a different design. For customer data, use a hard rule in code that never returns an address or phone number, with the model only explaining CD-1, the customer data procedure. Releasing customer data must be impossible by design, whatever the model does.

Three more things change the cost of an error:

• Errors are asymmetric. "Can I give this caller the customer's address?" answered yes by mistake is a privacy incident. Answered no by mistake costs one minute. Design for the expensive direction.
• Reversible or not. A wrong answer that someone reads can be corrected. A refund sent, stock adjusted or a supplier emailed may not be.
• Ease of checking. If a person can check the answer in seconds because the source and the data sit next to it, most errors are caught cheaply. If checking means redoing the work, the AI saved nothing.

Assist or automate

There is a spectrum between "AI suggests, a person decides" and "AI acts on its own". Lesson pm-50 turns it into autonomy levels for agents. For choosing a first problem, two questions decide where to start: how costly is a wrong result, and how quickly can a person check it?

Assist and automate create value in different ways. Assist saves search time and spreads expert knowledge to 320 stores, but a person still spends time on every case. Automate saves the whole task, but needs a much lower error rate, because nobody looks before it happens. Many good AI products start as assist and earn automation one task type at a time, with evidence from real use.

Assist only works if the person can really check. If the evidence isn't on screen, or approvals come in a stack of fifty, people approve without looking. Psychologists call this automation bias. Then you have automation with an extra click and someone to blame. Lesson pm-48 shows how to design checking that people actually do.

Screening AI ideas, and saying no well

Run every idea through the same seven questions before anyone builds. Each needs an answer with a number or a name, not an adjective.

1. Pain. How often does the problem happen, how long does it take, and for how many people? Measured today, not imagined.
2. The boring baseline. Would a rule, a report, better search, a clearer form or a fixed procedure solve most of it? Try that first, or at least price it.
3. Input. Is the input messy language or images (AI's strength) or structured data (rules' strength)?
4. Data. Do we have the knowledge or data the answers need, is it correct, and are we allowed to use it?
5. Cost of being wrong. Per type of case, in money and in trust, and who catches errors.
6. Can we measure it? Could experts write 50 real examples with agreed good answers? If they can't agree what good is, AI won't settle it. This set becomes the start of your evals (pm-49).
7. Unit economics. Cost per answer (pm-46) against value per answer, including the time people spend checking.

Most ideas that fail the screen fail on question 2 or question 6. That is good news: you have found a cheaper fix, or a definition problem worth solving anyway.

Saying no well means saying "not this, not yet, and here is what would change my mind", with the alternative attached. "AI markdowns" becomes "the EX-3 rule in the Store app in two weeks". "AI forecasting" becomes "a forecasting pilot with the data team, judged by forecast error". People asking for AI usually want the outcome, not the technology, and they accept a faster route to it.

Big ideas usually contain several problems. Ask Ops is a good example. When Tomás, Mangrove's data analyst, tagged a sample of 400 desk questions, they fell into three groups with different fits, shown below.