# AI agent memory: writing, updating, forgetting and verification

> Design AI-agent memory with task state, facts, provenance, contradictions, expiry and deletion. Security checks and research references.

Published: 2026-11-04  
Canonical: https://rootzero.eu/en/research/ai-agent-memory-lifecycle/

Agent memory should make information reusable without losing its origin, scope or date. Storing every message in a vector database does not define how a fact will be corrected, shared or withdrawn. The design needs both a write path and a read path.

[MemGPT](https://arxiv.org/abs/2310.08560) studies memory tiers beyond directly available context. [GAM](https://arxiv.org/html/2511.18423v1) separates historical preservation from on-demand research. These architectures inform choices while leaving application-specific permissions and lifecycle rules to define.

## Separate information with different lifetimes

| Layer | Fictional example | Reuse rule |
| --- | --- | --- |
| Task state | A check is blocked by a missing account | Resume the current task state |
| Document fact | Procedure RZ-41 has revision 2 | Check source and validity |
| Preference | A recipient wants a short summary | Respect scope and permit changes |
| Observation | An HTTP response was obtained at a given time | Preserve artefact and preconditions |

Mixing these layers can turn a presentation preference into business policy or a temporary observation into permanent system state. Explicit types help determine what to verify before reuse.

## Proposed writes need a status

Our proposed workflow stores candidate memories before promoting shared facts. Check provenance, identity, permissions, duplicates and contradictions. Some observations can be recorded immediately with their status; a consequential shared rule needs suitable promotion controls.

```json
{
  "key": "procedure.vpn.window",
  "organisation": "alpha",
  "value": "Tuesday",
  "source": "procedure:RZ-41@2",
  "status": "confirmed",
  "supersedes": "procedure:RZ-41@1"
}
```

This educational record illustrates information missing from the plain statement “VPN maintenance is on Tuesday.” It is not a production implementation.

## Resolve revisions without hiding conflicts

An old procedure says Friday; the new revision says Tuesday. Semantic similarity cannot choose between them. Apply revision and validity rules. Conflicting current sources should remain visible or trigger a decision request.

The last sentence in a conversation is not necessarily authoritative: it may be a question, historical quotation or unapproved proposal. Retain the event and evidence that changed a record’s status.

Expiry can prohibit use as current information while preserving authorised history. Deletion has a different purpose. Define the effects on embeddings, summaries, caches and secondary indexes in either case.

Test by recording a fact, producing a summary and revoking a user’s access. Check that a fresh consultation cannot recover it through the summary or cache. Repeat for deletion and direct identifier access using demonstration data.

## Evaluate memory operations

[MemSkill](https://arxiv.org/abs/2602.02474) treats memory operations as skills whose selection and content can evolve. An operational question follows: who may change a write rule, and how can its effects be observed?

[LongMemEval](https://arxiv.org/abs/2410.10813) distinguishes abilities including temporal reasoning, updating and abstention. Adapt these dimensions to your service. Retrieving an old fact successfully does not establish recognition that it is now outdated.

The [offline example](/lab/rag-demo/rag-demo.zip) provides deterministic revision, expiry and access checks, not an agent-memory implementation. Continue with [context compaction](/en/research/context-engineering-budgets-compaction/) and [RAG security](/en/research/rag-security-injection-memory/) through the [series index](/en/ai-security-guides/).