An agent memory can be concise, fluent and completely untrustworthy. The danger is greatest when a generated summary presents an interpretation with the tone of a verified fact.
Trustworthy memory does not require eliminating inference. Inference is often where the value lives: noticing a changing priority, connecting two delayed commitments, or identifying a relationship that may need attention. The requirement is to keep inference bounded by evidence, visibly qualified and easy to correct.
Three mechanisms do that work: provenance, uncertainty and correction.
Provenance is a navigable chain
Provenance is more than a citation URL. It is the chain from a memory back to the evidence and transformations that produced it.
For a direct extracted fact, provenance may include the source event, author, timestamp and exact span. For a higher-level conclusion, it may include several source events, an extraction step and the rule or model operation that combined them.
A useful provenance record can answer:
- Which sources support this memory?
- Are they direct statements, quotations or generated summaries?
- When were they observed and effective?
- Which source has authority for this subject?
- Was the memory edited or confirmed by a user?
- Which derived outputs depend on it?
This lineage supports inspection and later correction. Without it, a memory becomes an orphaned sentence.
Not every source should be exposed
Inspectable does not mean indiscriminately visible. A source may contain unrelated private material, access-controlled content or raw workflow state that should not appear in routine retrieval.
The product should separate the ability to verify a claim from the ability to browse an entire source. Depending on authority, an agent might receive:
- a source label and timestamp;
- a bounded supporting excerpt;
- a link requiring the user’s existing permission;
- a statement that evidence exists but is outside the current agent’s visibility.
Provenance must inherit authorization. It should never become a back door around source access controls. See the broader scope principles on security.
Use explicit epistemic types
A practical memory system should label how it knows something. A small vocabulary is better than one generic confidence score.
Explicit fact. Directly stated by an authorized source: “Maya is the executive sponsor.”
Observed behavior. A bounded event: “Maya moved two review meetings this month.”
Extracted commitment. A speech act with operational fields: “Jon will send the rollout plan by Friday.”
User direction. An instruction about system behavior: “Brief me before contacting the wider team.”
Inference or hypothesis. A conclusion supported by evidence but not directly stated: “Executive confidence may be weakening.”
Conflict. Two claims cannot both describe the same state: “CRM lists Maya as decision maker; executive email assigns the decision to Daniel.”
These types help rendering and retrieval. A hypothesis can be useful in an internal briefing but should not be repeated to a customer as if they declared it.
Confidence scores are not explanations
A number such as 0.82 can be useful for ranking or review thresholds. It is a poor user explanation. People need to know why the system is uncertain.
Prefer reasoned qualification:
- identity is uncertain because two people share the name;
- current status is uncertain because the latest two sources conflict;
- preference is weak because it is inferred from one event;
- commitment deadline is uncertain because “next Friday” was parsed across time zones;
- source authority is uncertain because the author’s role changed.
These reasons point toward resolution. A naked score does not.
Keep evidence separate from summaries
Generated summaries are convenient, but they should not recursively become evidence for stronger summaries.
A dangerous loop looks like this:
- A model reads three messages and writes “Maya is unhappy.”
- That summary is stored without source lineage.
- A later agent retrieves it as context and writes “Maya’s dissatisfaction is increasing.”
- The stronger conclusion is stored and repeatedly retrieved.
The system has converted one interpretation into apparent accumulated evidence.
Prevent this by distinguishing primary evidence, derived memory and generated presentation. A derived memory can support retrieval, but any stronger claim should trace through it to the underlying primary sources. Generated display text should usually be ephemeral.
Correction needs several verbs
“Edit” is not enough for a memory system. Different errors require different operations.
Correct. The memory was recorded incorrectly: wrong date, owner or identity.
Supersede. The memory was once true but is no longer current.
Retract. The evidence does not support the claim and it should no longer be used.
Narrow. A broad claim should apply only to a specific context or period.
Split identity. Evidence from two people was combined.
Merge identity. One person was fragmented across records.
Resolve conflict. Competing claims are reconciled, with the basis recorded.
Each operation should preserve a version trail and trigger downstream maintenance.
Corrections must propagate
The most common correction failure is local repair. A user edits a profile field, but stale summaries, embeddings, briefings and relationship edges continue to reflect the old value.
A correction should identify dependencies:
- current-state views;
- derived claims;
- search indexes and caches;
- scheduled or queued briefings;
- identity links;
- evaluation labels where appropriate.
Not every dependency needs synchronous recomputation, but the system should know that it is stale. Otherwise users experience the same error repeatedly and conclude that correction is cosmetic.
The memory-quality page treats correction as an end-to-end behavior for exactly this reason.
Make user feedback precise
A generic thumbs-down is weak supervisory data. A useful correction interface asks what is wrong:
- wrong person;
- outdated;
- unsupported inference;
- wrong source interpretation;
- not relevant to this task;
- should not be in this scope;
- missing important context.
The system can then apply the right operation. “Outdated” may supersede a claim; “wrong person” may initiate an identity split; “not in this scope” may indicate an authorization or retrieval-policy issue rather than a content error.
Feedback should also allow positive confirmation. A user-confirmed memory can be marked as such without pretending the user authored the original evidence.
Render uncertainty where it changes action
Not every caveat belongs in the main response. Overloading a briefing with confidence language can make it unusable. The rendering policy should focus attention on uncertainty that could change the decision.
For example:
- hide minor extraction confidence when several direct sources agree;
- surface identity ambiguity before attributing a sensitive commitment;
- surface conflict about who owns a renewal decision;
- mark a weak hypothesis as a question to verify;
- omit low-impact historical disagreements from a concise meeting brief.
The objective is calibrated action, not maximum disclaimer density.
Evaluate trust behavior directly
Accuracy tests should be joined by trust tests:
- Can a reviewer open the evidence for a consequential claim?
- Does the system distinguish direct statements from inference?
- Does it surface a material contradiction?
- Does a correction update all relevant retrieval surfaces?
- Can an identity split remove contaminated claims?
- Does provenance respect the current authority scope?
- Can the system say “unknown” without inventing a profile?
Synthetic sequences are useful because they can specify exact truth, change and source authority. Real-world review is also necessary to discover which uncertainties users actually care about.
A practical claim contract
A consequential memory object should include, at minimum:
- stable ID and subject;
- claim type and value;
- epistemic type;
- observed and effective time;
- current status;
- source references;
- scope and owner;
- uncertainty reasons;
- conflict or supersession links;
- version and correction history.
This may look heavier than storing a paragraph. It is lighter than debugging an opaque paragraph after it has appeared in five customer workflows.
Trust comes from bounded behavior
Avoid broad claims that a memory system is perfectly accurate, private or hallucination-free. Those claims are neither credible nor useful. Describe the behavior you can inspect:
- sources stay connected to published memory;
- facts and hypotheses remain distinct;
- changing state can supersede old state;
- retrieval is bounded by explicit scope;
- corrections preserve history and propagate.
This is also the right standard for evaluating vendors and internal systems. Ask to see how a wrong identity is split, how a stale preference expires and how an agent reveals the basis of a relationship conclusion.
For the implementation surface beneath an existing agent, see developers. For the operational model, see how it works.
A trustworthy memory is not one that asks users to believe it. It is one that gives them enough evidence and control to decide when they should.