Ask an AI model for a figure it does not have and it will give you one anyway. It has read millions of documents. It knows what a plausible number looks like. So it fills the gap, in confident English, and the answer looks exactly like a correct one.
Ordinary software fails loudly. It throws an error and stops. An AI model fails politely, and you find out from a customer.
If your name goes on the numbers, that is the problem to solve before anything else. The solution is not a better prompt. It is to give the model buttons, not a database.
Why a prompt cannot fix this
The first thing everyone tries is an instruction: "Only answer from the provided data. Never guess." It helps. It does not hold.
A prompt is advice. The model follows it most of the time. It follows it least in exactly the situation you care about: a reader asks something the data does not cover, and a plausible answer is available from memory. Instructions lose that contest often enough to matter.
So the fix has to be structural. The model must have no way to produce a figure except by fetching it.
What a tool is, and why it changes everything
An AI model can be given tools. A tool is a small function the model is allowed to call. Think of a button that runs one specific query and hands back the result. The model decides which button to press and how to phrase the reply. The button supplies the number.
Now take everything else away. No open web. No file uploads. No writing code. If the model has only buttons, it can only answer what the buttons can fetch. Ask for something no button covers, and there is nothing to press. The honest reply is "I cannot answer that", and it comes for free.
That is what people mean by a grounded agent. Not a model told to be careful. A model that cannot be careless.
Four rules that make it hold
Buttons alone are not quite enough. Four rules go with them.
One button per thing the data can answer. Not one general "query the database" button that can be asked anything, including things the data does not hold. One button per view, table or report, each returning its result in the shape that view uses.
No arithmetic in its head. Any sum, difference or percentage goes through a calculator tool, and the answer shows the working. Models are unreliable at arithmetic and confident about it.
Every figure carries its source. The query or document that produced it is in the answer. A reader can check it, and so can you.
Check before you try. If a question names a state, a sector and a year, the agent confirms all three exist in the data before running anything. If one is missing, it stops and offers questions it can answer.
A worked example: a climate data publisher
OnlyFacts.io is a small nonpartisan fact tank in Australia. It publishes the climate data newsrooms quote by name, under an open licence, so anyone can republish it with attribution. A wrong figure does not sit on their site waiting to be corrected. It travels, with their name on it.
Their readers kept emailing for numbers that were already on the site, nine sections deep. A chatbot would have answered faster. Sooner or later it would have answered wrong.
We built the agent with 190 buttons, one for each published view of the data, each tied to the chart that view uses. Open web off. Calculator for every sum. Source on every figure. Answerability check before every query.
Here it is on a real question: "What is Australia's emissions trend with state and sector breakdowns?" It confirms all three dimensions exist. It runs two separate queries, national then by state. It works out the gap to the 2030 target with the calculator: 43 minus 24.7 equals 18.3. It writes the answer with a footnote on every figure, pointing to the national inventory. A reporter can paste that into a story.
The pilot took under three weeks, because their data was already clean and structured. The full engagement, with the numbers, is in the OnlyFacts case study.
Keeping it honest after launch
Most AI projects are at their best on launch day. Then the model updates, the wording drifts, and nobody notices until a reader does.
So nothing ships until it passes a set of checks on real questions. For OnlyFacts there are four. Does the number match the database. Is that the right chart for this data. Is the citation there. Has a banned word crept back in. The checks run before every change. That is also why they can switch to a newer, cheaper model the week it lands and show the answers did not move.
What this does not solve
A grounded agent answers what its buttons can fetch. A new dataset needs a new button before the agent can see it. Asked for a forecast the data cannot support, it declines in plain words. Some readers get a polite no where a chatbot would have given a fluent guess. And it was fast to build because the data was already clean. A messy corpus moves the work from the agent to the data.
What to do this week
- List what your data can answer. One line per table, view or report. That list is your set of buttons.
- Find every place an answer needs arithmetic and route it through a calculator tool.
- Switch the open web off for any agent that speaks for your numbers.
- Put the source in every answer. If a reader cannot check a figure, neither can you.
- Write four checks that would catch the failure you most fear, and run them before every change.
The bottom line
You cannot instruct a model out of inventing numbers. You can build it so it has no way to. Give it buttons, not a database, take the open web away, and put the source in every answer. The job transfers to anyone whose name goes on a figure: research desks, regulators, investment committees, compliance teams.
