Semantic Memory — Patterns

Candidate, then confirmation

Problem. Automatic extraction cannot distinguish a user describing their situation from a user describing a hypothetical, quoting someone else, or stating what they do not want. Written directly, every one of those becomes a standing claim the product will later assert.

Approach. Make extraction produce candidates in a staging state rather than beliefs, and promote a candidate only on a defined signal: the same claim appearing in a second independent turn, the user acting consistently with it, or an explicit confirmation. Candidates are visible to retrieval only as weak context, never as assertions. Because promotion is an event, the rate and the sources of promotion can be measured, and a bad extractor shows up as a spike rather than as a slow drift in answer quality.

Trade-off. Confirmation delays everything, so a genuinely useful claim is unavailable during the conversation in which it was stated, which is exactly when it was most useful. Asking the user to confirm is accurate and makes the product feel like a form, so most teams end up with an implicit signal that is a heuristic in a different costume.

Controlled predicate vocabulary with an escape hatch

Problem. Free-text beliefs accumulate three paraphrases of the same claim, none of which can be found when looking for the others, while a fully typed schema rejects most of what a real conversation produces and loses it entirely.

Approach. Maintain a small vocabulary of predicates that the system actually reasons about — the ones that gate behaviour, feed templates, or must be corrected — and validate those writes strictly. Everything else is written as a free note attached to the same subject, retrievable but never treated as structured. Periodically review which notes recur across many subjects; those are the candidates for promotion into the vocabulary, and the promotion comes with a backfill plan.

Trade-off. The split is a standing judgement call and the boundary moves, so there will be a period where the same kind of claim exists on both sides and queries must check both. A small vocabulary also means the things the system reasons about are decided by engineers in advance, which caps how much the memory can surprise you usefully.

Claims carry their origin and their age

Problem. At retrieval time a claim inferred by a model eighteen months ago is indistinguishable from one the user stated this morning. The model receives both as context and treats them identically, so the agent asserts old guesses with the same confidence as fresh statements.

Approach. Store origin as a closed enumeration — stated by the subject, observed from a system of record, inferred by a model — together with the time it was established and the extractor identity. Carry all of it through to the prompt, rendered as part of the claim rather than as metadata the model never sees. Downstream ranking, conflict resolution, and the agent's own hedging language then all have something to act on, and a faulty extractor is a sweepable cohort.

Trade-off. Rendering origin and age costs tokens on every retrieved claim and makes prompts noisier, and models vary in how reliably they act on the qualifier. Recording the extractor identity also means the memory store now depends on the versioning discipline of whatever wrote to it.

Subject keys resolved before write

Problem. The same entity arrives as "Priya", "P. Raghavan", and an opaque account identifier. Written as three subjects, the store holds three partial belief sets, each of which is retrieved for a different phrasing of the same question.

Approach. Resolve the subject to a stable internal identifier at write time, using the system of record where one exists — an account id, a user id, a CRM key — and store the surface forms as aliases pointing at it. Retrieval resolves the query's subject the same way. When resolution is ambiguous, write the claim against the ambiguous surface form and flag it for resolution rather than guessing, because a claim merged onto the wrong entity is harder to find than one that was never merged.

Trade-off. Resolution requires a system of record, which does not exist for the entities that matter most in open-ended conversation, and a wrong merge contaminates two subjects at once and is difficult to unpick afterwards. The alias table becomes its own thing to maintain, with its own staleness.