Grounding every draft in real pipeline signal

The fastest way to lose a rep's trust in an AI draft is for them to catch it inventing one detail. After that they read every line as suspect, which costs more time than writing it themselves would have.

Fluent is not the same as true

Language models are optimised to produce text that reads well. Nothing in that objective requires the text to correspond to your pipeline. A model asked to write a follow-up will happily reference a conversation that did not happen, a stakeholder who does not exist, and a timeline nobody agreed to, and it will do so in confident, well-structured prose.

This is not a flaw that better prompting removes. It is what the system does when it lacks the fact and still has to emit a sentence. The fix is not to ask it more nicely. The fix is to make the fact available and to make its absence visible.

Retrieval over your own deals

Before drafting, the relevant signals are pulled off the account: the last conversation and what was actually said in it, the objection still unanswered, the stage the deal is in rather than the stage the rep hopes it is in, who has been in the thread and who has gone quiet. The draft is then assembled from those, and every specific in the output traces to one of them.

The discipline that matters is what happens when the signal is missing. A grounded system with nothing to ground on should produce a shorter, vaguer message, or decline to draft at all. The tempting alternative is to let the model fill the gap fluently, which is precisely how a fabricated detail enters an email that a rep sends to a buyer.

A model that guesses is a liability. A model that can point at the sentence it is working from is something a rep can argue with, which is what makes it usable.

Recency is not the same as relevance

The most common grounding failure is not an empty context, it is a stale one. Retrieval ranks on similarity, and a superseded document is maximally similar to a question about the thing it used to describe. A cancelled pricing thread, a deprecated integration, an objection that was resolved two calls ago: each of these looks like exactly the right context to a similarity search, and each produces a draft that is specific, confident and out of date.

Which is why signals carry the time they were true as well as the time they were recorded, and why a superseded fact is retired rather than deleted. A deleted fact leaves the model free to re-infer it. A retired one is still there, marked as no longer current, and can be excluded deliberately rather than accidentally.

What good looks like from the rep's seat

The test is not whether the draft is impressive. It is whether the rep can read it in fifteen seconds, recognise every specific in it, and send it without a rewrite. When grounding works, the draft is often less polished than an ungrounded one and considerably more sendable, because it says the awkward specific thing the buyer actually raised.

Specific beats fluent. A message that references what was really said gets a reply because it proves someone was listening, and no amount of well-formed prose substitutes for that.

Abstention is the feature nobody asks for

The hardest behaviour to build, and the one that matters most, is declining to answer. A system that produces a confident draft for every request is easy to demo and expensive to trust, because the failure is silent: the rep cannot tell the well-grounded message from the well-written guess by reading it.

So the useful design makes absence loud. No signal on the account should produce a visibly shorter draft, or an explicit refusal, rather than a fluent paragraph assembled from nothing. Reps calibrate quickly once they see the system decline, because a tool that admits ignorance becomes a tool whose confidence means something.

How to check it yourself

There is a simple test any team can run before trusting this. Take an account with almost nothing on it, ask for a follow-up, and read what comes back. If the output is specific, it is inventing, and every other draft it produces is suspect. If the output is thin or absent, the grounding is real.

Run the same test on an account whose situation changed recently, where an old thread has been superseded. A system that quotes the stale thread confidently has a recency problem, and that one is harder to spot because the output is genuinely derived from something real, just no longer true.

Grounding changes what a rep is for

When drafts are reliably grounded, the rep's job shifts away from composition and towards judgement: is this the right moment, is this the right person, is this angle worth spending the relationship on. Those are the decisions that were always the valuable part, and they were being crowded out by the mechanical work of assembling a message from four browser tabs.

It also changes what a bad draft means. An ungrounded system producing a weak message is a prompt problem. A grounded system producing a weak message is usually telling you something true about the account, most often that there is not enough of a relationship there yet to say anything specific. That is useful information rather than a failure, provided the system is honest enough to show it.

Which is the whole argument in one line: the value is not that the machine writes, it is that what it writes can be checked.

• Engineering
• Retrieval
• AI Drafts