Claude apps Claude appsMemory

Claude Memory: how it works and how to steer it

Claude Memory lets Claude keep facts about you and your work across separate conversations, so it does not start from zero each time. It builds up as you use it, you can view, edit, and delete what it holds, and you can switch it off. It is the durable layer that sits on top of a single chat's context, and like any memory, it is only useful if you steer it.

Overview

The first time Claude remembered my writing preferences without being asked, I was sold. The second time it remembered something wrong, I learned the other half of the feature. For a solid week it was quietly certain we still sold to enterprise, months after we had moved down-market, and it tilted every draft that way until I found the stale fact and deleted it.

That is memory in one story. It is the layer that lets Claude carry what it knows from one chat to the next, which is genuinely useful, and which is exactly why a wrong entry does real damage. Memory is a colleague you have to train, not a database you can trust blind.

So here is how it works and, more to the point, how to steer it, because the steering is the part people skip and then blame the model for.

Memory is the layer that survives the chat

Memory is the layer that survives the chat

A single conversation lives in context, the window Claude can see right now. Memory is the separate layer that carries facts across conversations, so a brand-new chat can recall what you told it last week. If you have read the context and memory piece, this is the concrete version of the memory half.

The distinction is not academic, it is the source of most confusion. When people say Claude 'forgot', they usually mean a fresh chat started with an empty context, which is normal. Memory is the thing that makes a fact persist past that reset, and it only holds what it has been allowed to keep.

So the useful frame is two clocks running at once: context is what Claude knows for this task, memory is what it knows about you, period. Different clocks, different rules for each.

Context vs memory
  1. What Claude can see right now, this session Context
  2. What persists across sessions Memory
Context is working memory for one task. Memory is the durable record it reads at the start and writes at the end.
💡

TipWhen Claude seems to 'forget' mid-task, that is context filling up, not memory failing. When it should have known something from last week and did not, that is memory, and probably nothing was ever saved.

What it actually holds

What it actually holds

Memory accumulates facts about you and how you work: your role, your preferences, the projects and terms you keep circling back to. It builds quietly as you use Claude, so over time it needs less setup from you to be useful, which is the whole promise.

Two things to keep straight. It is personal to your account, not a shared team brain, so your memory and your colleague's are different. And it is a running interpretation of your chats, not a perfect log, so it can hold a slightly-off version of something you said in passing. Useful, but fallible, like an actual memory.

You can see and steer it

You can see and steer it

The part that makes memory safe to use is that it is not a black box. You can inspect what Claude has stored, change it, remove entries, and switch it off entirely if you would rather it persist nothing. That control is the feature, not a footnote to it.

  • View: read the facts Claude is holding about you
  • Edit or delete: fix a wrong entry, or clear one that has gone stale
  • Turn it off: run with no persistence when you want a clean slate
💡

TipSkim your memory occasionally the way you would tidy a desk. Two minutes of deleting stale entries prevents a week of subtly-off answers built on them.

Steering it is the whole skill

Steering it is the whole skill

Treat memory like an assistant you are training, because that is exactly what it is. Tell it explicitly what is worth remembering, your ICP, your rules, how you like output, and when it holds something stale, correct it instead of working around it. A little curation keeps it an asset; neglect turns it into a confident liability.

My down-market story is the lesson in one line. Nothing was broken. The feature worked perfectly, holding a fact I had let go stale, and applied it with total confidence to everything downstream. The fix was ten seconds of editing, and the cost of not doing it was a week of skewed drafts. Steer it, or it steers you.

💡

TipWhen you correct Claude on the same fact twice, do not correct it a third time, open memory and fix the underlying entry. The repeat correction is the tell that memory is holding something wrong.

Memory vs a file, for anything shared

Memory vs a file, for anything shared

Memory is great for personal continuity. It is the wrong tool for anything the team must share, because it is personal and implicit: only you have it, and you cannot easily review or version it. For shared truth, your ICP, your positioning, your rules, use a file instead, an ICP doc or a CLAUDE.md that Claude reads.

A file is explicit, reviewable, and identical for everyone, which is exactly what shared context needs and exactly what memory is not. The strong setup runs both: memory for your personal defaults, files (and Projects) for the truth the whole team works from.

💡

TipIf a fact should be the same for you and your colleague, it belongs in a file, not in memory. If it is just how you personally like things, memory is fine.

Where memory goes wrong

Where memory goes wrong

The headline failure is confident amnesia: a stale fact that nobody pruned, applied with total authority. It is worse than a gap, because a gap makes Claude ask and a stale fact makes it assert. Old, trusted memory does more damage than missing memory.

The second trap is over-trusting it for things that should be explicit. Relying on memory to hold your positioning means you cannot see it, review it, or share it, and you will not notice when it drifts. The third is forgetting it is personal, and assuming your teammate's Claude knows what yours does. It does not.

None of these are reasons to turn memory off. They are reasons to steer it: prune the stale, keep shared truth in files, and remember whose memory you are actually relying on.

💡

TipAnything you would be embarrassed to have wrong in front of a customer should live in a file you can see, not only in memory you have to trust.

How to run memory well

How to run memory well

The setup is light. Let memory build, but seed it on purpose by telling Claude the durable things about how you work, and skim it every so often to prune what has gone stale. For sensitive or regulated work, turn it off for that session rather than hoping nothing got kept.

Then push the shared, load-bearing context out of memory and into files and Projects, so memory is doing what it is good at, remembering you, and files are doing what they are good at, holding the team's truth. That division is the whole art of it.

💡

TipDecide once, per fact: is this personal (memory) or shared and load-bearing (a file)? Sorting on that line keeps both clean.

Memory in a GTM setup

Memory in a GTM setup

For a go-to-market operator, memory is the personal layer: how you like briefs formatted, the tone you write in, the shorthand you use. Let it hold that so you stop re-specifying it. But your ICP, your positioning, your account facts, the things that must be right and shared, belong in files and Projects, where you and the team can see and version them.

Get that split right and Claude compounds without drifting: it remembers you, and it reads the team's truth from a source you control. Get it wrong, lean on memory for the shared stuff, and you get my down-market week, at scale.

So take two minutes and look at what your Claude currently remembers. Anything on that list that your whole team should agree on? Move it to a file.

💡

TipKeep the shared, must-be-right context in files; let memory hold your personal defaults. The moment a fact needs to be true for the team, it has outgrown memory.

How to set it up

How to set it up

Seed it on purpose

Do not wait for memory to guess what matters. Tell it the durable facts once, plainly:

"Remember: our ICP is VPs of Marketing at B2B SaaS companies from 50 to 500 employees, we sell an inbound demand platform, and I never use hype words in copy."

Open it and read what it holds

Go to Settings and look at what Claude has remembered about you and your work. This is the part people skip, and it is where you catch a fact that quietly went stale, an old title, a repositioned value prop, a metric that changed.

💡

TipRead your memory once a month like you would audit a required CRM field. Five minutes stops it confidently repeating something that stopped being true.

Edit and delete to steer it

When something is wrong or out of date, fix it or delete it. Steering memory is the whole skill: keep the facts that make every chat start smarter, cut the ones that would make it wrong. What is left is context you never have to re-type.

FAQ

Frequently asked questions

Does Claude remember past conversations?

With memory on, yes: it keeps facts about you and your work across chats. Without it, each conversation starts fresh. Memory is separate from a single chat's context, which is only what Claude sees in that conversation.

What is the difference between context and memory?

Context is what Claude can see for the current task, inside a fixed window. Memory is what persists across chats. Context is working memory for one job; memory is the durable record of you. Most 'it forgot' complaints are actually context, not memory.

How do I see or edit what Claude remembers?

In the memory settings you can view the stored facts and edit or delete them. If Claude keeps acting on something stale, fix the underlying entry there rather than correcting it in every chat.

Can I turn Claude's memory off?

Yes, you can disable it entirely and run with no persistence, then turn it back on when continuity helps. For sensitive or regulated work, switching it off for that session is the safe default.

Is memory shared across my team?

No. Memory is personal to your account, so your colleague's Claude does not know what yours does. For anything the team must share, use a file or a Project, which is explicit and identical for everyone.

Why did Claude confidently get a fact about my company wrong?

Usually a stale entry in memory that nobody corrected, applied with full confidence. Old trusted memory does more damage than a gap, because it asserts instead of asking. Edit the entry, and keep must-be-right facts in a file you can see.

Should I put my ICP and positioning in memory?

No, put them in files or a Project. Those facts must be right, shared, and versioned, and memory is personal and implicit. Use memory for personal defaults, files for the team's truth.

Is my data safe with memory on?

You control what it keeps and can view, edit, or delete it, or turn it off. For sensitive information, prefer files you manage and review Anthropic's current data terms rather than relying on memory.

Sources

Sources & further reading

Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.

Get the AI-for-GTM playbook in your inbox

New Claude guides, use cases, and prompts every couple of weeks.

Subscribe →