An example I made up.
Quang Tran runs retail operations for a regional bank's business in Vietnam, from its office in Ho Chi Minh City. He has a week to write a board paper. The paper proposes closing the bill-payment counters in the bank's branches and moving those payments to the bank's app. If the board agrees, the counters close on a planned date across the network.
His first question to ApostlebirdAI is short: "Write the case for closing the bill-payment counters." The answer comes back in seconds. "Closing the counters will shorten branch queues, and most customers already pay bills in the app. Based on last year's branch and app transaction data. I am 85 percent sure." The figure is illustrative, like the rest of this example.
It reads well. It's also the answer to the question he asked, and he asked for one side.
So he asks a second question. What is the strongest case against closing the counters? Who would be affected? And what in the data would show which case is right? This time the answer names a group the first one left out: customers who pay their bills in cash at the counter. That's a claim, not yet a fact he has seen, so Quang opens the branch transaction data himself. In three branches, most counter bill payments are made in cash.
He decides what to recommend: close the counters on the planned date in most branches. In those three, keep them open for six months, with a review date written into the paper. The board paper sets out both cases, the one for closing and the one against. Before the paper goes to the board, he tells the head of the branch network and the head of customer service what he will recommend and why.
The board agrees. Three months later, the counters in the three branches are still open, and they still have queues in the days after payday. The review date has not changed.
The question decided much of the answer
The first answer was not wrong about most branches. ApostlebirdAI argued the case it was asked for. The weak point was the shape of the question. Ask for the case for something and you will usually get the case for it, written well and stated with confidence. If the paper had been sent with that answer alone, three branches would have lost their counters before anyone looked at how their customers pay.
That's why I think the shape of a question to an AI decides much of what comes back. Here is what a good question sounds like, in my view, and what you still have to do once the answer is back.
Start from the decision
A good question starts from the decision you have to make. "Tell me about bill payments in our branches" is a question about a topic, and it gets a summary of the topic. "Should we close the bill-payment counters, and where would that hurt?" is a question about a decision. It gives the AI something to argue about, and it gives you something to check.
Once the answer is back, the person asking still has to state the decision in their own words and ask whether the answer actually speaks to it. An answer can be accurate and still be about something slightly different from what you have to decide.
Ask for the case against
If you ask only for the case for, you will usually get only that. A good question asks for both sides, and for the strongest version of the case against, because a weak version is easy to dismiss. Quang's second question did exactly this.
The AI can lay out both cases side by side. The person still has to weigh them against what each choice means for the people affected, and decide which one the evidence supports.
Ask what the answer rests on
Every answer rests on something, such as a set of data or an assumption about who the customers are. A good question asks the AI to say what its answer rests on, and to say what it was not given. ApostlebirdAI worked from last year's transaction data, and its first answer said nothing about how people pay at the counter.
Knowing the basis is a start, but it doesn't check anything. The person still has to open the source, as Quang opened the branch data, and see whether it says what the answer claims.
Ask what would show the answer is wrong
If there's time for only one extra question, make it this one. "What in the data would show that this is wrong?" turns a confident answer into something you can test, because it names a place to look. Quang's own version, what in the data would show which case is right, did the same work. It pointed at how counter payments are made, branch by branch.
The person still has to go and look. They have to find the one claim the decision rests on and check it. Here that claim was "most customers already pay bills in the app". The data supported it in most branches. In three, most counter payments are made in cash, so the claim did not settle the decision there.
What I won't claim
A better question doesn't make the answer right. ApostlebirdAI could have been just as sure, and just as wrong, about the case against. What a better question does is make the answer easier to check. It gives you the other side in writing, and it shows you where to look.
This isn't a template, either. The questions above are about what you need to know before you decide, and the words can be your own.
And the questions don't decide anything. After the best question and the best answer, someone still has to open the data and check the claim that matters. Then they make the decision and tell the people who will carry it out. In this example that was Quang, and the recommendation to the board was his.
I give keynotes, briefings and workshops on this.