Perspectives
A brilliant answer is not a reliable one
Capability, intelligence and reliability are three different questions.
By Ehsan Gazar, 22 October 2026
Your team trusts an AI tool because it did something impressive. Then it gets a simple thing wrong, in front of a client. Both are true of the same system.
That is not a contradiction. It is three different questions asked as one.
A Millennium Problem and a word with two o's
OpenAI recently reported an AI-generated proof about Navier-Stokes, one of the Millennium Prize problems in mathematics. The formal review is still going on. Whatever it finds, this is serious work that no person had managed before.
In a live session with leaders, Anoosh Zeighami asked ChatGPT how many times the letter o appears in "notebook". Its first answer was wrong.
Researchers see the same pattern with puzzles. Give a model a familiar puzzle and it answers well. Change the rules so the puzzle becomes easier for a person, and the model often answers the old puzzle instead.
Easier for people does not always mean easier for the model.
Three questions, kept apart
When someone shows you what an AI system did, ask three questions, one at a time.
Capability. What did the system demonstrably do, on this task, under these conditions?
Intelligence. What broader ability might that imply? This depends on how you define intelligence, and it is where most arguments get stuck.
Reliability. Can we depend on this result, here, every time it matters?
One impressive answer settles the first question. It says almost nothing about the third, and the third is the one your organisation runs on.
Why capable and unreliable go together
Generative AI learns patterns from very large amounts of text. Given a prompt, it predicts the next token, adds it, and predicts again. That simple loop writes emails, summarises reports, classifies documents and drafts code.
The same loop explains the failures. The model produces the most plausible continuation, not a checked fact. Nothing in the loop knows whether the answer is true.
So one mechanism is broad and fragile at once. The capability is real. The reliability has to be built.
Reliability as a design job
A business usually needs a dependable result, and a model gives a probable one. Anoosh put it plainly in the session: whoever designs a bridge cannot sign off on probably.
You cannot make a model certain. You can design the work around it so the result is dependable. In practice that means four things:
- Break the task into steps small enough to check, instead of one large request.
- Retrieve rather than recall. Pull the clause, the formula or the figure from your own documents instead of trusting what the model remembers.
- Check the output with a second pass that compares it with its sources and flags any disagreement.
- Put a person where it matters. The system proposes, and someone accountable approves before anything is recorded.
This is how we build agents at Vatan. An Agent Sprint takes one process and designs it this way, with a person approving before anything reaches your systems.
What leaders need to see for themselves
A leader does not need to build any of this. A leader does need to tell the three questions apart when a vendor, a board paper or a headline blurs them.
That is why AI Enablement starts with how the technology works, before any strategy. A leadership team that understands next-token prediction stops asking whether AI is clever. It starts asking where a result can be trusted, and what that would take.
Anoosh and I taught this as a live session for organisational leaders on 21 October. Over 100 people signed up. The slides are on the hub.
The question is never whether AI is impressive, only whether you can depend on it here.