How Claude Memory actually works — and how to use it

Claude Memory solves a specific problem: every Claude conversation, by default, starts from scratch. Claude does not know who you are, what you have worked on before, or what you care about. Memory changes that — it allows Claude to retain information across sessions, building up context over time rather than starting fresh every time.

Understanding how it actually works prevents the disappointment of expecting too much, and the underuse that comes from expecting too little.

What Memory stores and when

Memory is not automatic recall of everything Claude has ever seen. It is a set of facts Claude has explicitly noted and stored — typically triggered when you or Claude identifies something worth remembering.

Things Memory is designed to hold:

• Facts about you: your role, preferences, how you like to work
• Facts about your organisation: company name, key context, ongoing projects
• Preferences about how Claude should behave with you: tone preferences, formatting preferences, things to avoid
• Ongoing context: a project you are working on, a decision you are tracking

Memory is personal — it is scoped to your account, not shared across a team. If you set up Memory with your preferences, your colleagues do not inherit them.

How to build useful Memory

Memory is most useful when you treat it deliberately rather than hoping Claude automatically retains the right things.

At the start of a relationship with Claude, you can explicitly ask it to remember key context:

• "Remember that I am a head of product at a 50-person SaaS company."
• "Remember that I prefer bullet-point summaries over prose paragraphs."
• "Remember that when I ask for a draft, I want three options, not one."

These instructions persist. Future conversations start with Claude already knowing these things.

You can also ask Claude to recall what it remembers: "What do you know about me?" gives you a clear picture of what is stored and what you might want to add or correct.

What Memory does not solve

Memory is not a knowledge base. Memory stores facts and preferences, not documents. If you want Claude to reference your company's product documentation, that belongs in a Project's uploaded files — not Memory. Memory is for persistent context about you and how you work; Projects are for domain knowledge about your work.

Memory is not a conversation history. Claude does not remember the specific content of past conversations through Memory — it remembers facts that were explicitly stored. If you had a detailed strategic discussion last week, Memory will not let Claude reference that conversation unless you explicitly extracted key points and asked it to remember them.

Memory resets are possible. If Memory is producing wrong or outdated information, you can ask Claude to forget specific things: "Forget that I am the head of product — I've changed roles." Keeping Memory accurate is an ongoing task, not a one-time setup.

Memory for individuals vs. teams

Memory is fundamentally an individual feature. It personalises Claude for one person's way of working.

For team consistency — everyone getting the same baseline context — Projects with well-configured system prompts are the right tool. Memory adds personalisation on top of that: a CS rep might have individual Memory that tells Claude their preferred communication style, layered on top of a CS Project that gives everyone the same product knowledge.

Think of it as: Project = team context, Memory = individual personalisation.

The practical pattern

Set up Memory early with the four or five facts about yourself and your work that would most change how Claude interacts with you. Review it quarterly. Use it primarily for how you like to work, not for what you are working on (projects come and go — Memory is for the more persistent stuff).

For teams, do not rely on Memory for consistency. That is Projects' job. Memory is the layer that makes Claude feel like it knows you — useful, but not the foundation of team deployment.