AI agent memory is readable context that survives between sessions: decisions, conventions, and corrections the next run should not have to rediscover. Build it as a small always-loaded index plus a searchable long tail, let the model judge salience in-session, and run an offline dreaming job that checks notes against transcripts. Anthropic's The components of agent memory (6 November 2026) backs that shape with benchmarks on CL-Bench, Pokémon, and a ~350k-file internal corpus.
Sources I used: Anthropic research (6 Nov 2026), Arize Alyx architecture (read 9 Nov 2026), Databricks MemCurrent (read 9 Nov 2026), AAIF patterns (read 9 Nov 2026). Numbers are theirs, dated; the design calls are mine.
How does Anthropic define agent memory (November 2026)?
Anthropic (6 November 2026) defines agent memory as knowledge gained from experience, retained between sessions, and saved as context the agent can read later. It explicitly excludes weight changes, knowledge picked up only inside one conversation, and compaction (summaries that replace older turns so work can continue in a fresh window).
That boundary matters for design. Your chat log is not memory. Your vector index of every tool result is not automatically memory either. Memory is what you choose to promote because a later session will probably need it without repeating the work.
Anthropic also frames memory as prediction: writing a rule is betting the pattern will matter again. On CL-Bench 1.0, Claude Opus 5 was the first model they describe as closing the learning loop (rule plus how it knew, prior answers, trap warnings). Telling Opus 5 to record only failures cut the gain from memory; telling the model what memory is for, not rigid write rules, worked better on frontier models. Claude Sonnet 4.6 nearly doubled its score when prompted to read memory and test theories (Anthropic, 6 November 2026).
What memory pattern should I use when?
AAIF's pattern guide (read 9 November 2026) separates capabilities teams all call "memory." In production you often stack several; forcing one mechanism to do everything is how you get stale Pokémon encounter logs.
| Pattern | What it is | Use when | Skip when |
|---|---|---|---|
| Session state | Ordered messages and tool results in one conversation | The agent must continue the same thread | You need facts after the session ends |
| Retrieval | Search over a large corpus (code, docs, tickets) | Ground truth lives in many files | You only need a dozen durable conventions |
| Checkpoints | Durable step log for pause and resume | Long jobs, crashes, human gates | Short request/response turns |
| Extracted memory notes | Files or rows of decisions, rules, preferences | Cross-session continuity | Everything is re-fetchable from an API |
| Shared memory | One store several agents or users read | Coordinating bots with explicit ownership | No scope, provenance, or delete story |
Checkpoints pair with execution durability, not with "remember my tone." See durable AI agents for step logs and idempotency. Retrieval pairs with tools; see MCP vs function calling when the same integrations must work across hosts.
Arize Alyx (architecture post, read 9 November 2026) went the opposite direction from heavy vector-plus-graph designs: one structured file per user and space, 8,000 characters, loaded whole every request, updated by background jobs. For a scoped agent, that can be enough (they report 16 of 18 memory-dependent eval questions correct). Databricks MemCurrent (blog, read 9 November 2026) combines append-only episodic session history with mutable derived files, a top-level memory.md index, plugin injection at session start, search_memory / fetch_memory during work, and an offline dreaming pipeline.
What should agents store vs leave out?
Three lists, because teams still stuff live Shopify inventory into "memory" and wonder why next week lies.
Store (durable, costly to rediscover):
- Decisions and why ("we rejected chain-of-thought in v4 after latency regression").
- Project conventions, naming, off-limits actions.
- Verified corrections and trap warnings (Anthropic's CL-Bench loop).
- Plans and strategy the environment does not print on screen (Anthropic's Pokémon comparison: Claude Fable 5 used nine files plus
global.mdand earned four badges; Claude Sonnet 3.7 wrote 413 files in 225 folders, one badge, and spent steps curating stale state).
Do not store:
- Secrets, tokens, private keys (AAIF lists these as weak candidates for persistence).
- Live values you can read from a tool next turn (player coordinates, current spend).
- Raw tool dumps "for safety" (bloat and drift).
- Untrusted content treated as instruction (AAIF: retrieved page is source, not policy).
Hierarchy: a thin always-loaded index (Anthropic: Claude Code auto memory loads only the first 200 lines or 25 KB of MEMORY.md) and searchable depth below. Wrong notes in the injected layer poison every session; dreaming's promotion work is partly keeping that layer small (Anthropic, 6 November 2026).
My webmaster agent writes its SEO plan, content calendar and a change log (each experiment with a baseline) to Notion; when several of my bots share Notion, each section has one writer and the others only read. Rule of thumb from AI webmaster agent: if you'd be annoyed to explain it twice, it goes in memory.
How do I design a dreaming / consolidation job?
Anthropic's dreaming is an offline pass over transcripts (and existing notes). It can correct mistakes (Pokémon Mt. Moon PokéCenter east/west note), build wikis with links, promote stable facts into the always-loaded layer, and fill gaps (repoint dead wiki links, add index pages).
Sketch for production:
| Step | Cadence | Action |
|---|---|---|
| Ingest | After session or nightly batch | Pull new transcripts; skip empty runs |
| Validate | Every dream pass | Compare note claims to transcript ground truth; flag drift |
| Merge | When duplicates detected | Collapse overlapping pages; keep provenance pointer |
| Promote | When note stable N sessions | Move one-line summary to index; leave link in long tail |
| Expire | Weekly or on access drop | Archive notes tied to finished projects |
| Contest writes | On shared tables | Prefer one agent per durable artifact (Anthropic LAB contracts: 41/57 facts with shared table vs 57/57 with one agent per contract quoting terms verbatim, 6 November 2026) |
On Anthropic's Stainless corpus eval (~350,000 files, ~420M tokens, 6 November 2026), wiki-only accuracy went from 13% to 48% of graded criteria as dreaming scaled 2 to 128 sessions; search plus wiki reached 61% vs 53% search alone, saving about 20,000 tokens per question. Merger questions: 87% with wiki vs 73% search alone. Dreaming is not free compute; tune cadence to how fast your world changes (Anthropic's open question, 6 November 2026). Wire it like any background chore: Vercel Schedules vs cron jobs if you already run timed jobs on this stack.
Tell the online agent what memory is for, not micromanagement write rules. Run dreaming with goal-tuned instructions when one artifact class dominates (contract terms in LAB). For token budget discipline while memory grows, see keeping Claude's token bill under control.
Production checklist for long-term agent memory
- Named memory types (session, retrieval, checkpoints, extracted notes, shared) and owners per store.
- Small injected index with hard byte/line cap; everything else fetched or searched.
- Write path: model or tool, plus optional async summarizer (Arize-style) or episodic append (MemCurrent-style).
- Dreaming job with transcript validation and duplicate merge.
- No secrets in memory files; redact before persist.
- Supersession: old decisions marked replaced, not silently deleted without trace.
- Eval set with memory-needed and memory-harmful questions (Arize reports passing the second group).
- Multi-agent: one writer per section in shared memory (single agent vs multi-agent for when extra loops earn their keep).
FAQ
What is AI agent memory?
In Anthropic's 6 November 2026 post, agent memory means knowledge the agent gains from experience and retains between sessions as readable context (not weight updates, in-context learning within one chat, or compaction). Memory is often a prediction about what a future session will need.
What should an agent write to long-term memory?
Store durable facts you cannot cheaply re-fetch, decisions with rationale, conventions, and verified corrections. Do not store secrets, live metrics, raw tool dumps, or untrusted content. AAIF's pattern guide makes the same split: source material is not automatically an instruction just because it persisted.
What is agent memory dreaming?
Dreaming is an offline pass over session transcripts that checks notes against ground truth, merges duplicates, builds wikis, promotes a small index into always-loaded context, and fills gaps. Anthropic (6 November 2026) reports wiki quality rising from 13% to 48% graded criteria on a 350k-file corpus as dreaming scaled from 2 to 128 sessions.
Should I use search, a wiki, or an always-loaded file?
Use a small always-loaded index (Anthropic cites Claude Code loading the first 200 lines or 25 KB of MEMORY.md) plus search or fetch for the long tail. On Anthropic's Stainless corpus eval (6 November 2026), search plus wiki scored 61% versus 53% search alone and saved about 20,000 tokens per question.
About the author
I'm Joan Comadran, an AI engineer and full-stack developer in Barcelona (industrial engineer, UPC). I run my own agents with memory and use Notion as shared memory between bots; my Sogas Mascaró webmaster setup is role, tools, memory, routines, and approvals in one loop (write-up). If you want memory boundaries drawn on a real product, that's what I do.