AI-generated CRM fields are not a source of truth
A generated summary field is more dangerous than a stale one, because it's fresh, fluent, and it asserts things. The two failure modes, compounding fabrication, vocabulary decay, and the controls that contain them.
On this page
Most advice about grounding CRM AI, including plenty on this site, tells you to synthesize a briefing or summary field onto the record. It's genuinely useful. It's also one of the easiest fields to trust too much, and the reason is worth writing down.
A stale CRM field can take many forms. For example, it might be an
account_health = Green value that reps were expected to maintain but stopped
updating months ago. That is the easy version of the problem: stale fields eventually
look stale. The date is old, the value stopped moving, and someone eventually
notices.
A generated field can be refreshed regularly, read fluently, and make specific assertions. Everything about it can signal reliability except its accuracy. Nothing necessarily prompts anyone to check it.
The two failure modes
Intent gets promoted to fact. Imagine the generator reads "next step: send the pricing proposal" from a call summary and writes a briefing. Two weeks later, something reads that briefing and reports "proposal sent" even though the source only recorded an intended next step. The tense quietly changed somewhere in the middle.
Quiet records read as healthy. Source signals often describe plans and intentions, because that's what call notes and emails contain. A record with no outcomes and plenty of talk can generate a briefing full of momentum even when recent activity does not support that conclusion.
Both are hard to catch precisely because everything else about the field can be correct and current. The generation ran on schedule, the inputs were real, and the prose is clean. Only the claim is wrong.
The tense shift is the one to internalize. Summarizers are good at compression and can be bad at modality. The difference between will send, should send, and sent is one word in the source and an entirely different fact downstream.
Compounding fabrication
This is the failure that makes the others structural rather than occasional.
An agent reads the generated field. It cites the field in an answer. That answer, or another generated field built from the same source, becomes an input to the next generation run. Two hops later there's no path back to a primary record, and every step of the chain reads beautifully.
The generator's output has re-entered the system as evidence.
You can't prevent that with better prompting on the generation side alone, because the problem is on the reading side: nothing told the consumer that this field is different from a field a human typed or a job computed.
The entry that fixes it
Give the generated field its own context entry, marked non-authoritative, with
instructions rather than just a flag. A bare authoritative: false tends to get read
as a mild caveat.
id: F-088
kind: field
title: >
Treat ai_account_briefing as an unverified lead to investigate, never as
evidence for a decision
appliesTo: [Account]
category: authority
status: active
version: 1
alwaysLoad: false
property: ai_account_briefing
object: Account
meaning: >
Model-generated summary of recent account activity. Regenerated nightly from
activity, opportunity, and call-summary records.
source: ai_generated
authoritative: false
writePolicy: read_only
primarySource: false
interpretation:
- "Every statement is a lead to investigate, not a verified fact."
- "Anything load-bearing must be confirmed against activity, opportunity, or transaction records before it is used in a decision."
- "Statements about completed actions are the least reliable. A planned next step is frequently rendered as a finished one."
- "Do not cite this field as a source in an answer. Cite what it led you to."
freshness: "Regenerated nightly. Reflects signals as of the last run, not as of now."
owner: revops
originFailure: "Example failure: briefing reported 'proposal sent' from a note that only recorded 'next step: send proposal'"
testIds: [GQ-13, GQ-24, GQ-30]
updated: "2026-08-29"The line doing the most work is the last interpretation rule. "Don't cite this field, cite what it led you to" converts the field from a source into an index, which is what it actually is.
Vocabulary decay
A slower failure that only shows up after a few months.
A generator that reads prior context to stay consistent can echo retired product names, old system names, and stale segment language indefinitely. Each run can treat the last run's output as background, so the vocabulary outlives the thing it described. You rename a product in March and can still find the old name in generated briefings in October.
One useful instruction in the generation prompt is:
Build only from current signals. Prior context and history are for continuity only, and may not introduce a fact the current data doesn't support.
That single line helps keep prior generated context from quietly becoming a new source of facts.
Controls on the generation side
If you're writing these fields, the pipeline needs a few things that a demo doesn't. The portable implementation guide covers the full set; the ones specific to trusting the output:
Provenance with a timestamp and a version. Every claim should carry where the signal came from, when it was retrieved, and which workflow and context version produced it. A citation without a timestamp isn't verifiable. Six weeks later, "hiring three data engineers" is either a live signal or an artifact and there's no way to tell.
Atomic write-back. A failed generation must never wipe a good prior value. Write the artifact and its timestamp together, and on failure write nothing. The naive version clears the field, calls the model, and writes the result, so a timeout leaves the record worse than before the run.
Append-only history. Keep every generated artifact with its timestamp and what triggered it, and point the live field at the newest. You get "what changed about this account since last month" for free, and the ledger doubles as an audit trail when someone asks where a claim came from.
A recursion guard. Generation triggers on record change and generation writes to the record. Either exclude the writing user from the trigger, or set a flag the trigger checks. Put it in the first node, not the fifth.
Freshness at the point of use
The part most pipelines miss: a briefing generated Monday gets read on Thursday, and by Thursday the deal may have moved stages, the champion may have left, or the ticket that prompted it may have been resolved.
Two ways to handle it, and you want one of them explicitly:
- Regenerate at consume time rather than on a schedule, when the read is infrequent enough to afford it.
- Gate on freshness. If the artifact is older than your threshold, the workflow doesn't proceed until it's refreshed.
Put the threshold in the context repo alongside everything else. It's a business decision, not a constant.
Testing it
Three golden questions cover this, and all three are in the starter set:
- GQ-13: Summarize a record that carries a generated field. Fails if the model repeats the narrative as verified fact.
- GQ-24: Ask an open question where generated and verified content both apply. Fails if it blends them into one confident voice.
- GQ-30: Ask a question answerable only from the generated field. Fails if it answers confidently instead of flagging the limitation.
GQ-30 is the one worth adding first. It's the cleanest test of whether your non-authority instruction actually landed, because there's nothing else for the model to fall back on.
- How to build an AI context layer for your CRM: the concept and full build
- The rule schema:
source: ai_generatedand the rest of the provenance axes - Portable AI context layer: the generation pipeline and its controls
- Golden-question testing: how to keep the non-authority rule working
FAQ
- Why is an AI-generated CRM field more dangerous than a stale one?
- A stale field eventually looks stale: the date is old, the value stopped moving, someone notices. A generated field can be refreshed regularly, read fluently, and make specific assertions. Everything about it can signal reliability except its accuracy, so nothing necessarily prompts anyone to check it. The failure isn't that it's wrong more often; it's that being wrong can leave very little visible trace.
- Should AI-generated fields be marked non-authoritative?
- Yes, always, and with instructions rather than just a flag. The entry should say that every statement is a lead to investigate, that anything load-bearing must be confirmed against activity, opportunity, or transaction records, and that claims about completed actions are the least reliable of all. A bare authoritative: false tends to get read as a mild caveat.
- What is compounding fabrication?
- An agent reads an AI-generated field, cites it as fact in its answer, and that answer becomes the input to the next generated field. Two hops later nothing traces back to a primary record and every step still reads beautifully. It's the reason a generated field needs its own context entry. Without one, the generator's output re-enters the system as evidence.
- Why does generated text keep mentioning products we discontinued?
- Because the generator can read prior context to stay consistent, so each run may treat the last run's output as background and let old vocabulary survive the thing it described. One instruction helps prevent it: build only from current signals, and treat prior context as continuity only, never as a source that can introduce a fact the current data doesn't support.