Why AI sales emails make things up, and how to stop it

AI sales emails make things up because language models are trained and graded in ways that reward a confident guess over an admission of uncertainty. A better prompt does not change that. What changes it is a deterministic checker that runs after the model writes: every factual sentence must cite a saved quote from a page that was actually read, and any sentence that cannot is deleted before a person sees the draft.

The most damaging sentence in an AI-written sales email is usually the friendliest one. Congratulations on the funding round. Loved your talk at the conference. Great to see the team has grown to forty people. Each one reads like research. Each one is also a claim about the reader's own company, which makes the reader the one person guaranteed to know whether it is true.

We built Snaut around a rule that costs us volume and occasionally costs us whole drafts: if a sentence states a fact about a company, it has to point to the exact words on a page we saved, and code, not a model, checks that the words are there. This article explains why we think that rule is necessary, what it catches, and, just as important, what it cannot catch.

What a made-up sentence looks like in outreach

A hallucination in a chat window is an annoyance. You notice the wrong answer, you ask again, and the conversation moves on. A hallucination in outreach is different. The reader did not ask for the message, owes the sender nothing, and has every reason to read the first line skeptically. One false detail ends the conversation, and it often ends it with a spam report.

These are the patterns that appear most often when a model is asked to personalize messages for companies it knows little about:

None of these requires a broken model. They are what a capable model does when it is asked to be specific and given less information than the request assumes. That distinction matters, because it means the fix is not waiting for a smarter model. It is changing what the system accepts as output.

Why language models make things up

In September 2025, OpenAI published research on exactly this question. The researchers define hallucinations as "plausible but false statements generated by language models," and their central argument is about incentives: language models hallucinate "because standard training and evaluation procedures reward guessing over acknowledging uncertainty." A test that only counts right answers gives a guess some chance of points and an honest "I don't know" none, so systems tuned against those tests learn to guess.

The same article shows what that looks like in numbers. On the SimpleQA benchmark, OpenAI's older o4-mini model abstained on 1% of questions, answered 24% correctly and got 75% wrong. The newer gpt-5-thinking-mini abstained on 52%, answered 22% correctly and got 26% wrong. Accuracy was almost the same. The error rate was roughly a third as high, and the difference came from the model's willingness to say it did not know.

The researchers also explain which facts are most at risk. Spelling and grammar follow consistent patterns, so models stop making those mistakes as they grow. But "arbitrary low-frequency facts, like a pet's birthday, cannot be predicted from patterns alone and hence lead to hallucinations." Read that sentence with sales outreach in mind. A specific company's headcount, its latest hire, the date it opened a second location and the name of its operations lead are all arbitrary, low-frequency facts. Personalized outreach asks a model for precisely the category of fact it is worst at.

Stanford researchers measured a related failure in a domain where precision matters as much as it does in a sales email. Testing more than 200,000 queries against each of GPT-3.5, Llama 2 and PaLM 2, they found hallucination rates from 69% to 88% on specific legal questions, and at least 75% when models were asked about a court's core ruling. Those were 2023 models and newer ones do better, so the exact rates should not be applied to today's systems. Two other findings have aged less: the models were overconfident regardless of accuracy, and they showed what the authors call contra-factual bias, "the tendency to assume that a factual premise in a query is true, even if it is flatly wrong."

Contra-factual bias is the quiet danger in outreach. A prompt that says "write about their recent expansion" contains a premise. If the expansion is not real, a model that tends to accept premises will describe it anyway, fluently and in detail.

OpenAI's article also offers the hopeful half of the argument: hallucinations are not inevitable, "because language models can abstain when uncertain." We agree, with one practical addition. In a product, abstention cannot be left to the model's judgment alone. It has to be enforced by the system around the model, which is what the rest of this article describes.

Why outreach is the worst place for a guess

The reader knows the truth

Most hallucinations go unnoticed because the person reading them does not know the right answer. Outreach reverses that. The message is about the reader's own company, so the one person reading it is the world's leading expert on whether it is correct. An invented compliment is not a small error to them. It is proof that nobody looked.

There is no correction loop

In a chat, a wrong answer gets a follow-up question. In outreach, a wrong first line gets deleted, and the sender never learns which sentence did it. The system cannot improve from feedback it never receives, which is why prevention has to happen before sending rather than after.

Scale multiplies errors

A person writing ten emails might make one careless mistake a month. A system writing hundreds a day makes the same kind of mistake at the same rate on every message, and nobody reads them all. The arithmetic is simple. If one message in twenty carried an invented detail, a thousand messages would put that detail in front of fifty people, each of them a potential customer who now associates your name with something false.

The law does not care who wrote it

When the U.S. Federal Trade Commission announced its Operation AI Comply cases in September 2024, the agency's chair said that the actions "make clear that there is no AI exemption from the laws on the books." One of those cases concerned DoNotPay, which, according to the FTC's complaint, did not test whether its AI's output matched the level of a human lawyer. The company agreed to a proposed order requiring it to pay $193,000.

Commercial email has its own rules. The FTC's CAN-SPAM compliance guide prohibits deceptive subject lines and notes that email making misleading claims about products or services may also fall under laws against deceptive advertising, such as Section 5 of the FTC Act. A model inventing a result you never achieved is writing exactly that kind of claim, in your name.

A Canadian tribunal decision from 2024 makes the ownership point plainly. In Moffatt v. Air Canada, the airline argued it should not be held responsible for incorrect information its website chatbot gave a customer. The tribunal disagreed, writing: "It makes no difference whether the information comes from a static page or a chatbot." The award was $812.02 in total, small in money and large in principle. If software says it on your behalf, you said it.

Why a better prompt does not fix it

The instinct is to add a line to the prompt: only use facts from the research, never invent numbers, do not make assumptions. That instruction helps, and it is not a control. A prompt is a request to a probabilistic system. The same request can be honored ninety-nine times and ignored the hundredth, and nothing in the output marks which time it was.

Retrieval helps more. The retrieval-augmented generation approach, introduced by Lewis and colleagues in 2020, gives the model relevant documents at the moment it writes, and it is the reason modern assistants can discuss pages they have just read. But retrieval changes what the model sees, not what it is allowed to say. Nothing in the architecture forces every generated sentence to come from the retrieved passage, so a model can still blend what it read with what it assumes.

Asking a second model to review the first has the same weakness one level up. A reviewer model is better than none, but it fails in the same way the writer does: it can be confidently wrong about whether a claim is supported.

Security practitioners reached the same conclusion for a related problem. In its guidance on prompt injection, the OWASP Gen AI Security Project recommends that systems "specify clear output formats, request detailed reasoning and source citations, and use deterministic code to validate adherence to these formats." The principle generalizes. When the cost of an error is high, the last check should be one that behaves the same way every time.

A prompt asks the model to be honest. A checker makes dishonesty impossible to ship.

The alternative: every sentence declares what it is

Snaut's writer does not produce a block of text. It produces a list of sentences, and each sentence declares its type and, where the type requires it, the evidence it relies on. Code then judges every sentence against the rules for its type. There are four types.

FACT: a quote you can open

Every piece of evidence Snaut saves has the page address, a snapshot of the page text as it was read, the exact quote, the date it was captured and the date it expires. When the writer marks a sentence as a FACT, it must name the evidence it relies on. The checker then confirms that the quote appears in the snapshot. The comparison is literal, with only whitespace normalized. A paraphrase that a person would accept as close enough fails, on purpose, because close enough is how invented details get in.

The checker also confirms that the evidence belongs to the company the email is addressed to. A model that has read ten companies' pages in one session can attribute one company's hiring post to another. With the account check, that error is not merely unlikely. It cannot be sent.

INFERENCE: honest about being a guess

Outreach needs some interpretation. Two open dispatcher roles may mean the routing queue is behind, and saying so is what makes a message useful rather than a list of observations. Snaut allows that, under two conditions. The sentence must carry a hedge word, so the reader can see it is a reading and not a claim. And it cannot introduce a capitalized name or an acronym that does not appear in the evidence it cites. That second rule catches a specific failure: an inference that smuggles in a new fact.

Given a careers page that lists two dispatcher roles, "That may mean routing is taking longer than the team would like" passes. "That may mean your TMS cannot keep up" fails, because nothing the company published mentions a TMS. The hedge does not license the model to name things it never read. The check is deliberately blunt: it would rather remove a harmless capitalized word than let an invented one through.

Numbers: the strictest rule

Numbers get their own check, because a number is the detail a reader is most likely to verify and the detail a model is most likely to invent. Any number in any sentence must appear in the text that sentence cites. For an OFFER, the number must appear in a piece of proof you entered with a source address. This applies to questions too: "Worth 15 minutes next week?" is removed unless the number 15 appears in what it cites, which is one reason Snaut's questions rarely contain numbers.

QUESTION: one, and last

An email with three questions gets none of them answered. The checker keeps only the last question, removes any earlier ones, and requires that the question be the final sentence. It must be a single sentence of 20 words or fewer. The shape is deliberately narrow: one easy thing to answer.

A draft before and after the checker

Here is an illustrative example. The company and the evidence are invented for this article. Assume a regional freight company's careers page says: "We are hiring two Dispatch Coordinators to support our growing regional routes." The sender runs an overnight dispatch service, and that offer is defined in their workspace. A model writes nine sentences:

What survives is four sentences and about fifty words:

Your careers page lists two Dispatch Coordinator roles for your regional routes.
That may mean routing is taking longer than the team would like.
We run overnight dispatch for regional carriers, so the queue is covered while you hire.
Would it help to see how that works for a team your size?

Two things are worth noticing. First, the surviving email is better than the original, not just safer: shorter, specific, and with one clear question. The removed sentences were mostly the ones a reader would have found irritating. Second, nothing was silently rewritten. The removed sentences stay visible in review, struck through, each with its reason, so the person approving can see what the model tried to say and why it was cut.

The rules around the sentences

The checker also enforces rules about the email as a whole:

• Banned phrases. "I hope this finds you well," "quick question," "as we discussed," "just bumping this," "guarantee," "world-class," "best-in-class" and "industry-leading" are removed wherever they appear. A workspace can add its own.
• Length. A first email keeps between three and six sentences and no more than 90 words after the cuts.
• At least one fact. An email with no surviving FACT fails, because an email with nothing true and specific in it is the generic message this whole system exists to prevent.
• Subject lines. Two to six words, and never a fake "Re:" that pretends a conversation already happened.
• Links. A link is allowed only if it is on the workspace's allowlist.
• Re-checked at send time. Approval is not the last check. The checker runs again when the email is about to leave, and the send is blocked if any cited evidence has expired in the meantime.

If the kept sentences do not form a valid email, the draft fails and has to be regenerated. It is never padded back out with filler to reach the minimum, and it cannot be sent as it is.

Why evidence expires

A fact can be true when it was read and false when it is sent. A job post gets filled. A promotion ends. A page is rewritten. So Snaut gives every piece of evidence an expiry date set by what kind of page it came from: 14 days for careers pages and job boards, because roles move fast, and 30 days for news, press releases, reviews, help-center articles and ordinary website pages.

The expiry is enforced twice. When the draft is written, the checker refuses evidence that has already expired. When the email is about to be sent, the send gate checks again. A draft approved on the thirteenth day of a job post's evidence and sent on the fifteenth does not go out. It goes back for a fresh look, which is the correct outcome, because "I saw you're hiring" is only a compliment while it is true.

What the checker cannot do

A system that claims to eliminate errors deserves the same skepticism as a model that claims to know a company's headcount. These are the limits we know about:

• It cannot tell whether the source page is true. If a company's website is out of date, a verbatim quote of it is out of date too. Expiry reduces this risk without removing it.
• It cannot judge context. A quote can be word for word on the page and still be used in a way the page did not intend.
• It cannot make an inference correct. The hedge makes an inference honest about being a guess. The guess can still be wrong.
• It cannot judge tone or relevance. A message can pass every rule and still not be worth sending to that person.
• It cannot make thin research rich. If the research found nothing specific, the honest output is no message, and the checker will produce exactly that.

That is why the checker and the approval step are both required. The checker removes what cannot be proven. The person removes what should not be said. By default, every first message in Snaut waits in Needs you for that second judgment. A play can earn the right to send first messages on its own only from a clean record of at least 50 approved sends with fewer than 10% edited, and even then the checker still runs on every message and anything unusual still comes to you.

What the rule costs, and why we accept it

Strict grounding has real costs. Drafts are shorter. Some companies get no draft at all, because nothing specific and current could be found. A model that is allowed to improvise produces more emails per hour, and some of those improvised emails would have been fine.

We accept the trade because of where the costs land. A missing email costs one opportunity this week. A false email costs the opportunity, the sender's reputation with that reader, and, through spam reports, some of the sender's ability to reach the inbox at all. We explain that last mechanism in our guide to cold email deliverability. And the improvised emails that would have been fine are indistinguishable, from the inside, from the ones that would have embarrassed you.

There is also a simple practical test we use internally, and it works without any software. For every sentence that claims something, write down where you read it. If you cannot, cut the sentence. If the message is empty after the cuts, the research was not done. Our guide to writing a first message that gets replies applies the same test to messages written by hand.

How to test any AI writing tool for this

Whether you use Snaut or anything else, these questions separate tools that control invention from tools that hope to avoid it. We cover the wider buying decision in our guide to AI SDRs, cold email tools and lead databases.

1. Pick any factual sentence in a sample draft and ask to see the page and the exact words it came from. If the answer is a summary rather than a quote, the tool cannot prove the sentence.
2. Ask what happens when the model writes a fact with no source. Flagged, rewritten and deleted are three very different answers.
3. Ask whether the final check is code or another model. A model checking a model shares its failure mode.
4. Ask whether numbers are checked separately against the source text. Numbers are the most common invention and the easiest to verify.
5. Ask whether evidence expires, and whether the draft is checked again at send time or only when it was written.
6. Ask whether evidence from one company can end up in a message to another.
7. Ask whether a person approves before anything is sent, and whether they can see what the system removed.
8. Ask whether the agent ever presents itself as a human. Snaut never does.

A vendor that answers all eight clearly has thought about the problem. A vendor that answers with accuracy percentages and no mechanism has measured something, but has not explained what stops the next error.

Where this fits in finding customers

Grounded writing is the last step of a longer process, and it only works if the earlier steps produce real evidence to ground on. That means watching for buying signals that actually mean something, saving each one with its quote and date, and drafting only when a signal is current. Our overview of how an AI agent finds customers walks through the full loop, from describing the buyer to the draft that waits for your approval.

The validator rules described here are Snaut's production rules as of October 2026. The example company and quotes in the walkthrough are invented for illustration. Figures attributed to OpenAI, Stanford, the FTC and the Civil Resolution Tribunal are from the sources listed below.