Module · M2 · Ground the decision
Why an ungrounded agent is fluently wrong
Lesson 4 of 21 · 7 min
A language model, asked a question, produces the most probable continuation of the text so far. That is the whole mechanism. There is no separate step in which it checks whether it knows the answer, because there is no place in it where knowing and not-knowing are stored differently.
This has one consequence that matters more than all the others: a fabricated fact arrives in exactly the same register as a true one. Same confidence, same tone, same level of specific detail. The model is not lying, and it is not uncertain-but-hiding-it. It has produced the most plausible-looking answer, and plausibility is precisely what makes a wrong one hard to catch.
What it looks like when it happens to you
An agent was asked to escalate a case to the account manager. It escalated it to a colleague, by name, with an email address. Neither exists. The organisation it was working in has a Varun Menon and an Omkar Menon; the agent produced a “Raj Menon”, which is close enough to the real distribution of names in that company to survive any skim.
The invention was not random, and that is the problem. It was drawn from the same distribution as the truth. A fabrication that looked obviously wrong would be harmless — you would catch it. The ones that survive are the ones shaped like the surrounding facts.
Why “prompt it better” is the wrong reflex
The natural response is to write a firmer instruction. Here is what that actually does, measured on one task: an agent was asked to carry an account’s identifier through to a downstream step. Three attempts, each more precise than the last.
| What it was told | What it produced | How the failure behaves |
|---|---|---|
| “copy the id column” | the account’s name | wrong, and obviously wrong — you catch it in the first test |
| “it is a UUID, 36 characters, NOT the name” | 9e4f7c2a-8b3d-4f5a-9d2f-3b7e6a1c2d4f | wrong, and invisible — correctly formed, passes every shape check, and matches no record anywhere in the system |
“copy the id column”
- What it produced
- the account’s name
- How the failure behaves
- wrong, and obviously wrong — you catch it in the first test
“it is a UUID, 36 characters, NOT the name”
- What it produced
9e4f7c2a-8b3d-4f5a-9d2f-3b7e6a1c2d4f- How the failure behaves
- wrong, and invisible — correctly formed, passes every shape check, and matches no record anywhere in the system
Tightening the wording did not make it more accurate. It made the error better camouflaged. The first mistake announces itself. The second one attaches a decision to a record that does not exist, silently, forever. Precision in the instruction bought precision in the format, which is the one thing that was never the problem.
The rule that follows is short and it is the reason module 2 exists: you cannot prompt your way to a fact. An instruction can shape how an answer is expressed. It cannot put information into the model that was not there. The only fix is to hand the fact to it — from a document, or from a record — and to make that handover a step rather than a suggestion.
What grounding does not fix
Worth being precise, because the promise gets oversold. Grounding covers what you put in the corpus, and nothing else. The agent that invented a colleague had a knowledge base attached and was quoting from it accurately at the time. Its policy answers were grounded; its org chart was not, so the org chart is where it made something up.
A practical test you can apply to any agent output. For each fact in the answer, ask where it came from: the input, or a tool result you can point at. Anything left over — a name, a number, an identifier, a date — is a guess wearing a suit. In module 4 this stops being a habit you practise and becomes a node that checks.