Memory Is a Write-Policy Problem: Retention, Provenance and the Cost of Remembering

The asymmetry in memory design

Agent memory stacks are usually evaluated the same way search engines are: recall benchmarks, embedding quality, reranking latency. The write path receives far less attention. Yet every retrieval failure has an upstream cause, and in most production incidents we review, the cause is that something was written that should never have been stored, or was stored without the metadata needed to decide what to do with it later.

Retrieval is benchmarked because it is easy to benchmark. A fixed corpus, a query set, a ranking metric. Ingestion is harder to score because correctness depends on context: the same sentence is a durable preference in one turn and an offhand remark in another. Teams therefore ship ingestion as a thin append call and defer judgement to retrieval time, where the information needed to make that judgement has already been discarded.

The consequences are ordered differently than most teams expect. An agent that over-remembers degrades its privacy posture before it degrades its accuracy. Storing a user's incidental disclosure does not immediately change answer quality; it changes the blast radius of a later breach, a subpoena, a support export or a model-provider log. Accuracy erosion follows more slowly, as stale and contradictory entries compete during retrieval.

Deletion is the clearest symptom. Most memory tooling treats delete as an afterthought — a row removal on a vector store, with no guarantee that the embedding is gone from an index segment, that a summary derived from the entry is gone, or that a downstream cache is invalidated. Where deletion is unsupported, retention becomes accidental rather than chosen.

A write-policy interface

The fix is to make the write path a policy boundary rather than an append. Three properties do most of the work.

Provenance on every write

Every memory entry should carry a provenance record: which conversation turn produced it, which tool call supplied it, which user consent covers it, and which agent identity wrote it. This is not audit decoration. Provenance is what allows a later deletion request to be answered precisely — you can find derived entries, not just the original — and what allows a stale entry to be traced to the turn that introduced it when it starts distorting decisions.

A minimal schema, expressed as a validation step before persistence:

MemoryWrite = {
    "content": str,
    "provenance": {
        "turn_id": str,
        "tool_call_id": str | None,
        "consent_ref": str | None,
        "writer": str,          # agent or component identity
        "written_at": datetime,
    },
    "sensitivity": Literal["public", "internal", "personal", "restricted"],
    "retention": {
        "expires_at": datetime | None,
        "basis": Literal["session", "consent", "contract", "indefinite"],
    },
    "redaction": {
        "state": Literal["none", "applied", "required"],
        "fields": list[str],
    },
}

Writes that fail validation are rejected at the boundary. This is the cheapest place to reject them: the entry has not yet been embedded, indexed, summarised or replicated.

Sensitivity classes with per-class retention

Retention should be a function of class, not a global default. A public fact extracted from documentation and a personal detail volunteered in conversation do not need the same lifetime. Assigning retention per class lets the policy be reviewed once and enforced everywhere, rather than re-litigated in each feature.

The trade-off is real. Fine-grained classes increase the number of decisions a write path must make, and every additional decision is a place where an agent can be wrong. A conservative default — shorter retention, higher sensitivity — reduces exposure but also reduces the agent's ability to recall context that users expect it to remember. There is no setting that avoids this tension; the point is to make the tension explicit and reviewable instead of implicit in an append call.

Redaction and expiry in the schema

Redaction and expiry are usually implemented as periodic jobs that sweep the store. Sweeping is a poor fit for memory because it is retrospective: the entry exists, has been read, may have been summarised, and may have influenced a decision before the sweep runs. Moving both into the schema means the store itself enforces them.

Concretely, expiry can be a predicate evaluated at read time and a compaction trigger at write time, so an expired entry is never returned and is reclaimed on the next pass. Redaction can be a state transition that rewrites the stored content and invalidates derived summaries keyed by the entry's identifier. Neither requires a separate system; both require that the schema anticipated them.

Evaluating memory honestly

Memory evaluation should measure the properties the write policy claims to provide.

Precision of recall, not volume. A memory system that returns more context is not better; it is larger. Measure the fraction of retrieved entries that were relevant to the decision, and the fraction of decisions that would change if a retrieved entry were removed. Volume metrics reward over-remembering, which is the failure mode being addressed.

Behaviour after deletion, not only after insertion. Test suites for memory typically insert, query, assert. They rarely delete, then query, then assert that the deleted content is absent from direct recall, from summaries, and from any cached context. A deletion test that only checks the primary store will pass while derived artefacts retain the content.

Influence of stale entries. Track whether entries past their useful life still affect current outputs. One workable mechanism is a counterfactual probe: re-run a sample of decisions with expired or low-confidence entries masked, and compare. Divergence indicates that retention is doing work that freshness should be doing.

These tests are slower and less satisfying than a recall benchmark, and they produce findings that require policy changes rather than model changes. That is the honest trade-off: write-policy work is upstream, cross-cutting and harder to attribute to a single metric, which is precisely why it is usually deferred until an incident forces it.

What this changes in practice

Treating memory as a write-policy problem shifts where engineering effort goes. The ingestion boundary becomes a validated interface with provenance, sensitivity and retention as first-class fields. Deletion becomes a supported operation with defined semantics for derived data. Evaluation covers the full lifecycle rather than the read path alone.

None of this requires a new memory architecture. It requires deciding, at the moment of storage, what is being stored, on whose behalf, for how long, and how it will be removed. Agents that remember well are not the ones with the largest stores; they are the ones whose stores contain only entries the system can justify keeping.

---

Cover photo: Matheus Bertelli / Pexels.