How it works
Memory provenance attaches lineage to information as it enters and changes within agent memory. The memory value is only one part of the record. The harness also preserves facts needed to interpret that value: where it came from, when it was acquired, which actor wrote it, how it was transformed, and what scope or authority applies.
A practical provenance path follows the memory lifecycle:
- A tool result, operator statement, model conclusion, or system event enters the harness.
- The harness assigns a source identity and records acquisition context.
- Any filtering, summarization, merging, or compaction creates a derived record linked to its inputs.
- Retrieval returns the value together with the provenance fields needed by policy and evaluation code.
- Before consequential use, the harness checks freshness, authority, scope, and revocation state.
The important property is continuity. A summary should not lose its connection to the tool outputs it summarizes. A merged preference should identify the records and conflict rule that produced it. An operator correction should supersede the affected state without erasing the earlier history.
Provenance does not prove that information is true. It makes the basis of trust inspectable. That distinction lets the harness apply different controls to first-party state, retrieved documents, model-generated inferences, and unverified external content.
Why it matters in an agent harness
Agent memory converts past outputs into future inputs. Without provenance, an unsupported inference can become durable state and later appear indistinguishable from an operator instruction or authoritative tool result. The model may then act consistently while resting on a false premise. The failure becomes harder to detect because each later step sees only the remembered value, not how it entered the system.
Provenance gives the harness a control surface around that inheritance. Retrieval policy can exclude expired records, quarantine information derived from untrusted content, or require renewed evidence before a high-impact action. Authorization checks can distinguish a remembered request from a still-valid grant of authority. An instruction having existed in a transcript does not mean it remains permission to act.
It also improves reversibility. When an incorrect memory item is discovered, lineage identifies which summaries, plans, and merged records depend on it. The harness can invalidate that branch or reconstruct state from unaffected inputs. Without dependency information, correction often means clearing all memory or accepting unknown contamination.
Observability improves for the same reason. A trace can explain not only what the agent retrieved but why that item was eligible for retrieval. Evaluators can test whether decisions depend on permitted sources, whether compaction preserves attribution, and whether stale state changes outcomes. This turns memory behavior from an opaque model-context effect into something the surrounding system can inspect.
Provenance carries costs. Records require storage, stable identifiers, propagation rules, and retention decisions. Derived lineage can grow quickly. The right response is bounded detail, not abandonment: preserve the fields needed to reconstruct authority and transformation, then compact payloads separately from their lineage.
Memory Provenance vs Audit Trail
The two overlap, but they answer different operating questions. Memory provenance explains the ancestry and eligibility of retained information. An audit trail records events and actions over time. A harness often needs both.
| Concern | Memory provenance | Audit trail |
|---|---|---|
| Primary question | Why is this remembered value trusted or usable? | What happened during execution? |
| Unit of interest | A memory item and its dependencies | An event, decision, or action |
| Main control use | Retrieval, invalidation, authority, and freshness | Investigation, accountability, and replay |
| Transformation handling | Links derived state to source state | Records that a transformation occurred |
| Typical failure if absent | Contaminated or stale state silently influences later work | Operators cannot reconstruct the execution sequence |
An execution journal may show that a summary was written. Provenance identifies the records summarized, the transformation that produced it, and the policy under which it remains valid. Recording the event alone is not enough when later decisions depend on the resulting state.
The Rifty take
We treat memory as evidence-bearing state, not as a convenient bag of context. We accept additional metadata and retention complexity because unattributed memory weakens control precisely when a run becomes long, distributed, or difficult to inspect. When lineage cannot be preserved, the boundary should be visible and the affected state should lose authority rather than inherit trust by default.
Implementation checks
- Give every retained item a stable identity that survives retrieval and compaction.
- Record the source, acquisition time, writing actor or process, and applicable scope.
- Represent model conclusions as derived state, not as equivalent to source evidence.
- Link summaries, merges, and extracted facts to their input records and transformation method.
- Define how corrections supersede prior state without deleting the historical relationship.
- Make unknown origin an explicit status. Do not manufacture lineage for legacy memory.
- Check freshness and revocation before using memory for consequential actions.
- Keep remembered instructions separate from current authorization and permission state.
- Test whether untrusted tool content can become durable, high-authority memory.
- Verify that compaction reduces payload size without severing provenance links.
- Expose provenance in traces so operators can inspect why a retrieved item affected a decision.
- Support targeted invalidation of derived records when a source becomes false, stale, or unauthorized.
Frequently asked questions
What metadata should a memory provenance record contain?
At minimum, store the source identity, acquisition time, writing actor or process, transformation history, applicable scope, and a stable reference to the underlying evidence. Add expiry or revocation state when freshness matters. The exact schema may vary, but the harness must be able to explain why a memory item is eligible for use.
Does memory provenance require retaining every raw source?
No. Provenance requires a durable path back to supporting evidence, not necessarily unlimited duplication of every source. Retain enough immutable identity, relevant excerpts or hashes, transformation records, and access metadata to verify use later. If the source can disappear or change, the retention policy must account for that risk explicitly.
How should provenance behave during context compaction?
Compaction should preserve provenance links even when it replaces detailed conversation or tool output with a summary. The summary becomes a new derived memory item whose record points to its inputs and transformation. If compaction severs that lineage, the harness can no longer distinguish supported state from an unsupported compression artifact.
Can memory provenance prevent prompt injection or tool poisoning?
Memory provenance does not make untrusted content safe. It gives policy code the facts needed to quarantine, discount, or forbid content from particular sources and transformations. Prompt-injected text remains hostile even when perfectly attributed. Provenance supports containment, while sanitization, permissions, and deterministic checks enforce the boundary.
How should a harness handle legacy memory with no provenance?
Treat legacy entries as unknown-origin state rather than assigning plausible metadata after the fact. The harness can restrict them to low-risk uses, require revalidation before consequential actions, or rebuild them from authoritative sources. A visible unknown status is operationally useful; fabricated lineage creates false confidence and weakens later audits.