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 reads prior context to stay consistent, so each run treats the last run's output as background and the vocabulary survives the thing it described. One instruction clears 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.

AI-generated CRM fields are not a source of truth

Q: 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 is refreshed nightly, reads fluently, and makes specific assertions. Everything about it signals reliability except its accuracy, so nothing prompts anyone to check it. The failure isn't that it's wrong more often; it's that being wrong leaves no trace.

Q: 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.

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 the most dangerous field in your CRM, and almost nobody writes down why.

The stale-field example everyone uses (account_health = Green, abandoned last year) is the easy version of the problem. A stale field eventually looks stale. The date is old, the value stopped moving, someone eventually notices.

A generated field is refreshed nightly, reads fluently, and makes specific assertions. Everything about it signals reliability except its accuracy. Nothing prompts anyone to check it.

The two failure modes

Observed in production

Intent gets promoted to fact. The generator reads "next step: send the pricing proposal" off a call summary and writes a briefing. Two weeks later something reads that briefing and reports "proposal sent." Nobody sent anything. The tense quietly changed somewhere in the middle.

Quiet records read as healthy. Source signals mostly describe plans and intentions, because that's what call notes and emails contain. A record with no outcomes and plenty of talk generates a briefing full of momentum. The account has been dead for six weeks.

Both are hard to catch precisely because everything else about the field is correct and current. The generation ran on schedule, the inputs were real, the prose is clean. Only the claim is wrong.

The tense shift is the one to internalize. Summarizers are good at compression and 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.

context/fields/ai_account_briefing.yaml

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: "Briefing reported 'proposal sent' from a call note that said 'next step: send proposal'"
testIds: [GQ-13, GQ-24, GQ-30]
updated: "2026-08-20"

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 will echo retired product names, dead system names, and old segment language indefinitely. Each run treats the last run's output as background, so the vocabulary outlives the thing it described. You rename a product in March and find it in generated briefings in October.

One instruction in the generation prompt clears it:

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 is the difference between a summary field and a museum.

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 moved stages, the champion left, or the ticket that prompted it got 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: an open question where generated and verified content both apply. Fails if it blends them into one confident voice.
GQ-30: 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_generated and 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