The agent that won wasn't the one that knew more. It was the one that asked.

For retail and FMCG leaders — stop trying to fix decision quality by giving the model more knowledge, and start specifying what each decision is not allowed to be made without.

Two paths approach one decision point; one gathers evidence before arriving.

A study about questions, dressed as a study about medicine

The headline that will travel from this research is the one about doctors, and it is the least useful part. Here is what happened. Participants described a symptom to an agent built on Gemini Flash 2.0. In one condition the agent simply worked with what it was told. In the others it asked follow-up questions, either from a fixed clinical questionnaire, a flexible version of one, or by deciding dynamically what to ask next. Afterwards, participants reported what a healthcare provider had actually told them, and a blinded panel of three board-certified clinicians compared the agent’s differential list against lists written by other clinicians.

Every condition in which the agent asked its own questions significantly outperformed the condition where it did not. The panel preferred the agent’s list in over half of the cases and ranked it first on quality in 53.3% of them.

Two caveats belong right next to those numbers, because without them the result is routinely overstated. The clinicians in the comparison were not seeing patients; they were reading the transcript the agent had produced, and the study says plainly that they “were not given agency to ask their own follow-up questions”. And SymptomAI is described by its own authors as an exploratory research effort, an investigational agent, not a medical product. So this is not evidence that AI diagnoses better than a doctor. It is evidence about something narrower and, for anyone building decision systems, considerably more useful.

The finding underneath the headline

The comparison that matters is between the conditions, not between the agent and the clinicians. What the study reports is that every condition in which the agent asked its own questions beat the one in which it did not, whether the questions came from a fixed clinical questionnaire, a flexible version of one, or were chosen dynamically. Our reading of that design is the interesting part: if the advantage had come from clinical knowledge encoded in a script, you would expect the rigid questionnaire to stand apart from the rest. What the conditions share is not a script but a posture, spending turns reducing uncertainty instead of answering from whatever was given.

That is a statement about decision architecture wearing a lab coat. The model’s knowledge was constant across all five conditions. The only thing that changed was whether the system took responsibility for finding out what it did not know.

Four required evidence inputs for a markdown decision, with a rule to fetch missing facts or stop.
01 / Four required evidence inputs for a markdown decision, with a rule to fetch missing facts or stop.

Your operating decisions have the same shape

Now move it out of the clinic, and treat what follows as a pattern worth checking rather than a proven equivalence. Consider a markdown decision on a perishable line: how deep to cut, and when. The request that reaches the system usually contains the SKU, the store, current stock and days of supply. The decision, though, is determined by things that are almost never in the request. Whether a competitor started clearing the same category yesterday. Whether the weather forecast just moved demand by a third. Whether there are four hundred units sitting in a store eleven kilometres away that could be transferred instead of discounted. Whether the next delivery is already in transit.

A system that answers from the request alone will produce a fluent, confident number. It can also be wrong in a way that surfaces late, because nothing in the output signals that a decisive fact was missing. The shape resembles the study’s base condition: an answer built on whatever the person thought to mention.

The alternative is not a better model. It is a system whose first move on a decision is to check what it must know and to notice when it doesn’t know it.

Define decisions by what they must know

The practical form of this is a shift in how a recurring decision is specified. Most definitions describe the output: what the system may recommend, within what bounds. The more useful definition starts from the input side and names the evidence the decision is not allowed to be made without.

For a markdown beyond a set depth, that list is short and specific: current competitor activity in the category, stock in nearby locations, inbound supply status, and the margin floor with current elasticity. Four items, each obtainable, each capable of changing the answer. Once they are named, three behaviours become possible that were not before. The system can fetch what is missing rather than proceeding without it. It can stop and escalate when something cannot be obtained, which is a far better outcome than a confident guess. And a reviewer can see, at a glance, whether this particular decision was made on a complete picture or a partial one.

This is what SHEPORD is designed to carry: each recurring decision class defined with the evidence it requires, so a decision is either made on that evidence or explicitly held back for a named owner. Deciding what that list should contain in the first place is a separate craft, and it is what BoardRA is designed for: mining how a decision is actually made today, then turning that into an explicit design before anything runs.

A signal triggers questions that return evidence and assemble a more complete decision picture.
02 / A signal triggers questions that return evidence and assemble a more complete decision picture.

The second layer: let the signal start the conversation

The study includes a quieter finding. Participants had been wearing devices, and biosignals gathered in the weeks beforehand aligned in time with the respiratory illnesses the agent went on to suspect. The authors are careful, and so should we be: temporal alignment supports plausibility, it does not confirm any individual’s diagnosis.

The design implication is what matters. It suggests an enquiry that does not wait to be asked. A deviation appears, the system begins gathering, and by the time a person is involved the picture is already assembled.

Operations have their own version of this signal. Waste in a category creeps above its normal band. Availability in a cluster of stores drifts down. A supplier’s delivery variance widens. Today those signals mostly generate alerts, which is to say they generate work for a human who must then go and find out what happened. The more valuable pattern is the one from the study: the signal triggers the acquisition, and the human arrives to a decision that is already evidenced.

That is the shape DecidRA is designed around, as the producer side of the portfolio: it is built to watch governed indicators, raise a deviation with its evidence attached, and put forward candidate decisions. It is designed to propose rather than authorise, which keeps a clean line to the next step, where SHEPORD decides whether a candidate may proceed.

A decision trace records what was decided while an acquisition trace records what was asked and still missing.
03 / A decision trace records what was decided while an acquisition trace records what was asked and still missing.

The third layer: record how you found out, not only what you decided

Here is the layer almost nobody builds, and the one likely to matter most over time.

Every decision system worth the name keeps a record of what was decided and why. Far fewer keep a record of the path taken to get there: which questions were asked, in what order, which piece of retrieved data actually changed the recommendation, and where a human overrode it and on what grounds. In the study, that path is exactly what was being tested, since the conditions differed only in how the agent went about asking.

The value of keeping it is that it is the only material from which the acquisition itself can improve, and it is the raw input for design: BoardRA is designed to mine exactly these trajectories, so that the next version of a decision class can inherit what earlier runs revealed about which questions mattered. A decision trace tells you that the system chose a thirty percent cut and was wrong. An acquisition trace tells you that it never checked nearby stock, how often the recommendation changes once that check is added, and that the merchant who overrode it was reacting to a competitor signal the system had no route to obtain. The first record supports an audit. The second improves the next decision.

What to do with this on Monday

Take one decision your business makes thousands of times a week and write down what it must know. Not what the system may output, and not what data happens to be available: the specific facts without which the decision should not be made at all.

Then check what happens today when one of them is missing. If the answer is that a recommendation appears anyway, indistinguishable from the ones made on complete information, you have found the same gap the study’s base condition had, and no upgrade to the model behind it will close it.

The agent in that study did not win because it knew more medicine. It won because it treated the gap in its own information as the first thing to fix.