Agent Atlas / Chapter 6

Memory Is a Typed Storage Contract

Calling every retained fact memory obscures incompatible stores and guarantees. Thread history, notes, retrieval indexes, summaries, caches, and archives have different owners, lifetimes, and deletion behavior.

Learning objective

Use public evidence to answer: Where is agent state written, how is it selected for a turn, and what does forgetting actually remove?

Working question

Where is agent state written, how is it selected for a turn, and what does forgetting actually remove?

Continuity emerges from explicit write, read, correction, compaction, archive, and forget semantics.
Five nested storage layers move from short-lived high-fidelity turn context to durable records with increasing persistence and distortion risk.
Memory is a stack of contracts Memory layers differ in lifespan, fidelity, ownership, retrieval cost, and correction path. Open full-size diagram
Case file 06 / Undo does not mean delete

A forgotten turn can still exist

Hermes implements undo by marking transcript rows inactive rather than deleting them. The rows remain available for audit but disappear from active prompts and search. Hermes then evicts cached agent state so the next message rebuilds from active-only history.

Forgetting therefore requires coordinated storage, query, and cache behavior. Codex draws another boundary by moving memory-owned tables and jobs into memories_1.sqlite while durable thread metadata remains elsewhere. Rewindable conversation state and rebuildable memory pipelines are not the same store.

Latest newsroom receipts

What changed since the first Atlas draft

Mechanism trace

What actually happens

  1. Turn context

    selected, short-lived, high fidelity

  2. Thread history

    durable conversational record

  3. Notes and memories

    typed writes with provenance

  4. Indexes and caches

    derived and rebuildable

  5. Archive and audit

    long-lived, costly to correct

Name the store before calling it memory

A useful inventory distinguishes active turn context, durable thread history, append-only notes, extracted memories, retrieval indexes, cached agents, archived sessions, and inactive transcript rows. Each needs an owner, schema, namespace, retention policy, rebuild rule, and authority model.

Codex's separate memory database makes pipeline state independently rebuildable while preserving thread metadata. OpenViking's abstract, overview, and full-content layers expose another typed distinction: different reads trade detail for context cost.

Writes need authority and conflict semantics

Codex's ad hoc note path validates filenames, rejects path-like names and empty notes, and uses create-new semantics. Those constraints prevent accidental overwrite and namespace traversal. The tool remains behind a disabled registration path, treating exposure as a separate rollout decision.

Every memory write should record source, author, trust class, scope, timestamp, and idempotency key. It also needs correction and conflict rules: append, supersede, reject, or merge. A model-generated note without provenance is an assertion, not durable knowledge.

Reads are selection and injection

Codex additionalContext entries carry trust kinds and support deduplication, reset, and truncation before hidden injection. Reading is an explicit selection pipeline, not an invisible dump of everything previously stored.

A read contract should identify the selected source version, trust class, retrieval score, token budget, and injection location. Stale or low-authority memories must not silently outrank current user instructions.

Forget is a family of operations

Soft deletion hides records from active reads while retaining audit history. Archive allows restoration. Hard deletion removes durable data. Cache eviction removes derived runtime state. Index deletion prevents retrieval. These operations are related but not equivalent.

Compaction is also not deletion. A summary can reduce context cost while preserving original archives, unsummarized tails, and sensitive or incorrect source records elsewhere.

Failure modes

Where the contract breaks

Cross-store forgetting mismatch

A row is hidden while caches, indexes, summaries, or backups still contain it.

Failure signalForgotten content reappears after restart, retrieval, compaction, or resume.

Poisoned or conflicting write

Untrusted content is persisted without provenance or collision handling.

Failure signalA memory write lacks source metadata, scope, or supersession rules.

Lossy or stale read

Compaction omits a constraint or retrieval selects obsolete state.

Failure signalInjected context cannot identify its source version or trust class.
Release tests

What the product must prove

  1. Inventory every store with owner, schema, namespace, retention, rebuildability, and deletion guarantees.
  2. Trace one fact through write, index, cache, read injection, correction, archive, and forget operations.
  3. Verify telemetry records operation, scope, status, truncation, provenance, and compaction markers without leaking content.

Projects In This Lesson

12 projects

Recent Reporting For This Lesson

6 articles