Where a prompt's mistakes are actually born
I write payroll software. In my world, "almost right" is a polite word for wrong. A salary that's off by one crown still has to be corrected, explained and signed off, and a payslip paid
out three years ago must still match the rules it was calculated under.
So when I hear people say they don't trust AI because the same question gets a different answer every time, I don't argue. I mostly agree. But I wanted to know why the answers differ, so
I asked the one who gives them.
"If I ask you the same question twice, will I get the same answer?"
Not necessarily. But "the same question" is doing a lot of work in that sentence.
"Meaning what?"
Meaning that most questions leave something open. Which ticker, which price, which period. Each time, I fill those gaps — and I may fill them differently.
That I understand better than I'd like. In payroll, "salary" can mean base pay, gross, net, with allowances, with the quarterly bonus. Ask five people for an employee's salary and you can
get five correct answers to five different questions. That isn't an unreliable system. That's an imprecise question.
But a different answer isn't what keeps me up at night.
"What worries me is the wrong answer nobody notices. A filter built slightly wrong, a list of employees that's quietly incomplete. No error message. Somebody just doesn't get paid."
Then let's find where that kind of mistake is born. It isn't one place.
Where you ask
The first place surprised me, because it happens before any answer at all.
A few days ago I wanted to try a new MCP server, and typed into a chat: use canli-mcp: who owns more than 5% of Coca-Cola? Nothing useful came back. That server runs on your own
computer, through the desktop app. I had asked in the browser, where it could never reach.
I couldn't use a tool that wasn't connected to that conversation, and this time I said so. The risk is the other case: a question that sounds answerable, and a model that answers it
anyway — from memory.
"From memory meaning…"
From what I learned in training. That can be months old. I'll know Coca-Cola's long-time largest shareholder. I won't know last week's filing.
That's where my own story with AI began. I asked for Amazon's price, got a polite refusal, and thought: is that all this is? Only later did I understand that the question had gone to the
wrong place. Without a connection to live data, the honest answer is "I can't". The dangerous answer is a confident old number.
What the model chooses
"And when the tool is connected?"
Then the data is the same every time. What can change is what I ask the tool for. Which ticker. Close or adjusted close. Which dates.
So we're back at salary. The data in my payroll system doesn't change between two reports. The report changes, because someone chose gross instead of net.
The tool can make choices too. A developer named Arhan Canli wrote openly about a bug in an early version of canli-mcp, the free, MIT-licensed finance server he built (github.com/arhancanli/
canlicapital). Ask it for the "silver price", and it returned US consumer inflation. The word "price" matched the description of the inflation
series; the word "silver", the one that actually mattered, matched nothing. The tool didn't crash. It returned real numbers, neatly formatted, for a question nobody asked.
That's the kind of mistake that worries you. Not an error. A correct answer to the wrong question.
His fix was simple and, I think, wise: when the tool isn't sure, it now says "I don't know" and points elsewhere. My old programs did that by default. They crashed when something was
missing — loudly, rudely, and safely.
The filter that stays quiet
"So where does the quiet kind of mistake come from?"
Sometimes from the tool itself. Let me show you one we made together.
Last week, for an article about congressional stock trades, we pulled every trade made in
the last week of July and measured how long each one took to be disclosed. A hundred trades. Clean numbers, a tidy median, an honesty section about the small sample. Published.
Days later, while checking a reader's question, a single field in the server's reply said something the table never had: total: 111.
One request returns at most a hundred rows. The other eleven were there all along. Nothing failed, nothing warned. The data simply ended.
"That's my incomplete employee list."
It is. Every number we reported was correct — for the hundred rows we saw. The mistake was in assuming the hundred were all of them.
I've written payroll filters for years, and I know this failure by heart. It never looks like an error. It looks like a shorter list. The only defence I've ever trusted is to ask a second,
boring question: how many should there be? Compare the count with the list, and the silence starts talking. In the data we used, that question costs nothing — the total sits right there
in the reply, waiting to be read.
Does the server matter?
"If the tool can hide rows, how much does the choice of tool matter?"
Someone measured it. Arhan Canli — the same developer with the silver bug — ran one model with one prompt and the same limits, and changed only the server behind it. On the questions
every server finished, canli-mcp answered 22 of 28 runs correctly. The best alternative, EdgarTools plus Yahoo, answered 15 of 28.
That's the first measurement I've seen where everything stayed
fixed except the server. And it says what I suspected: the same model can be more or less accurate depending on what it's connected to.
With a caution he raised himself: each question was asked twice, and an easy question tends to be right twice. So it's closer to fourteen questions than twenty-eight. Promising, not
proven. He's running a fresh set of questions, written before any tuning, and has promised to publish the result either way.
I like that last sentence more than the numbers.
When the source is wrong
"And if the model asks the right question, and the tool returns every row?"
Then there's one place left: the data itself.
Two examples, both found by someone else.
In an article about stock splits I printed Tesla's "raw"
closing price before its 2022 split: $498.3201. A reader — Arhan Canli again, as it happens — noticed the fourth decimal. Stocks don't trade in hundredths of a cent. That number was
exactly three times Tesla's split-adjusted price. It wasn't a price someone paid. It was a price someone rebuilt. Out of 3,207 Tesla closes in my sample, 1,449 had more decimals than any
exchange would quote.
Which means part of the check compared the data with itself. It passed — because it couldn't fail.
The second comes from him too. The SEC publishes the exact time each
filing was accepted, and its submissions API keeps one file per company. He measured 450 filings from 25 companies. In 12 of the files, the times were right. In the other 13 — Apple,
Nvidia and Amazon among them — every time in the file was shifted by exactly one New York offset: four hours in summer, five in winter. A JPMorgan results filing accepted at 6:30 in the
morning, New York time, appears as if it came after the market opened. The same filing can show one time in one company's file and another in the next. Same filing, a different file, a
different hour.
Neither mistake announces itself. Both had a cheap check: count the decimals; compare one filing's time with a second source.
Final Thoughts
"Same question, different answer" turned out to be four different problems. The question was asked where no data could reach it. The model or the tool filled a gap in the question
differently. The tool returned less than everything and said nothing. Or the source was wrong before anyone asked.
None of them is fixed by trusting AI more, or less. Each is fixed by a cheap, boring check: Was the tool even connected? What exactly did it look up? How many rows should there be? Does
this number look like a real one?
That's also why I agree with the people around me who say AI shouldn't calculate payroll. It shouldn't. A calculation repeated every month for every employee belongs in a program that was
verified once and behaves the same way every time. That was the whole point of the dividend tracker in Part 2. A prompt is for the questions you ask once, and for getting to the data in the first place. And the final check, and
the responsibility that comes with it, stays with a person.
My challenge from Part 1 still stands: find a task where checking costs more than producing, and a prompt is still the right choice. I haven't found one yet. But I've learned where to look
first when an answer seems wrong: not at the model, but at the chain behind it.
New to this series? Start with Part 1: Is That All This Is? — A Programmer Meets the Prompt. The examples above come from my other series, Unlock Real-Time Market Intelligence with EODHD and Claude, where every number gets checked before it's trusted.
Top comments (0)