AI gives you more information, not answers

There was a stretch of about ten years when being good at Google was a real skill. Two people could sit in front of the same search box, ask the same question, and get completely different results. One typed a full sentence and trawled through pages of near-misses. The other used four well-chosen words and landed on the answer first time. We even had a name for it: Google-fu.

That skill has gone quiet now, because search got better and we got better at it without really noticing. But it is worth remembering what it actually was. It had nothing to do with knowing more than the search engine. It was about asking in a way the tool could act on. You learned which words carried weight, when to be specific, when to drop the filler. You were, in a small way, learning to supply context.

That is the skill back in play with AI, and most of the noise around it misses the point.

We have done this before

The panic about prompting being some new dark art is overblown. Anyone who lived through the search era already has the instinct. You are interrogating a tool to get value out of it, phrasing your request so the thing in front of you can do its job. The mechanics are different and the output is different, but the underlying move is the same one we have made before.

What is different is the part nobody warns you about.

Where the comparison breaks down

When you searched, the interface was honest about being unfinished. It handed you ten blue links and left the judgement to you. Nobody mistook the first result for the truth. You knew you had to read, weigh, and discard. The work of evaluation was right there in front of you, so you did it.

AI removes that friction. You no longer see the rough edges of the process. You ask a question and get back a fluent, confident paragraph that reads like a conclusion. The evaluation did not disappear. It just stopped being visible. And a well-written answer is far harder to be sceptical of than a list of ten links, because it has already done the work of sounding right.

The short version

The model is not telling you the answer. It is giving you a well-written starting point that you still have to check. Treat it like the first page of search results, not the last word.

Why it is always a best guess

It helps to know what the thing is actually doing. A large language model guesses the next likely piece of text, given everything you have said and everything it has seen before. That is the whole trick, and it is very good at it. But “likely” and “correct” are different things, and the model has no built-in way to tell the difference. It writes a wrong answer with the same calm fluency as a right one.

This matters most in our world, because the model cannot see the things that decide whether an answer is any good. It has never opened your client’s OneStream application. It does not know that the consolidation was set up with an unusual currency treatment three years ago, or that one entity gets loaded differently for historical reasons nobody wants to reopen, or that the finance team will reject anything that changes how one board report looks. None of that is in the training data. All of it changes the answer.

Context is the whole game

Here is the difference in practice. Ask a thin question and you get a thin answer, delivered with the same confidence as a good one.

Write me a OneStream business rule to allocate shared overhead.

The model will happily produce something. It will read as plausible. But it will assume a clean model that does not exist: simple entity hierarchies, a single driver, no edge cases, no prior design decisions to respect. It looks like an answer. In practice, it ignores half the things that will make or break it in your environment.

Now give it the constraints you are already working around.

Write me a OneStream business rule to allocate shared overhead from the Corporate entity down to level 0 Operations entities, using headcount from the HR cube as the driver.

Only run for the Forecast scenario (no impact on Actuals), post results to the Allocated account, and ensure the source data remains intact for reporting.

The Operations hierarchy includes mixed-ownership entities, so exclude minority-owned entities from the allocation.

The HR headcount data is stored at a different dimensional intersection (no Entity dimension), so it needs to be mapped via a lookup table.

Do not change any existing allocation logic used for the board reporting packs.

Same model, same five seconds. The second answer comes back shaped like something you can actually work with, because it has to honour the constraints you gave it. You did not get better at the tool by learning a trick; you got better at it by being explicit about what you already knew. That is the search skill returning under a new name, and the query was always the lever.

What you bring that the model cannot

The context

The specifics of this client, this system, this constraint. The model only ever has what you choose to tell it, and the things that matter most are usually the things nobody wrote down.

The verification

Knowing what “right” looks like, and catching the confident wrong answer before it ships. The model cannot grade its own homework. You are the one who knows when the plausible thing is the incorrect thing.

The accountability

The model never signs its name to the deliverable. You do. When the board asks why the numbers moved, “the AI suggested it” is not an answer anyone wants to give.

Guide, do not follow

The most useful way I have found to think about it is as an extremely well-read junior who has never worked here. It has read more documentation than any of us will in a lifetime, and it remembers nothing about the specifics of your engagement. It will give you a confident answer to anything you ask, including the things it has no business being confident about.

It has read about your problem in general; it has never seen yours in particular.

I see this constantly on integration work. The model hands me something that reads as completely correct, built against an interface that behaves differently on the version the client is actually running, or assuming a data structure that is not the one they have. It had no way of knowing; it has never seen this environment. The model is far from useless in these moments, it gets me moving faster every time. But each confident draft still has to meet the real environment, and the environment keeps having opinions the model could not have known about. The progress comes from me steering, not from the model being right.

That is the whole posture. The model is a fast way to get more information in front of you. What you do with it, which parts you keep, which you bin, what you check, what you put your name to, is still the job. It changes the texture of the work. It does not change who is accountable for the work.

A note on where this is heading, because it is heading there quickly. So far I have assumed you are talking to the AI directly, a ChatGPT or a Copilot. More and more it is moving inside the tools themselves. OneStream and Oracle EPM are both building it into the product, where the vendor tries to handle the context for you. That genuinely helps. But the embedded version inherits the same limit: it knows what it has been given and no more, and you are still the one who signs off on the number that comes out the other side.

For consultants, this is worth getting good at, in the same quiet way we got good at search. It is a skill, not a revolution. The people who get the most out of it will not be the ones who trust it the most. They will be the ones who know exactly how much to, and when not to.