Memory and State Management

Memory and State Management

Long-term Memory

Long term memory

14 of 69 in this book · 3 min read

What it is

The tier that keeps what an agent has learned across sessions, deployments, and model changes: a store with its own schema, its own write path, and its own lifecycle, independent of any one conversation that contributed to it. The substance of this capability is the set of decisions that make persistence safe — what is allowed to be written, under which partition key, in what shape, with what durability, and what the organisation has committed to about how long it stays.

Why it is not a fourth memory type

Episodic, semantic, and procedural memory describe what a remembered item is: an occasion, a standing belief, a way of doing something. This capability describes where any of them lives once the session is over and what that implies — a schema that must be migrated, a backup that is now a replica of personal data, a partition key that decides every isolation property downstream, and an answer for who may read this in eighteen months. All three types are stored here, and none of them is this.

Why it matters

Persistence is the point at which memory stops being a convenience and becomes a commitment. A sentence written during one conversation is something the product will later assert on a user's behalf with no human in the loop, something a security review will ask about, and something that appears in an erasure request. The decisions that determine whether that goes well — what earns a write, how it is keyed, whether it can be superseded — are made once, at the tier level, and are nearly impossible to revisit after the store has a year of content in it.

Key decisions

  • What earns a write. Writing on every turn is cheap and fills the store with noise that degrades retrieval months later; writing only on an explicit user instruction is safe and captures almost nothing.
  • The partition key — person, account, workspace, agent, or a tuple. This is the least reversible decision in the whole memory system and it determines isolation, deletion scope, and what "shared" can later mean.
  • Shape: typed slots with validation, or free text with an embedding. Typed is queryable, supersedable, and rejects what does not fit the schema; free text accepts everything and is then only as good as retrieval.
  • Whether a stored item is final or supersedable, and how the store represents something that was true and stopped being true, as opposed to something that was never true.
  • Durability posture, and specifically whether replicas and backups sit inside or outside the boundary that deletion and retention commitments apply to.
  • Whether the user can see, correct, and remove what is held about them directly, which is both a product feature and the cheapest correction mechanism available.

Failure modes

  • The store is keyed by individual user while the product is sold per workspace; a shared login mixes two people's memories and nobody notices until one of them is quoted to the other.
  • Write-on-every-turn is enabled for recall quality, retrieval precision collapses after a few months, and the resulting degradation is attributed to the model rather than to the store.
  • The shape is free text, a field is later needed for filtering, and there is no way to backfill it across millions of rows.
  • The embedding model is upgraded and the stored vectors are still from the previous one, so similarity scores quietly stop meaning anything without a single error being raised.
  • Backups retain records that were removed from the live store, and the completion report sent to the requester is therefore false.
  • Nobody owns the write policy, so when memory-driven quality regresses there is no changelog that would say which release changed what gets written.
  • Schema migration is attempted while agents are writing, and a partially migrated store serves two incompatible item shapes to the same retrieval query.

Related capabilities

Applies: Production readiness · Design questions