AI, usefully · 4 min read · Sep 28, 2026

Before you ask AI for an answer, ask what it can see

A product manager opens an AI assistant on Monday morning and asks, “Why did signups fall last week?”

The assistant offers a tidy explanation: perhaps a campaign ended, a new onboarding screen created friction, or weekend traffic changed. Each possibility sounds reasonable. None answers the question unless the assistant has seen the signup data—and even then, a drop in signups does not reveal its cause by itself.

This is the first habit I would teach anyone using AI for work: before judging an answer, find out what the assistant had available when it produced it.

Three places an answer can come from

TrainingPatterns learned beforehand can help explain concepts and suggest possibilities.
What you provideA pasted table, uploaded report or metric definition gives the assistant specific material to examine.
Connected toolsPermitted search, files, queries or applications can supply outside information when available.

An AI assistant may draw on patterns learned during training. That makes it useful for explaining concepts, suggesting approaches and helping you think through possibilities. It does not give the assistant a live view of your product or the world. OpenAI notes that a model can produce confident, incorrect answers. Read its explanation of model errors.

It can also work with information you supply: a table pasted into the conversation, an uploaded report, or a definition such as “signup means a verified account, counted by creation date.” Now it has something specific to examine. You still need to check whether that material is complete and whether it interpreted it correctly.

Finally, some assistants can use tools to search the web, read permitted files, run a query or call an application. Tool access depends on what is connected and allowed in that particular conversation or product. It should never be assumed from the assistant’s confident tone. OpenAI describes external data and functions as tools; Google describes search grounding as a way to bring current results into a model response.

These are different kinds of access. A model describing what usually causes signup declines is doing a different job from one that queried your signup events.

Give the question something to stand on

Suppose the PM provides a weekly report:

The assistant can calculate a 25% decline. It can point out that the campaign and screen change deserve investigation. It cannot tell which caused the decline from these four facts.

Maybe the campaign accounted for most of the missing visitors. Maybe the new screen affected conversion. Perhaps a tracking change altered the count. More than one explanation could be true.

A useful next response would be a short investigation plan: compare traffic by source, check conversion before and after the screen launch, confirm the signup definition stayed stable, and look for missing events. That moves the team closer to an answer without pretending the answer has already been found.

Ask for the boundary of the answer

Here is a prompt you can reuse with a report, article or dataset you are permitted to share:

Using only the material I provided, tell me:
1. What we can directly observe.
2. What you calculated, with the inputs and method.
3. What you are inferring.
4. What information is missing before we can answer the original question.

Quote or identify the part of the source behind each important claim. If a claim needs current information or access to another system, tell me what you would need to check. Do not present a possible cause as an established one.

The prompt does not make the model infallible. It makes its claims easier to inspect.

For the signup example, I would check the 120 and 90 against the original report, recalculate the percentage, and confirm that “verified signup” means the same thing in both weeks. I would also check whether the report includes late-arriving records before drawing a conclusion from the latest week.

When searching helps—and when it doesn’t

A web search can establish a current public fact, such as whether a tool changed its pricing or a restaurant changed its opening hours. Search results still need to be opened and checked; a citation beside a sentence does not prove the sentence follows from the page.

Searching the web will not explain a private signup decline. That requires access to the right internal evidence. And giving an assistant access to a dashboard is only useful if it understands the metric, the date range and what the dashboard leaves out.

This distinction is easy to lose because the final answer appears in the same chat window either way. The writing may look equally polished whether it came from a general pattern, a supplied document or a query against live data.

Try this

Take one question you recently asked AI. Before reading its answer again, write down what it could actually see at the time.

Then mark each factual sentence as supported by the supplied material, supported by a source or tool result, or still an inference. Open one cited source and check the claim yourself. If the question matters, ask what additional evidence would change your conclusion.

That small pause is useful well beyond AI. It is the same question good analysts ask of any compelling explanation: What did we observe, and what are we filling in?