Long-term stores, compared by retrieval path

Lesson 4 of 5 in Memory Architectures: Engineering the Context at Scale.

Once information leaves the context, the architecture question inverts: not how do we store it but how does it get back in? The retrieval path is the defining property of any long-term store — a store you cannot reliably retrieve from at the right moment is not memory, it is a write-only landfill that costs money and accumulates risk.

Production agents draw on four store families, usually in combination. Compare them on the three dimensions that decide real designs: the retrieval path (how the agent finds it again), the staleness risk (how it goes wrong over time), and the cost profile (what you pay, in storage and in per-session tokens).

Four long-term stores — retrieval path, staleness risk, cost
Store	Retrieval path	Staleness risk	Cost profile	Watch out for
Files — notes, checkpoints, project conventions	Read the whole file into context at session start, or fetch by path/grep. Deterministic, human-readable, trivially auditable and editable.	High if never pruned. The file grows monotonically, and every stale line is re-injected into — and taxes — every future session.	Storage ≈ free; the real cost is tokens per session, which scales with file length.	One ever-growing file quietly becomes context rot with a filename. Prune on a schedule.
Key-value — preferences, settings, entity records	Exact-key lookup: deterministic, fast, cheap. But the agent must know the key — there is no fuzzy recall.	Medium. Overwrites keep individual values fresh, but keys nobody queries anymore accumulate silently.	Cheap at any scale; retrieval injects only the value asked for.	Schema drift — three subsystems writing `user_pref`, `userPreference`, and `prefs.user` — and no path to discover what you don’t know to ask for.
Vector index — embedded chunks, semantic recall	Semantic search: embed the query, return nearest neighbours. Fuzzy recall by meaning — finds things the agent didn’t know to ask for. This is RAG territory.	High. Similarity is not truth or freshness: a confidently stale (or poisoned) chunk keeps winning retrieval forever unless expiry, recency ranking, or provenance filtering demote it. True deletion is hard — embeddings and caches outlive their source.	Embedding compute + index storage + re-embedding on updates; each retrieval injects k chunks of budget.	Retrieval quality feels like memory quality — a store full of garbage still returns confident nearest neighbours.
Episodic logs — append-only run records, transcripts, traces	Time-range and attribute queries: “what happened in run 41,” “every session that touched this customer.” The replay and audit path — and the raw feed for evals.	Low, with a twist. Episodes are facts about the past and never go stale — but their lessons do nothing until a distillation pipeline extracts them into one of the other stores.	Storage grows without bound — retention policy required; retrieval is cheap but returns bulk.	Raw episodes are far too big to re-inject. An episodic log without distillation is an archive, not a memory.

AgentCore Developer Guide — Memory (as of September 2026)

Amazon Bedrock AgentCore Memory is a useful reality check: a managed service that reproduces this lesson’s architecture almost exactly. It offers two memory types — short-term memory storing raw interaction events (messages, tool calls) for in-session context, and long-term memory storing insights extracted across sessions, such as user preferences, semantic facts, and summaries. Extraction into long-term memory is driven by configurable strategies — semantic, summarization, user preference, episodic, or custom — with extracted records retrievable via semantic search; configure no strategy, and the resource stores only short-term events. Two details carry design lessons beyond AWS: extraction is asynchronous (there is a delay between event ingestion and extracted-record availability — consolidation is a background job, not a synchronous write), and memory is scoped by actorId and sessionId with namespace paths per strategy — isolation is in the data model, not bolted on. This is an educational snapshot, not vendor documentation — check the current AgentCore docs before building.

Pick the store for one piece of information

Interactive decision tree — outcomes:

Key-value store
Deterministic lookup by a key the agent already knows. Cheap, fast, precise — the right home for preferences, settings, and entity records. Govern the key schema before three subsystems invent three spellings.
Files
Inject the whole file at session start. Auditable, human-editable, zero infrastructure — ideal for the small durable working set. The discipline is pruning: every line you keep is a tax on every future session.
Episodic log
Append-only, queryable by time and attribute. This is your audit trail, replay source, and evals feed — but raw episodes never re-enter context whole. Pair it with a distillation pipeline that extracts lessons into the other stores.
Vector index — with staleness controls
Semantic recall earns its cost when queries are unpredictable. But similarity is not truth: budget for expiry, recency ranking, and provenance filtering from day one, or the most confidently retrieved chunk in your system will eventually be a stale one.
Don’t store it
If you cannot name the retrieval path, storage adds cost and risk with no payoff — a write-only landfill. Drop it, or keep it only in the episodic log where audits can still find it. Storage without retrieval is a liability, not memory.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.