You open Claude Code on Monday morning and the first thing it does is ask you to explain the codebase - the same one you spent three hours walking it through on Friday. Claude Code agents are stateless. Every session starts fresh. The agent has no memory of the decision it made yesterday, the file it refactored last week, or the blocked dependency it flagged three days ago. That is not a bug. It is the default, and until recently it was the only option.
That default got significantly less mandatory in April 2026. Memory stores for Claude Managed Agents entered public beta on April 23, 2026. Sessions still start with a blank context by default - when a session ends, anything the agent learned is gone - but memory stores let you carry information across them: user preferences, project conventions, prior mistakes, domain knowledge. The question worth asking is whether this is a marginal quality-of-life improvement or something that changes how you architect agent workflows entirely.
What stateless actually costs a team
The cost is real and underreported. On a team of just 10 developers running three sessions a day each, you burn roughly 225 seconds a day on context re-discovery alone. Scale that to 50 developers over a month, and you're losing real engineering hours to stateless amnesia.
The subtler cost is re-derivation. An agent that doesn't remember previous reasoning will re-read the same files, re-examine the same trade-offs, and sometimes reach a different answer. So you don't just pay the re-briefing tax; you also get inconsistency across sessions - two Claude Code runs on the same codebase that make different architectural calls because the second one didn't know what the first one decided.
The production failure mode of a memoryless agent is not subtle: it forgets the user between sessions, contradicts itself within them, and degrades exactly as the user expects it to get smarter.
The workaround most teams reach for is CLAUDE.md.
Claude Code automatically loads a markdown file called CLAUDE.md into context at the start of every session. The file at the repository root loads when Claude Code is invoked from within that directory.
It's a persistent instruction file you place at your project root, in specific directories, or at the user level. It tells Claude your architectural decisions, coding conventions, and project constraints - improving output quality across sessions.
The limit of CLAUDE.md is that it's static. It captures what you write into it. It doesn't update from what the agent learns mid-session. If a Claude Code run discovers that a particular API returns a non-standard error on edge inputs, that finding vanishes when the session ends unless you manually note it in the file. The file is a solved problem for stable conventions; it's not a solution for accumulated, session-derived knowledge.
How persistent memory stores actually work
A memory store is a workspace-scoped collection of text documents. When you attach a store to a session, it mounts as a directory inside the session's container at /mnt/memory/. The agent reads and writes it using the same file tools it uses for the rest of the filesystem.
That design choice - plain files, not a vector database, not a proprietary API - is worth pausing on. Any inspection or editing you want to do happens in the Claude Console or via standard API calls. The abstraction is thin.
Stores can be scoped at the organization or user level, with different read and write permissions applied to each. Multiple agents can work concurrently against the same memory store without overwriting each other, and all changes are tracked in a detailed audit log that records which agent and session each memory came from.
Memories are files that can be exported and independently managed via the API, giving developers full control. All changes are tracked with a detailed audit log, so you can tell which agent and session a memory came from. You can roll back to an earlier version or redact content from history. Updates also surface in the Claude Console as session events, so developers can trace what an agent learned and where it came from.
The audit trail matters for exactly the reason you'd expect. In one real-world test, an agent destroyed almost 6KB of carefully-written notes in a single tool call. The platform's immutable versioning let the developer recover the file byte-for-byte, with full attribution of which session caused the damage. Cross-session memory works as advertised, but agents will sometimes get it wrong even when they're trying to do the right thing - and the audit trail is the kind of feature you don't appreciate until you need it.
Beagle in action#eng-infra, 8:52amThe numbers early adopters are reporting
The headline figure is from Rakuten. Memory in Claude Managed Agents lets them put continuous learning into production at scale. Their agents distill lessons from every session, delivering 97% fewer first-pass errors at 27% lower cost and 34% lower latency. And because memory is workspace-scoped and observable, continuous learning stays under their control.
Wisedocs built their document verification pipeline on Managed Agents, using cross-session memory to spot and remember recurring document issues, speeding up verification by 30%.
These numbers are from production pipelines - document verification and structured AI workflows - not open-ended coding. The gains in a raw Claude Code session will vary, and they depend heavily on the quality of what the agent writes to memory. A store full of vague summaries doesn't help. The value compounds from precision: specific decisions, specific error patterns, specific conventions that the agent actually encountered and resolved.
The non-obvious constraint: what the agent writes is what you get
Here is the thing nobody's talking about in the coverage of this feature. The memory store is only as good as what the agent writes to it - and the agent decides what to write. Multiple practitioners have independently settled on the same threshold: do not let context exceed 60% capacity. Auto-compaction fires at roughly 83.5% and is lossy, retaining only about 20 to 30% of details. In a world without persistent memory, that loss was annoying but bounded. Now that sessions feed memory stores, a compaction event mid-session could mean the agent writes an incomplete or misleading summary to a store that persists into every future session.
Anthropic has launched "dreaming" in Claude Managed Agents as a research preview. It is a scheduled process that reviews agent sessions and memory stores, extracts patterns, and curates memories so agents improve over time. Dreaming surfaces patterns that a single agent can't see on its own - including recurring mistakes, workflows that agents converge on, and preferences shared across a team. It also restructures memory so it stays high-signal as it evolves.
That last part is where the real value is. A single session's memory write might miss something or frame it wrong. A scheduled consolidation pass, run across hundreds of sessions, can surface a pattern no individual run would catch. The risk is symmetrical: a systematic error pattern could also consolidate. You still need humans reviewing what the store contains.
The practical model is not "set it and forget it." It's closer to shared team notes that the agent also writes to - which means the same discipline you'd apply to shared team notes applies here. Review what's in the store. Delete entries that are stale. Scope org-wide stores as read-only while per-user stores allow reads and writes. Treat the audit log as a first-class artifact, not an afterthought.
Persistent memory for coding agents: common questions
What is persistent memory for an AI coding agent?
Persistent memory for a coding agent is a storage layer that survives across sessions. Without it, every session opens with no knowledge of previous work - the agent re-reads files, re-examines trade-offs, and sometimes reaches different conclusions. With a memory store, the agent carries forward project conventions, prior mistakes, and domain context it accumulated in earlier sessions.
Does Claude Code have persistent memory?
Claude Code is stateless by default - each session starts fresh.
Claude Code doesn't maintain project memory the way Claude Projects does. Instead, it relies on files like CLAUDE.md and conversation history to preserve project context. You store project background, architecture decisions, and naming conventions in a markdown file at your project root, which loads automatically when a session starts.
This is hand-curated and doesn't self-update from what the agent discovers.
How do Claude Managed Agents memory stores differ from CLAUDE.md?
CLAUDE.md is a static file you write and maintain. It captures the conventions you already know. A Managed Agents memory store is writable by the agent itself across sessions - it accumulates knowledge from what the agent encounters, including patterns and mistakes that emerge at runtime. The two are complementary, not substitutes.
What does the Managed Agents "dreaming" feature do?
Anthropic launched "dreaming" as a research preview - a scheduled process that reviews agent sessions and memory stores, extracts patterns, and curates memories so agents improve over time. It runs asynchronously, surfaces cross-session patterns no single run would catch, and restructures memory to keep it high-signal over time. It is not yet generally available.
What is the cost of running Claude Managed Agents with memory?
Persistent memory runs on top of Claude Managed Agents, which costs standard Claude API token rates plus $0.08 per session-hour.
That sounds cheap until you're running thousands of concurrent agents. The memory feature likely increases session duration since agents do more work per session. Budget for longer sessions, and scope what the agent reads from the store carefully - loading a large memory directory into every session context is a fast way to burn the savings the feature is supposed to create.