Memory Consolidation for Long-Running AI Agents

Memory consolidation converts an append-only history of observations into smaller, reusable records without destroying the evidence needed to correct them. A safe design keeps raw events immutable, makes summaries derived and replaceable, records provenance and confidence, separates user assertions from verified facts, and supports supersession and deletion.

The objective is not for an agent to remember everything. It is to retrieve the minimum relevant, authorized, current context for the next decision.

Separate four kinds of state

Use different stores and retention rules for:

Do not let conversational content rewrite procedural policy. Tool permissions and system rules belong in controlled configuration.

The Generative Agents paper used a memory stream, retrieval, reflection, and planning, and its ablations found those components contributed to the behavior evaluated in its simulation. That is evidence for one research architecture, not proof that unconstrained reflection is safe for production. See Park et al..

MemGPT proposed managing several memory tiers using an operating-system analogy to work beyond a fixed context window. The paper motivates explicit movement between fast context and external storage, rather than treating the entire history as one prompt. See Packer et al..

Keep consolidation derived and traceable

Every consolidated memory should reference its inputs:

type Memory = {
  id: string;
  subjectId: string;
  statement: string;
  kind: "preference" | "fact" | "commitment" | "summary";
  evidenceEventIds: string[];
  confidence: number;
  validFrom: string | null;
  validUntil: string | null;
  status: "active" | "superseded" | "disputed" | "deleted";
  derivedBy: string;
};

The confidence field is application-defined and must be calibrated; a model-generated decimal is not automatically a probability. derivedBy should identify the consolidation prompt, model, rules, and code version.

Never replace raw evidence with its summary during the same transaction. Publish the derived memory only after validating its sources still exist, belong to the same authorized scope, and support the narrower statement.

Consolidate on explicit triggers

Useful triggers include:

• a task reaches a durable completion state;
• an event count or token budget is exceeded;
• repeated observations appear to express one stable preference;
• new evidence contradicts active memory; or
• retention policy requires compaction.

Avoid consolidating every message synchronously. It adds latency and can turn one malicious input into persistent memory before the system has corroborating context.

A consolidation job can propose four operations: create, reinforce, supersede, or dispute. Deletion should remain a policy-controlled operation, not a model preference.

Resolve duplicates and contradictions explicitly

Similarity is only a candidate signal. Two close embeddings may express opposites: “prefers email” and “does not prefer email.” Retrieve possible matches, then compare subject, predicate, polarity, time, source, and authority.

When evidence conflicts:

1. retain both claims and provenance;
2. mark the memory disputed;
3. prefer newer evidence only when recency is a valid rule;
4. ask the user when the distinction affects the task; and
5. never silently merge contradictions into a vague statement.

Commitments and external facts often need authoritative tool evidence. A user saying “the invoice is paid” is an assertion; a verified billing-system result can support a different confidence class.

Implement decay as retrieval policy

Decay should usually reduce retrieval priority, not erase evidence. Compute rank from several signals:

priority = relevance × trust × freshness × utility × policy_weight

This is a conceptual formula, not a calibrated scoring model. Different memory kinds need different time behavior: a lunch preference may remain stable, a current location may expire quickly, and a contractual restriction should be controlled by effective dates rather than generic decay.

Apply the documented deletion and retention rules for the deployment. Map each deletion across raw events, derived memories, vectors, caches, exports, replicas, and future consolidation inputs; confirm any jurisdiction- or contract-specific requirements separately.

Put memory behind a write policy

Before persistence, check:

• Is remembering this information necessary for a defined user benefit?
• Is the source trusted enough for this memory kind?
• Does it contain credentials, sensitive personal data, or third-party data?
• Does it conflict with existing memory?
• What is its expiration or review date?
• Can the user inspect, correct, and delete it?

OWASP’s 2026 memory-security guidance emphasizes that persistent context can carry an attack forward across sessions. Treat every memory write as a privileged state change, not a harmless optimization. See “Memory Is a Feature. It Is Also an Attack Surface”.

Evaluate usefulness and harm together

Measure whether memory improves task success with fewer clarification turns, but also test:

• false-memory insertion;
• stale preference use;
• cross-user and cross-tenant retrieval;
• contradiction recognition;
• provenance resolution;
• correction and deletion completeness;
• malicious instructions embedded in remembered text; and
• performance with memory disabled.

The no-memory baseline matters. If a workflow succeeds with explicit current-state queries, persistent semantic memory may add risk without enough benefit.