Separating personalization tokens from hallucinated prospect facts before send
Most agencies already know not to send {{first_name}} when it is blank. Fewer treat an AI-written sentence like "Congrats on the Series B" with the same ruthlessness. Merge tokens fail loudly. Hallucinated specifics fail charmingly. Prospects notice the charming ones.
GTM's motion is write from prospect evidence inside a client-isolated workspace. The ops habit that makes that real is a hard line between tokens (structured fields) and claims (sentences that assert facts).
Two different failure modes
Token failure: the field is missing, stale, or mis-mapped. The template shows a blank, a literal {{company}}, or the wrong company after a bad match. Embarrassing, usually obvious in QA.
Claim failure: the model invents or relocates a fact. Funding that did not close. A tool the company does not use. A job the person left last year. It reads confident. It destroys trust.
Prompting "only use real facts" does not fix claim failure if the model never received a verified field to begin with. Gap-filling is how generators behave when context is empty.
Define tokens as resolvable fields only
A personalization token is allowed in a sendable draft only when:
- The field exists on the prospect record
- It has a source and a collected/refreshed timestamp
- Match confidence clears your bar (person <-> company)
- The rendered value is non-empty after normalization
Examples of honest tokens: first name, current company, title, city, verified tech from an enrichment field you store, a job-post URL you saved as evidence.
If the field is absent, the template falls back to a line that needs no fact ("saw your team is hiring for ops roles" only if you have the posting; otherwise a generic true opener).
Define claims as sentences that need evidence packs
Any sentence that asserts something specific about the person or company is a claim. Before send, each claim needs:
- claim text
- source type (structured field, saved URL span, CRM note)
- source reference
- retrieved_at
- verifier result (pass/fail)
Engineering writeups on AI outreach hallucination make the same point in different words: a URL that loads is not the same as a source that supports the sentence. Fact-check scores lag "link works" scores for a reason.
No passing verifier means the sentence is dropped or rewritten to a generic true line. Do not ship "probably fine."
Pre-send gate that agencies can actually run
Whether a human or an automated checker runs it, the gate answers:
- Did every token resolve?
- Does every remaining specific claim have a verified evidence row?
- Are evidence timestamps fresh enough for this campaign's rule?
- Did the draft introduce new proper nouns that are not in the evidence pack?
If step 4 fails, the model snuck in an ungrounded specific. Block or strip.
Tools that require an evidence pack for QA are pointing at the right design. If you cannot show the pack, you cannot validate the claim. Scoring "specificity" without citations just teaches models to stuff fake detail.
What belongs in human QA vs automated QA
Automate token resolution, empty-field checks, and "proper noun not in evidence" scans. Those are cheap and objective.
Keep humans on edge cases: sensitive industries, executive-level accounts, humor that might misread, and any claim that passed a weak verifier but still feels off. Human QA gates at agency scale still matter. They should not be the only place you notice a blank first name.
Client workspace rules that prevent cross-contamination
Because agencies juggle many ICPs:
- Evidence packs stay inside the client workspace
- Voice briefs do not authorize inventing customer logos or metrics
- Provenance on fields survives into the draft audit trail
- Suppression and compliance gates still run after copy QA
A beautiful personalized line that violates unsubscribe rules is still a failed send.
Operator checklist
- Template tokens documented with fallback lines
- Enrichment fields tagged verified vs inferred
- Claim verifier required for any non-token specific
- Stale-evidence threshold set per campaign
- Sample audit weekly: 10 random drafts checked against packs
- Block path when evidence insufficient (no guessing)
Where GTM fits
GTM is AI outbound that books conversations by finding, qualifying, writing from evidence, and sending inside isolated client workspaces with compliance always on. Separating tokens from claims is how writing from evidence stays honest when volume rises.
If that is the motion you want: trygtm.com/waitlist.