AI agent memory: what your Claude agent should remember, and how dreaming keeps it right

Most teams treat agent memory as a feature flag. Switch it on, and the agent will "learn" your business. In practice, memory is closer to a small database that Claude writes to itself, reads back in every session, and trusts by default. If what it remembers is wrong, stale or redundant, the agent gets worse over time, not better.

Anthropic's engineering team made that case with data on 6 November 2026 in The components of agent memory (opens in a new tab). This post turns that research into practical design decisions for business agents: what to remember, what to look up, and how to keep memory correct with dreaming.

The headline result is that memory helps, by a lot. On a CL-Bench 1.0 database task run on Claude Managed Agents, Anthropic reports that moving from stateless runs to runs with memory raised scores from 0.655 to 0.838 for Opus 5.5, from 0.644 to 0.833 for Sonnet 5.5, and from 0.383 to 0.700 for Opus 4.7 (Anthropic (opens in a new tab)).

The same research shows how easily that gain is lost. Wrong notes get trusted in later sessions. Redundant notes go stale. Long instruction files reduce adherence. None of these are model failures; they are design failures. That is why we treat memory as a small data asset with an owner, a scope and a review step.

Anthropic describes a memory hierarchy with four layers (Anthropic (opens in a new tab)):

• Transcripts: the raw record of what happened in each session.
• Memory notes: short notes Claude writes for itself about what it learned.
• Representations such as wikis: structured, organised knowledge built from many sources.
• Injected context: material loaded into every session, whether the agent asks for it or not.

Dreaming works across these layers. It can correct notes, build representations and shape what gets injected. A useful way to think about it: transcripts are evidence, notes and wikis are working knowledge, and injected context is the small set of things the agent must never forget.

Anthropic's most memorable example comes from a Pokemon-playing test. Sonnet 3.7 wrote 413 files across 225 folders and earned one badge. A later model wrote nine files plus a global.md and earned four (Anthropic (opens in a new tab)). Anthropic's conclusion is that storing state the agent could read anyway was redundant and went stale.

Apply that to a business. Your ERP already knows stock levels. Your CRM already knows the account owner and deal stage. Your Shopify store already knows order status. If the agent copies those facts into memory, you now have two versions of the truth, and the memory copy is the one that will be wrong next week.

What belongs in memory is what no system of record holds:

• Rules and traps: "Carrier X's tracking API returns 'delivered' before the scan is final; confirm with the POD before closing."
• Interpretations: "In this client's leases, 'operating costs' excludes capital repairs unless clause 14 says otherwise."
• Working preferences: "Legal wants clause references, not paraphrases."

Everything else should be looked up live. This is where data and automation pipelines that keep systems of record as the source of truth matter as much as the agent does. The agent needs reliable read access to current data so it never has to remember it.

A natural instinct is to give the agent strict rules about memory. Anthropic tested this. A fixed rule to "record only failures" reduced the memory gain by 0.234 for Opus 5 and 0.150 for Opus 4.7 (Anthropic (opens in a new tab)). Telling Claude what memory is for, rather than how to use it, worked better.

In practice, a good memory brief reads like a purpose statement: "Remember anything that would help a colleague handle the next RFP for this client faster and with fewer errors." A poor one reads like a filing procedure. Let the model decide the format. You decide the goal and the limits, such as "never store personal data" or "never store prices".

The risk with any memory the agent writes for itself is that a wrong note becomes a trusted note. Anthropic showed this directly. Dreaming checks notes against transcripts, and in the Pokemon test the run with the corrected note reached Cerulean City, while the uncorrected run never did (Anthropic (opens in a new tab)).

Dreaming launched in Claude Managed Agents as a research preview on 19 May 2026, with access by request (Claude blog (opens in a new tab)). It is a scheduled process that reviews sessions and memory stores, extracts patterns and curates memories. It can update memory automatically or let you review changes before they land, and it can pull shared learnings across agents (Claude blog (opens in a new tab)).

The Dreams documentation (opens in a new tab) explains how it works. Memory stores pick up duplicates, contradictions and stale entries. A dream reads one memory store plus 1 to 100 session transcripts and writes a new output store. The input store is never modified, so the output can be reviewed or discarded. An optional instructions field steers the synthesis, and targeted edits go through the Memory Stores API.

That design fits a pull-request workflow, which is what we recommend for business agents:

1. Schedule a dream over a limited set of recent sessions.
2. Diff the output store against the current one.
3. Have the process owner approve, edit or reject the changes.
4. Promote the approved store and keep the old one for rollback.

Automatic updates may be fine for low-stakes internal tools. For anything that touches customers, contracts or money, a person should read the diff first.

Wikis are the most expensive layer to build and maintain, so they need to earn their place. Anthropic's results are specific. On multi-document merger questions, Claude scored 87% with a wiki against 73% with search alone. Where the criteria came from a single document, there was no clear gain. One wiki also grew to 1.77 times the size of its source corpus (Anthropic (opens in a new tab)).

A second finding matters for contract work. When contract terms were extracted with one agent per contract and quoted word for word, 57 of 57 facts survived, against 41 of 57 for a shared table (Anthropic (opens in a new tab)). Summaries lose detail. Word-for-word extraction, one document at a time, keeps it.

The rule that follows is simple. Build a wiki only when the task regularly needs facts that span many documents. If the answer usually lives in one document, good search over the source is cheaper and stays current.

Three practical constraints from the Dreams documentation (opens in a new tab) should shape any rollout:

• Availability: dreams are a research preview on the Claude API for select models and need the beta headers managed-agents-2026-04-01 and dreaming-2026-04-21.
• Time and cost: dreams run asynchronously and typically take from minutes to a few hours, depending on the number of transcripts. They are billed at standard API token rates for the chosen model, and cost scales roughly linearly with the number and length of sessions. Start small.
• Data handling: Managed Agents, including dreams, is not eligible for Zero Data Retention (ZDR) or HIPAA, and session transcripts persist until you delete them.

That last point settles the question for regulated workflows. If a process handles patient data or falls under a ZDR requirement, Managed Agents memory is not the right home for it today. Design a different architecture, or keep regulated data out of the sessions entirely. Decide your transcript deletion policy before the first session runs, not after.

Keep injected context small as well. A wrong note in injected context is carried into every session, and longer instruction files reduce adherence. For reference, Claude Code's auto memory loads only the first 200 lines or 25 KB of MEMORY.md (Anthropic (opens in a new tab)). That is a sensible budget to aim for in your own agents.

Before you turn on memory for any agent, answer these questions:

• Which system of record holds each fact the agent uses? If one exists, look it up; don't remember it.
• What is memory for, in one sentence?
• What must never be stored (personal data, prices, credentials)?
• Does the task span enough documents to justify a wiki?
• Who reviews dream output, and how often?
• Is the workflow subject to ZDR, HIPAA or a retention policy?
• What fits in a small injected-context budget?

Here is how that works out for three common agent types.

A proposal and RFP engine should remember buyer preferences, rejected phrasing, compliance traps and which answers reviewers keep correcting. Pricing, product specs and case material should be pulled live from the teams that own them. RFPs draw on many documents, so a reviewed answer library or wiki can be worth building. Run dreams after each submission cycle and have the bid lead approve the diff.

A lease document abstraction agent should follow Anthropic's per-contract finding: one extraction pass per lease, with terms quoted word for word rather than merged into a shared table. Memory should hold interpretation rules and known drafting quirks, not the lease terms themselves, which belong in the abstract and the source document. A wiki may help with questions that cover the whole portfolio.

A shipment exception desk runs on live data. Shipment status, ETAs and order details must come from carrier and order systems every time. Memory should capture carrier-specific traps, escalation rules and resolution patterns that worked. Questions about a single shipment rarely need a wiki; search and live lookups are enough. Keep injected context to the few rules that apply to every case.

We design and build AI agents and automation on Claude, and memory design is part of the brief from day one: what the agent remembers, where the source of truth lives, and who reviews changes. We bring the same product thinking to our AI product engineering, including Infra-Q, an AI web product in development.

If you are planning a Claude agent for a repeat workflow and want a second opinion on what it should remember, talk to Softpiper about your agent's memory design.

• The components of agent memory (Anthropic Engineering, 6 Nov 2026) (opens in a new tab)
• New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration (Claude blog, 19 May 2026) (opens in a new tab)
• Dreams - Claude Platform Docs (opens in a new tab)