Most AI project conversations eventually reach the model question.
"Which model should we use?"
It is a fair question. Model choice matters. Some models are faster, cheaper, more capable, better at reasoning, better at long context, better at structured output, or less likely to fall over when handed something messy and real.
But it is rarely the first useful question.
Most businesses do not have a model problem.
They have a grounding problem.
The system does not know enough about the business. Or it knows the wrong things. Or it has access to a pile of documents that disagree with each other in five quiet ways. Or the process around the model is so vague that even a very capable model is left making guesses with excellent posture.
That is where many AI builds start to wobble.
Not because the model is bad.
Because the system is underfed, badly briefed, or pointing at source material that nobody sensible would trust if it were printed out and placed on a desk.
Model-chasing is easier to talk about. Grounding is usually where the work is.
What reliable sources change
Grounding is the difference between "answer from the general internet-shaped soup in your head" and "answer using this approved, relevant, current material".
In practical terms, grounding means giving the AI system access to the right context and designing how it should use that context.
That might include:
- product data
- internal guidance
- policies
- case studies
- pricing rules
- support documents
- previous enquiries
- project notes
- operational workflows
- known escalation rules
The exact source material depends on the job.
An ecommerce assistant needs catalogue data, compatibility information, delivery rules, returns policies, and a clear sense of what it should never invent.
An internal support agent needs process documents, ownership rules, current system information, and clear handover points.
A sales qualification assistant needs offer definitions, good-fit criteria, disqualification signals, tone guidance, and examples of what a useful enquiry summary looks like.
The model is only one part of that system.
The context is where the business lives.
Better models cannot fix poor source material
There is a tempting mistake here.
When the output is poor, people often reach for a better model.
Sometimes that helps. A stronger model may follow instructions better, reason more clearly, or produce cleaner structured output. Useful. We are not pretending the model does not matter. That would be tedious contrarianism, which is its own little industry.
But a better model cannot reliably fix source material that is stale, vague, contradictory, or missing.
If the policy document is out of date, the model may still answer from it.
If the product data is thin, the model may still have to infer too much.
If the internal guidance says three different things in three places, the model now has a small governance problem and no authority to solve it.
If the workflow has no clear escalation rule, the model may confidently decide when it should have handed over.
That is not a model problem.
That is a system design problem.
And system design problems have a habit of surviving model upgrades.
Finding the right source is not automatic
Retrieval-augmented generation sounds impressive enough to make people relax.
That is unfortunate.
Retrieval is useful. It lets a system search a body of source material, pull back relevant chunks, and answer with that material in view. It is often the right pattern for grounded AI.
But retrieval is not a moral force.
It does not automatically know which source is right.
It does not know whether a document is still current unless you design for that.
It does not know that a short policy note from last week should override a detailed process document from 2022 unless the system has a way to understand priority.
It does not make poor source material good.
Retrieval can answer the wrong question beautifully if it retrieves the wrong context.
This is why source quality matters so much.
The boring work around naming, freshness, document structure, permissions, ownership, and removal of stale material is not admin decoration. It is part of the AI product.
Ignore it and you are basically asking the model to rummage through a filing cabinet and hope.
Common failures in source-based AI
Most grounding failures are not dramatic. They are smaller, more annoying, and easier to miss in a demo.
The first is stale context.
The system is pointed at old policies, old product details, old price logic, old service definitions, or old process notes. It answers fluently, which makes the problem worse. A wrong answer delivered smoothly is still wrong. It has just put on a clean shirt.
The second is vague context.
The system has documents, but they are written for humans who already know the business. They rely on shorthand, missing assumptions, and phrases like "the usual process". The model sees words. It does not inherit the office folklore.
The third is conflicting context.
One page says one thing. A PDF says another. A spreadsheet has a third version. The person who knows which one is correct is on holiday or has wisely stopped answering Slack after 6pm.
The fourth is missing boundaries.
The model has enough information to say something, but not enough authority to do something. It needs to know when to answer, when to ask a follow-up question, when to draft, when to escalate, and when to stop.
The fifth is poor chunking.
The material may be good, but it is split badly for retrieval. The system pulls back fragments without the surrounding context needed to answer properly. Looks simple until you have to hand it real inputs.
None of these are solved by asking the model to "be more accurate".
That instruction is not useless, exactly. It is just not a substitute for architecture.