Agent Memory Systems

A survey of external agent memory systems — how AI agents store, retrieve, and maintain knowledge across sessions and tasks. We track knowledge bases, context-engineering layers, structured note-taking tools, and trajectory-learning loops, reading their source code wherever it is available.

Historical comparison: Scan the comparison table — one row per system, a plain-English description plus the handful of fields that actually discriminate. Then read the comparison, which synthesizes a 148-system matrix snapshot, and browse the repo-backed reviews under reviews/ — each reads the actual code and reports what a system does, not what its README claims.

We track these systems to make a shared design space inspectable. Commonplace supplies the ontology that names recurring solutions; convergence, variation, and failed mappings across independent projects then test that ontology more strongly than any single design argument.

How we review

Current analysis uses analyse-agentic-system, which delegates memory findings to analyse-agent-memory and integrates its typed report into the main result. New runs publish under kb/agentic-systems/; the reviews in this collection remain historical records.

The historical reviews classify a system's retained behavior-shaping artifacts in one shared vocabulary, so independent systems can be set side by side on the same terms. The vocabulary, and the activation distinction the reviews turn on, come from these theory notes:

• designing-agent-memory-systems — the design-pressure inventory the review contract distills into review-time sections.
• The four-field artifact record every review applies to each system's central artifacts:
• storage substrate — where retained state physically lives (files, repo, sqlite, rdbms, vector/graph, kv, in-memory, model-weights, service-object); locates access, versioning, deletion.
• representational form — natural-language / symbolic / parametric; sets the default inspection method (read / test / probe).
• lineage — authored, imported, or trace-extracted, and what source change invalidates it.
• behavioral authority — who consumes it, through which channel, with what force (knowledge advice vs system-definition instruction / enforcement / routing / validation / ranking / learning).
• (the record applies at the operative-part level of a retained artifact — a bundled object is split when its parts carry different forms or authorities.)
• knowledge storage does not imply contextual activation — separates stored memory, memory loaded into context (read-back: pull / push / both), and memory that actually changes behavior; the reason a review states a read-back direction and asks whether faithfulness is tested.
• Rule-based context selection needs a pre-existing signal — why a targeted push needs an identifier already on the table or a content inference; grounds the read-back signal (coarse vs identifier vs inferred).
• agent memory is a crosscutting concern, not a separable niche — why these axes span storage, retrieval, and learning at once rather than being one "memory" box.

The review type spec records the contract that turned these notes into the fixed review sections and the backticked lead tokens used by the historical matrix.

The review states the external mechanism first, then explains why a Commonplace term fits. It is not a delta from Commonplace. Current borrowable ideas or differences are selective transfer scans kept as living operational state until disposition; they do not feed the matrix or public analysis.

Coverage

Two historical coverage tiers. reviews/ holds implementation-grounded reviews; lightweight/ holds coverage grounded in papers, READMEs, or other documents. Current main analyses preserve the same distinction through their evidence-tier field, without adding reviews to either directory here.

Browse the roster:

• Repo-backed reviews (reviews/) — systems with open-source repos, reviewed from the code; the comparison table is the curated entry point

• Lightweight coverage — paper- or README-grounded systems with no inspectable repo

Cross-cutting reads:

• Comparison table — one scannable row per code-reviewed system

• Comparison — synthesis across its 148-system code-reviewed snapshot

• Trace-learning techniques in related systems — broadens the comparison to artifact-learning and weight-learning systems fed by live traces

• Thalo type comparison — detailed type mapping against the Commonplace document types

Comparison matrix

systems.csv and the comparison table are historical snapshots of this legacy corpus. The current builder, renderer, and analyzer read the main analysis's retained results directly and write under kb/agentic-systems/comparisons/; see the new comparison input contract and commands. They no longer rebuild these legacy files or preserve hand-classified columns.

The landscape procedure now reads retained main results and derives a matching matrix in one frozen bundle. The legacy snapshots here remain outside that population. Historical reproduction of these old comparisons requires their matching reviews, contracts, parser, and matrix at one reconstructable revision.

The ASISAS-2026 paper's frozen corpus and Karpathy-gist sample split are deposited separately at DOI 10.5281/zenodo.20759081, pinned to Commonplace v0.1.0 (e957a7b). Historical evidence remains independently citable; it is not part of the new input population until regenerated through the main analysis.

Patterns Across Systems

Most systems here (ours, Ars Contexta, Thalo, ClawVault, Agent-Skills) independently converge on:

• Filesystem over databases — plain text, version-controlled, no lock-in

• Progressive disclosure — load descriptions at startup, full content on demand

• Start simple — architectural reduction outperforms over-engineering

• Trace-learning — trace-learning techniques in related systems broadens the comparison beyond pi-adjacent session mining to include artifact-learning and weight-learning systems fed by live traces and trajectories

The divergences are more revealing:

• Storage model — Cognee uses a poly-store (graph + vector + relational with pluggable backends), Siftly uses SQLite, CrewAI uses LanceDB by default with optional Qdrant Edge, Hindsight uses PostgreSQL+pgvector, Zikkaron uses SQLite with FTS5+sqlite-vec, and SAGE uses SQLite+BadgerDB (personal) or PostgreSQL+pgvector (multi-node) as operational substrates, while the others keep files as the primary storage interface. OpenViking occupies a novel middle position: it presents a filesystem interface (viking:// URIs, ls/read/find operations) but the substrate is AGFS + vector index — filesystem as metaphor, not mechanism. Cludebot uses Supabase (PostgreSQL+pgvector) for its full mode but also offers a local JSON file store that is the closest a database-first system gets to filesystem-first. Cognee, Hindsight, CrewAI, Zikkaron, Cludebot, and SAGE are the furthest from filesystem-first: memories are opaque database records, not readable files

• System boundary — CocoIndex sits one layer below most systems here: it is an incremental engine for maintaining derived vector/graph/relational projections, not a primary knowledge medium. That makes it more relevant to our "operational layer beneath the KB" question than to the note/link semantics question directly

• Agent-facing UX — Napkin is the clearest example of treating CLI output itself as part of the memory architecture: hidden scores, match-only snippets, and next-step hints are all tuned for model behavior rather than human browsing. Most other systems focus on storage and retrieval internals but leave the interaction layer human-shaped

• Context-operation interface — Scroll combines a coarse pushed map with structured recall and model-authored Python over a retention-bounded event store, while Virtual Context uses proxy-owned selection plus paging tools. The comparison supports context-operation interface bounds context policy: retained volume alone does not determine what a controller can project into the next bounded call

• Packaging unit — most systems distribute concerns across multiple files (notes, configs, scripts, indexes), but o-o pushes the opposite extreme: each document is a self-contained polyglot file carrying rendering, update contract, shell dispatch, source cache, and changelog. That maximizes portability and local inspectability at the cost of modularity and inter-document structure

• Grounding discipline — cognitive psychology (arscontexta) vs programming theory (Commonplace, thalo) vs empirical operational patterns (Agent-Skills)

• Formalization level — custom DSL (thalo) vs YAML conventions (Commonplace) vs natural-language instructions (Agent-Skills)

• Governance stance — most systems treat governance as advisory (instructions the agent should follow); Decapod enforces governance with hard gates (validation must pass, VERIFIED requires proof-plan); SAGE enforces with cryptographic gates (signed transactions, validator quorum, RBAC clearance levels) — two very different enforcement models, both structurally enforced rather than instructed

• Access control — SAGE has structured multi-agent RBAC (clearance levels, domain-scoped permissions, on-chain agent identity); Cognee has relational ACLs with tenant isolation and per-dataset permissions; most other systems either have no access control or rely on filesystem permissions

• Cross-agent knowledge transfer — most systems are single-agent or agent-agnostic; cass-memory is the first reviewed system to make cross-agent session mining a first-class feature, indexing logs from Claude Code, Cursor, Codex, Aider, and others into a shared playbook

• Runtime self-modification — most frameworks have fixed agent topology defined at build time; OpenSage lets agents create subagents and scaffold new tools at runtime, though without quality gates on the created artifacts. Exo broadens the target to prompts, memory, tools, executor policy, and harness code while keeping canonical history in a protected substrate outside the rewound sandbox; its recovery boundary is stronger than its semantic promotion gates

• Self-referentiality — only our KB is simultaneously a knowledge system and a knowledge base about knowledge systems

Open Questions

• Does convergence on filesystem-first indicate a durable pattern, or a phase that will be outgrown?

• Should high-volume ingestion in a file-first KB adopt a small operational database layer for stage state and indexing?

• Will the programming-theory grounding produce better systems than the psychology grounding, or will they converge?

• Are there systems we're missing that take a fundamentally different approach?

---

Complete file listing (generated at build time)