Making an agent answer only what it can prove

Every other failure an email agent has is recoverable. A stiff sentence, an unnecessary escalation, a slow reply: none of these cost you much. The one that does is a confident, specific, false statement, because the customer acts on it, and by the time anyone notices they have missed a deadline or shipped something to the wrong address.

5 August 2026 · 5 min read

Grounding is the discipline that prevents it, and it is mostly mechanical rather than clever.

The rule#

Every factual claim in a reply must trace to something the agent read in this run. Not something it knows, not something that is usually true, not something it inferred from the customer's phrasing. A tool result, a retrieved passage, or a message in the thread.

When it cannot, the agent does not soften the claim or hedge it. It escalates, per the trigger in the system prompt for an email agent.

That last part is what makes the rule work. A model told "only say what you can source" without an alternative will still produce something, because producing something is what it does. Give it a legitimate exit and the exit gets used.

What counts as a source#

The last row is worth staring at. "Should be fine" is a claim, and it is the kind that ends up quoted back at you. Reassurance without a source is the most common ungrounded output, and the hardest to catch, because it reads as helpfulness rather than as an error.

Make sources checkable#

A rule you cannot verify is a preference. Two design choices make it enforceable.

Tools return structure, not prose. A tool result with fields can be traced; a paragraph can only be paraphrased, per designing the tools your email agent calls.

The decision step names its sources. Have the model return the claim and the source id together, then check in your own code that every claim has one before sending.

// The model returns claims with sources, and your code refuses ungrounded ones.
const decision = await decide(thread, contact, retrieved);

if (decision.claims.some((c) => !c.source)) {
  return escalate(thread, 'ungrounded claim');
}
await mail.replyAll(messageId, decision.body);

That check is a few lines and it converts grounding from an instruction into a gate. It also produces a metric for free, since counting how often it fires tells you whether the agent's remit matches what it can actually source.

Retrieval that helps rather than hurts#

Most grounding failures in practice are retrieval failures wearing a different hat: the passage was not found, or the wrong one was, and the model filled the gap.

Three habits that matter more than the choice of retrieval stack.

Retrieve before deciding, not after. A model asked to answer and then justify will justify whatever it said.

Pass passages, not the whole corpus. More context is not better here; it dilutes and it costs, per sending the model less than you think it needs.

Return "not found" honestly. A retrieval layer that always returns its best match, however weak, is a machine for producing confident wrong answers. A relevance floor with an explicit empty result is what lets the agent escalate correctly.

Citing to the customer, or not#

Internal traceability is non-negotiable. Whether the reply itself carries a link is a product decision, and the answer differs by context.

Cite when the customer benefits from the source: policy questions, how-to answers, anything they might need to re-read or forward to a colleague. A link to the help article is genuinely useful and it teaches people where answers live.

Do not cite when it reads as evasion: order status, account state, anything the customer expects you to simply know. "According to our records" is filler when the whole message is your records.

The failure to avoid is a reply that is more citation than answer. Lead with the fact, add the link where it helps, and never make someone click to find out what happened.

The uncertainty case#

Some questions have an answer that is genuinely uncertain, and the honest reply says so. That is different from an ungrounded claim: "I do not have a confirmed delivery date, the carrier last scanned it in Rotterdam on Tuesday" is grounded, useful, and honest about what is not known.

Teach that shape explicitly, because a model's instinct is either false confidence or unhelpful vagueness. The good version states what is known, names what is not, and says what happens next.

Measuring it#

Two numbers, both defined in evaluating an email agent.

Correction rate is the outcome measure: how often a human had to follow up and fix a claim. Anything above a couple of percent means grounding is too loose, and no amount of tone work will fix it.

Ungrounded escalation rate is the leading indicator: how often your check fired before sending. Rising means the agent is being asked questions it cannot source, which is a remit problem rather than a model problem, and the fix is documentation or a tool rather than a prompt.

The weekly read is where you see the ones both numbers miss, per the weekly half hour that keeps an agent honest.

Questions#

What does grounding mean for an email agent?

Every factual claim in a reply traces to something the agent read in that run: a tool result, a retrieved passage, or a message in the thread. Anything else escalates.

Why does the agent need an escalation path for this?

Because a model told only to avoid unsourced claims will still produce something. A legitimate exit is what makes the rule survive contact with a hard question.

How do I enforce it rather than request it?

Have the decision step return claims with source ids, and refuse to send in your own code when any claim lacks one. That turns an instruction into a gate and gives you a metric.

What is the most common ungrounded output?

Reassurance. "That should be fine" is a claim with no source, and it reads as helpfulness rather than error, which is why it survives review.

Should replies include citations?

When the source helps the customer, such as policy or how-to answers. Not for account state, where "according to our records" is filler and slightly evasive.

What if the answer is genuinely uncertain?

Say what is known, name what is not, and state what happens next. That is grounded and honest, and it is different from hedging an invented claim.