Your own memory bank – why keep one next to auto-memory

Auto-memory takes notes in the background on whatever it finds useful: that you prefer short answers, that the invoices live in this folder, that you have now reported the same fix twice. Nobody dictates any of it, and it doesn’t ask permission before writing something down – which is exactly why it is convenient.

There is a catch, though. The facts you actually care about land there only if Claude Code judges them worth saving, or if you ask for them by name. So it pays to keep your own memory bank alongside it – a folder of files the AI creates and fills in at your dictation, plus a clear split between what belongs there and what stays with auto-memory.

What a memory bank is – and how it differs from auto-memory

Your own memory bank is a handful of Markdown files in the folder where you work, plus one line in CLAUDE.md telling Claude Code what is in those files and when to open them. No switch in the settings turns this on; you ask Claude Code to build it.

In our workshops we simply call the folder data. That name is a suggestion, not a requirement – call yours something else and nothing breaks. What counts is what goes inside, and for us that is four files:

• profile.md – who you are, what you do and how you work; that one file has a lesson of its own, built around an eighteen-question interview
• offer.md – what you sell and on what terms
• customer-persona.md – not a real person, a general portrait of the customer your offer is aimed at
• day-plan.md – your goals and the tasks in front of you

The bank is easy to confuse with your working files: an order spreadsheet, a report out of some system, an export from the accountant. None of that is memory and none of it goes in. The bank holds what should still be true tomorrow and in six months. A file full of data to process stays where it was.

Claude Code builds the whole bank for you, when you ask:

In the folder we are in right now, create a subfolder for my permanent data, with a separate file for each topic: who I am and what I do, what I sell, who my customer is, and what my plan for the coming quarter is. I'll dictate the contents of each file later. Also add a line to CLAUDE.md saying what is in those files and when to reach for them. Show me the file names and that line first, and save nothing until I say yes.

Back comes a set of proposed names, empty files and one line for CLAUDE.md, along the lines of “my permanent data lives in the data folder – read the relevant file whenever you need to know who I am or what I sell”. That line is the important part here, because CLAUDE.md is read at the start of every conversation, while the files in the bank get opened only once Claude Code sees a reason to.

Two kinds of memory bank: one global, one per project

Start with a single, global bank. Put it in your main working folder and let it hold the facts that hold regardless of what you happen to be working on. Claude Code reads CLAUDE.md not only from the folder you launch it in but from the folders above it too, so a line written high up applies to everything underneath.

A project bank replaces nothing; it adds to the global one in a single place. Create it once a client or a project starts carrying facts of its own that would only get in the way higher up: its deadlines, its decisions, its own words for things. Two banks mean two things to maintain, so the second one wants a reason.

A memory bank has no ceiling to run into

Auto-memory keeps a table of contents – the MEMORY.md file. At the start of a conversation Claude Code loads its first 200 lines or its first 25 kilobytes, whichever boundary comes first, and reads no further. As the index approaches that boundary, Claude Code gets a signal to trim it.

The mechanism works; it is the AI that decides what drops out of the full index. Your own bank has no single index to squeeze – it grows the way you split it into files by topic. A new client gets a file rather than a line on a list with a ceiling.

A limit exists here too, in a different place. The line in CLAUDE.md that points at the bank has to stay short, because CLAUDE.md is loaded in full every time – the documentation recommends keeping it under 200 lines, since the longer it gets, the less consistently Claude Code follows it.

Your bank moves between computers; auto-memory doesn’t

Auto-memory is local, and the documentation says so outright: those files are not shared between machines or with cloud environments. They sit in the Claude Code configuration folder in your home directory – away from your documents, in a place that usually stays behind on the old machine when you move your work to a new one.

Your own bank lives where you work, so it travels with everything else. Whatever syncs that folder, a cloud drive or a GitHub repository, carries the bank along, and on the second computer Claude Code finds the same facts and the same line in CLAUDE.md. If you work on a laptop and a desktop both, that is the difference between one body of knowledge and two that drift apart.

Four layers of memory, not two choices

Every file in the bank is created and filled in by Claude Code – you say what should be in it. What separates the layers is not who does the typing but who decides on an entry, and when.

Two layers are already on the table:

Auto-memory decides on its own initiative and asks nothing. You don’t steer it.

The fact files in your bank – profile, offer, persona, plan – hold what you dictate explicitly: “add to my profile that I work mostly with bookkeeping firms”. The decision is yours; the AI just writes it down.

Time to add two more, which behave a little like auto-memory: Claude Code composes the content itself, without you supplying the wording, but only when you explicitly tell it to.

The record of your work with the AI splits into two kinds of entry. The changelog is a single file, a register of what happened to your files: Claude Code appends a dated entry saying what was created since the last save, what changed and what the change was. Conversation history is a whole folder, holding a short summary of each session – what it was about, what you settled, what came of it. Those summaries sit separately because the AI writes one per conversation and names the file after that conversation’s identifier.

The neatest way to get both is a skill – a set of instructions in a separate file that Claude Code reaches for when it recognises a matching request. How such a file comes about, step by step, is the lesson built around a morning plan. Here one short word triggers it: in our example the word “save”, though you can agree on another – “goodbye”, say, or “that’s it for today”.

In the data folder, create an empty file changelog.md and a subfolder conversation-history. Then write a skill that runs when I type "save". It should do two things. First, add a dated entry at the top of data/changelog.md saying which files were created or changed since the last save and what the change was. Second, save a short summary of our conversation in the data/conversation-history folder, in a file named after this conversation's identifier – if that file already exists, update it instead of creating a second one. Show me what goes into the skill before you save it.

Claude Code shows you the skill’s contents and where it should live, and saves it only once you agree. From then on, one word in the conversation is enough to close the working day.

Passwords and client data belong in no layer at all

The “save” skill you just built summarises entire conversations – and a conversation can easily contain a password for an admin panel or an account number.

All four layers of memory are ordinary Markdown text files with nothing encrypted in them, which is why sensitive data must never reach any of them.

So the skill needs one more instruction:

Add a safety rule to the "save" skill. Never write passwords, API keys, account numbers or my clients' personal data into the changelog or into the conversation history. Leave them out even when they came up in the conversation, and in place of such a value put a short note about the kind of information that was there (instead of a password, for instance, write only that a password was given). Before you change anything, show me the wording you're going to add to the skill.

The note is what lets you know, a month later, that the conversation was about setting up access to some service, even though the skill kept none of the credentials.

Hand the choice of layer to the “save” skill

Choosing a layer isn’t hard. An observation about how you like to work stays with auto-memory. A standing fact about you, your offer, your customers or your plans belongs in a fact file. A change in your files goes to the changelog, and what you settled in conversation goes to the history. But there is no point deciding this yourself every time, or repeating the same rule to the AI at every save – dictate it once and the skill you already have applies it for you.

Add an instruction to the "save" skill saying where each type of information goes. Observations about how I work and what I prefer – leave those in your built-in auto-memory, don't move them into my files. A standing fact about me, my offer, my customers or my plans – add it to the right file in the data folder. The information that a file was created or changed – put it in data/changelog.md. What we settled in conversation – into the summary in the data/conversation-history folder. Passwords, API keys, account numbers and my clients' personal data – nowhere. Show me the instruction you'll add to the skill before you save it.

From that point on, “where should this go” is a question Claude Code answers for itself.

Conversation history when you work on a single project

One client’s work has no business mixing with everything else: not their file changes in the global changelog, not your conversations about them in the global history. Where the folder you work in has a project bank of its own, that is where the changelog and the history folder belong. At the moment of the first save such a bank usually doesn’t exist yet, so let the skill ask about creating it:

Extend the "save" skill with project memory. If the folder we are working in already has its own memory bank, write the changelog and this conversation's history there. If it doesn't, ask me whether to create one. If I agree, create it and save into it. If I decline, save the changelog and the summary in the global bank, note my refusal in this project's CLAUDE.md file, and don't ask me again. Describe first how that question will look in practice.

The first “save” in a new project therefore ends with a single question: do we set up a bank here. You answer once. Say yes and Claude Code creates it; say no and your answer goes into the project’s CLAUDE.md – and it is that entry that keeps the question from coming back at the next save.

Growing the bank once the files pile up

Plain Markdown files are the simplest way to store all this, and for a start they are entirely enough. After a year of work, though, the history folder holds several hundred files and two things start to grate. Going through them by hand stops being realistic, and the AI opens only the ones it considers relevant to your question. On top of that, files are searched by word, while what you remember is the gist of a conversation, not its exact phrasing.

What follows is a direction, not a recipe – each of these is a post in its own right.

A database instead of Markdown files. Entries in a database aren’t scattered across hundreds of files; they sit in one place, ordered by the same rules: date, client, topic. That order is the whole difference. Finding one thing no longer means looking through everything else, so searching stays fast instead of slowing down with every new note.

Semantic search, also known as a RAG index. Ordinary search finds the word you typed and nothing else. Semantic search understands what you are asking about. Say you need what was said about a client leaving. Without a RAG index the AI can only go through your notes looking for the word “churn” – and in our example it finds nothing, because that word never came up: what you wrote at the time was “the client didn’t renew”. A RAG index describes each note by its meaning rather than by the words standing in it, so “churn” and “didn’t renew” amount to the same thing, and the question about a client leaving reaches the right conversation.

At the start, think about neither. A memory bank of a dozen or so files needs nothing of the kind. When the files do stop being enough, come back here, point your AI agent at this section and ask whether it is a sensible way to grow your bank.

In short

Auto-memory and your own bank divide the work between them. Auto-memory gathers observations by itself, in the background; the bank holds what has to be certain – the facts you dictate, plus the file changes and conversation summaries that Claude Code writes only when you tell it to.

You start with one global bank and add a project one when a single client asks for a place of their own. The rule for choosing a layer is worth locking into a skill – because in this arrangement the only memory that still fails is yours.