Every Monday, Don Alfonso—a meticulous and precise notary with language—started the same. “Do not use ‘contracting parties’, use ‘the appearing parties’.” «The format is always two columns.» Claude obeyed. Tuesday too. Wednesday the same. And the following Monday… start again.
It wasn’t an AI failure. It was the natural way: each conversation was born clean, without prior context. Until Don Alfonso understood a key distinction:talking is not remembering.
The problem of starting each session from scratch
Anyone who uses Claude every day recognizes the pattern. You correct the tone, adjust the vocabulary, specify the format. Claude learns… within that conversation. The next day, it’s time to repeat everything.
This cycle not only consumes time: it generates fatigue. The feeling of training an assistant who forgets every night discourages even the most motivated users.
The solution is not to write longer prompts or repeat instructions more insistently. It is in understanding thatla persistent memoryIt is a different concept from conversation, and deserves its own space.
Conversation vs. persistent memory: two different things
A conversation is ephemeral. It is used to think, decide and resolve something specific. When it’s over, it’s over.
Persistent memory is something else. It is the space where Claude can keephow you work, not what you are doing now. As long as there is no memory, Claude behaves like someone new every time.
And that is not a failure. It is an invitation for you to teach him.
The difference is crucial: the conversation resolves the present; memory shapes the future. Confusing them is the source of 80% of the frustration with AI assistants.
MEMORY.md: the file that changed everything
Don Alfonso solved his problem with something unglamorous: a file calledMEMORY.md. Nothing magical. A well-written text file that lives in the project’s working folder.
When Claude goes to work there, he reads it. And from that moment on, apply those rules.without you having to repeat them. It’s not training. It is a reliable reference.
Don Alfonso’s file contained something as simple as:
- I use specific notarial terminology.
- I avoid generic formulas.
- The standard format is double column.
Nothing else. That was enough for Claude to stop asking him every Monday.
The four types of memory that Claude can handle
Not everything Claude remembers is the same. Separating the types well avoids disorder and errors:
1. User memory.Who you are, what you do, your technical level, stable preferences. It changes little over time. It is the foundation on which everything else is built.
2. Memoryfeedback.Repeated corrections, rules that you correct over and over again. Not on a whim, but on discretion. Every time you correct the same thing three times, it deserves to become a written rule.
3. Project report.Context of the current project, what is being done, what has been decided. This memoryyes it expires: What was true in one project may not be true in another.
4. Reference memory.Where things are, what file contains what information. Not the content: the map. Allow Claude to navigate your repository without constantly asking you for directions.
How to write a good persistent memory
A good memory is clear, concrete and stable. It is not a disaster drawer.
The common mistake is to put too much in. The more information you accumulate, the less useful it becomes, because Claude has to filter through noise to find what’s relevant.
The principles are simple:
- Write what you correct repeatedly, not what suddenly occurs to you.
- Includes only what is stable: if it can change in three months, it is not memory.
- Separate what you are (user) from what you do (project).
What you should NOT keep in memory
Not everything deserves to be remembered. Avoid putting in memory:
- Prices that change.Volatile data that makes the file outdated.
- Agendas.Temporary information that does not provide recurring value.
- Temporarily sensitive data.What is secret today may be irrelevant tomorrow.
- Half-baked decisions.What is not yet decided contaminates the context.
Memory is for stability. The changeable lives in work files. Mixing the two is the quickest route to a memory that Claude ignores because it is full of outdated information.
How to put it into practice today
The exercise is direct. Create a file called `memory_user.md`. Write down five things any AI you work with should know about you. Check if they are stable or circumstantial. Eliminate everything that may no longer be true in three months. If it hurts to erase, it probably wasn’t memory.
Start small. Three or four well-thought-out lines are worth more than twenty messy pages. You can expand over time, as you detect patterns in the corrections you repeat.
A good test: after setting your memory, open a new conversation and ask Claude to write something common. If the usual corrections are no longer needed, it has worked. If you keep fixing the same thing, check what’s missing from your file.
The litmus test is simple: if after setting up your persistent memory, you stop repeating the same corrections every Monday, it has worked.
Beyond the archive: the habit of documenting
Persistent memory is not just a file that you write once and forget. It’s a habit. Every time you correct something repeatedly, ask yourself: should this live in memory? If the answer is yes, add it.
Over time, your MEMORY.md file becomes a working representation of how you work. It is not your biography or your procedures manual. It’s the minimum set of instructions any wizard needs to help you without bothering you.
The persistent memories in Claude transform the user-assistant relationship into something closer to a real collaboration. No more repetitive instructions, no more starting from scratch. Just a stable reference that grows with you.
This is just a sample. The complete book teaches you how to turn AI into your most productive employee.
📖 Your Digital Employee
Claude and AI as your best collaborator