Build a memory system that survives across sessions with Fable 5: write, consolidate, recall, apply

Every AI agent you have ever used has the same design flaw.

It is brilliant for exactly one session. Then you close the tab, and the next time you open it, it has learned nothing. Not the bug it spent an hour chasing yesterday. Not the approach you confirmed worked. Not the mistake it made twice in the same afternoon. It starts from zero, every single time, forever.

This is not a Fable 5 problem specifically. It is the default state of every model without a memory system built around it. What changes with Fable 5 is that Anthropic actually published a real, structured way to fix this, and almost nobody has implemented it properly.

The framework is four words. Write. Consolidate. Recall. Apply. This article is the complete build, with the exact prompts, the exact file structure, and the failure modes that break it if you skip a step.

Why Most "Memory" Setups Don't Actually Work

Before the build, understand why the obvious approach fails, because almost everyone tries it first and gets burned.

The obvious approach is to just save everything. Every conversation, every decision, every mistake, dumped into one growing log file. This feels like memory. It is not. It is a transcript, and a transcript is not knowledge.

Here is the problem in practice. After three weeks, that log file is thousands of lines long. When a new session starts and Fable 5 tries to use it as context, one of two things happens. Either the file is too large to meaningfully process and gets truncated, so the model only sees the most recent entries and loses everything earlier. Or the model does process the whole thing and wastes enormous context reading through raw, unstructured history to find the one relevant lesson buried in line 847.

Real memory is not a bigger transcript. It is compression. The goal is not to remember everything that happened. It is to extract the small number of things worth carrying forward, in a form dense enough that recalling them costs almost nothing.

That is exactly what the write, consolidate, recall, apply structure does, and it is why it works where a raw log does not.

The Four Parts, In Order

Part 1: Write

This is the capture step, and it happens during or immediately after a work session. The goal is not to write a summary of everything that happened. It is to write down specifically what was learned, what was corrected, and what was confirmed, along with why each one mattered.

The critical discipline here, and the one almost everyone skips, is that you only write down what is not already recorded elsewhere. If the decision is already in your codebase, your chat history, or an existing note, writing it again is noise, not memory. Memory is for the things that would otherwise be lost. The insight that took an hour to discover. The approach that failed and why. The assumption that turned out to be wrong.

Here is the prompt to run at the end of any substantial session:

Review what we just worked on in this session. Write one memory file for
each genuinely new lesson learned, using this structure:

- One-line summary at the top (this is what gets scanned later)
- What was learned, corrected, or confirmed
- Why it mattered (what would have gone wrong without this)
- Any specific detail needed to apply it correctly next time

Only write a file if this is NOT already recorded in the codebase, the
chat history, or an existing memory file. If you are unsure whether
something is new, check the memory folder first before writing.

Save each file to /memory with a descriptive filename, not a date or
a generic name.

Notice what this prompt actively prevents. It stops Fable 5 from writing a session transcript disguised as memory. It forces a check against existing records before adding anything. And it requires the one-line summary at the top, which is the detail that makes the next two steps actually work.

Part 2: Consolidate

This is the step almost nobody does, and it is the single most important one in the entire system.

Without consolidation, your memory folder grows into exactly the problem you were trying to avoid. Twenty files after a month. Eighty after three. Many of them saying slightly different versions of the same lesson, because you learned it, then relearned a variant of it, then relearned it again from a different angle. A memory system that only ever adds is not a memory system. It is the same unstructured log problem, just split across many files instead of one.

Consolidation means periodically reviewing the raw memory files and distilling them into a small number of durable lessons. Duplicate insights get merged into one file. Lessons that turned out to be wrong or outdated get deleted entirely, not archived, deleted. The goal at the end of consolidation is fewer files with more density each, not more files.

Run this on a schedule, weekly is a reasonable cadence for most active projects:

Review every file in /memory. For files covering the same underlying
lesson, merge them into a single file that captures the most accurate,
most current version of that lesson. Delete the files you merged from.

For any lesson that has since been proven wrong, outdated, or superseded
by a better approach, delete that file entirely. Do not keep a wrong
lesson around just in case, it will get applied by mistake later.

After consolidating, list what remains: how many distinct lessons, and
confirm each one still has an accurate one-line summary at the top.

This is the step that keeps the system usable at month six instead of collapsing under its own weight. A memory folder with 15 sharp, accurate, non-redundant lessons is worth more than one with 200 files nobody has time to read.

Part 3: Recall

This is the retrieval step, and it happens at the start of a new session, before any work begins.

The mistake to avoid here is dumping the entire memory folder into context indiscriminately. That defeats the purpose of consolidation. Instead, recall should be targeted, pulling the specific lessons relevant to the task at hand, using the one-line summaries as an index to scan quickly before loading full detail on only what matters.

Before starting this task, scan the one-line summaries of every file in
/memory. Identify which lessons are actually relevant to what we are
about to do. Load the full content of only those relevant files.

If nothing in memory is relevant to this specific task, say so explicitly
rather than loading unrelated lessons just because they exist.

Then proceed with the task, applying anything relevant you just recalled.

The explicit instruction to say when nothing is relevant matters more than it looks. Without it, a model under pressure to "use its memory" will sometimes force-fit an irrelevant lesson onto a task because it feels like it should be using what it has. That produces worse output than having no memory at all, since it applies a lesson from an unrelated context.

Part 4: Apply

This is not a separate prompt so much as a discipline that runs through the whole session. Applying memory means the recalled lessons actually change behavior, not just get acknowledged and ignored.

The way to verify this is working is simple and worth building into your standard session close:

Before we finish, confirm: did anything we did in this session actually
use a lesson from memory? If yes, name which one and how it changed the
approach. If no memory was relevant, confirm that explicitly too.

This closes the loop. If a session repeatedly reports no memory was relevant when you know a directly applicable lesson exists, that is a signal your recall step is not searching correctly, or your one-line summaries are not accurately describing what each file actually contains. Fix the summary or fix the search before assuming the memory system has nothing useful to offer.

Putting It Together: The Session Structure

Here is what a full session looks like once all four parts are wired together, using Fable 5's actual capacity for long, structured autonomous work.

At the start of a session, run recall. Fable 5 scans memory summaries, loads what is relevant, states explicitly what it found or that nothing applied.

During the session, work proceeds normally, but any decision or correction that happens gets flagged internally for the write step, rather than being forgotten the moment attention moves to the next thing.

At the end of the session, run write. New lessons get captured, checked against existing memory to avoid duplication, saved with proper one-line summaries.

On a weekly cadence, independent of any single session, run consolidate. The memory folder gets reviewed, merged, and pruned.

You can combine the start and end instructions into a single standing instruction in your Claude Project or CLAUDE.md file so you never have to type them manually:

MEMORY PROTOCOL
At the start of every session: scan /memory summaries, load what is
relevant, state what was found or that nothing applied.

At the end of every session: write one file per genuinely new lesson,
checking first that it is not already recorded elsewhere. Use a one-line
summary at the top of every file.

Weekly, when asked to consolidate: merge duplicate lessons, delete
outdated ones, confirm the remaining count and their summaries.

Paste that once into your project instructions and the entire cycle runs without you having to remember any of the four steps individually going forward.

A Worked Example

To make this concrete, here is how the cycle plays out over a few weeks on a real coding project.

Week one, session three. Fable 5 spent forty minutes chasing a bug that turned out to be a race condition in how the agent handled concurrent file writes. The write step captures this as a single file: one-line summary, "concurrent writes to the same file need a lock, or later writes silently overwrite earlier ones." Full detail below covers exactly which function was affected and how the fix was implemented.

Week one, session five. A different but related issue comes up, a different race condition in a different part of the same system. Fable 5 writes a second file, similar but not identical to the first.

End of week one, consolidate runs. These two files get merged into one broader lesson about the project's concurrency pattern generally, since they are really the same underlying issue showing up twice. The merged file is now more valuable than either original, because it generalizes the pattern instead of describing two isolated incidents.

Week two, a new session touches a part of the codebase that also involves concurrent writes. Recall runs first. Fable 5 scans the memory summaries, finds the concurrency lesson, loads it, and applies the locking pattern from the start instead of rediscovering the same bug a third time.

That is the entire value of the system in one sentence. The third instance of a category of bug never happens, because the first two got compressed into a lesson that generalizes, and that lesson got surfaced automatically at exactly the moment it was relevant.

Failure Modes to Watch For

Memory grows without ever consolidating. This is the most common failure and it happens because consolidation has no natural trigger, nobody forgets to close a session, but everyone forgets a maintenance task with no deadline. Put it on an actual calendar reminder, weekly, non-negotiable, or it will not happen.

Write captures too much. If every session produces five or six memory files, something is capturing routine work instead of genuine lessons. Tighten the instruction: a memory file exists for something that would cost real time to rediscover, not for anything that happened.

Recall loads everything regardless of relevance. This defeats consolidation's whole purpose. If you notice memory files being loaded that clearly do not apply to the current task, the recall prompt needs the explicit relevance check reinforced, and check that your one-line summaries are actually descriptive enough to filter on.

Old, wrong lessons never get deleted. A lesson that was correct in March and wrong by June, because the codebase or the strategy changed, is worse than no lesson at all if it keeps getting recalled and applied. Consolidation must include active deletion, not just merging. Be as willing to remove a file as to write one.

The system works for Fable 5 but breaks the moment you switch models. If you move a task to a different model mid-project, that model needs to be told about the memory protocol explicitly too, since it is not a built-in model behavior, it is a system you built on top of any model that can read and write files.

Why This Matters More With Fable 5 Specifically

You could technically build this system around any model. It matters more here because Fable 5 is built for exactly the kind of long, autonomous, multi-session work where memory loss actually costs the most.

A quick single-turn question does not benefit much from a persistent memory system, there is nothing to carry forward. A multi-week project with dozens of sessions, hundreds of small decisions, and a codebase that keeps evolving is a completely different situation. Without memory, every session partially relitigates decisions already made. With it, each session starts from the accumulated, compressed knowledge of every session before it.

This is also where Fable 5's documented tendency to sometimes report progress before verifying it becomes relevant to the memory system directly. If you are running the audit instruction from Anthropic's broader prompting guidance, before reporting progress, audit each claim against a tool result, pair it with the write step. A lesson written down without that verification discipline risks recording something that was never actually true, which then gets consolidated, recalled, and applied with false confidence in a future session. Verification and memory are not separate concerns. A memory system is only as trustworthy as the process that fed it.

Scoping Memory Across Multiple Projects

Everything above assumes one project with one memory folder. Most people running Fable 5 seriously have several projects going at once, and mixing their memory together creates a specific, avoidable failure.

If you run one shared memory folder across a client project, your own product, and a side experiment, you get cross contamination. A lesson learned about your client's specific tech stack gets recalled and applied to your own product, where it does not fit and actively misleads the model. A pricing decision from one client gets referenced in a conversation about a different client, which is not just wrong, it is the kind of mistake that damages trust if it ever surfaces in front of the wrong person.

The fix is structural, not procedural. Give each genuinely separate context its own memory folder, scoped the same way you would scope a Claude Project. A client folder per client. A separate folder for your own internal work. A separate one again for anything experimental or exploratory where you do not want half formed lessons treated as confirmed knowledge yet.

MEMORY SCOPE
This project's memory lives ONLY in /memory for this specific context.
Do not read from or write to any other project's memory folder, even if
you have access to it in this environment.

If a lesson learned here seems broadly useful beyond this specific project,
flag it explicitly at the end of the session instead of writing it directly
into another project's memory. I will decide whether to promote it manually.

That last instruction matters. Some lessons genuinely are general, a coding pattern that works well everywhere, a prompting technique that improves any project. Those are worth promoting deliberately to a shared, cross project memory folder. But that promotion should be a human decision made once, not something the model does automatically by writing across boundaries it should not cross. Automatic cross pollination between scoped memories is how a system that felt clean and trustworthy in month one becomes confusing and unreliable by month four.

For anyone running the client project template we covered in this newsletter's coverage of Claude Projects, the pattern maps directly. One project, one memory folder, one CLAUDE.md, no exceptions. The discipline of separation is what keeps a memory system trustworthy as it scales past a single context.

Measuring Whether The System Is Actually Working

A memory system that nobody checks the value of tends to quietly stop being maintained, since the payoff is invisible unless you look for it deliberately.

Here is a simple, honest test to run monthly. Pick three sessions from the past month where memory was recalled and applied. For each one, ask directly whether the outcome would have been meaningfully different, slower, more error prone, or lower quality, without that recalled lesson. If you cannot point to a real difference in at least two of the three, the memory system is producing noise dressed up as signal, and your write step needs to be more selective about what actually counts as a lesson worth keeping.

The inverse test matters too. Look at your consolidated memory folder and ask whether there is a lesson in there you have not seen recalled or applied in a month despite working on related tasks. If so, either the lesson is not actually relevant anymore and should be deleted, or your recall step's relevance matching is missing it, which means the summary at the top of that file needs to be rewritten to be more specific and searchable.

This monthly check is the single habit that separates a memory system that compounds for a year from one that quietly rots after six weeks. Building the four part cycle is the hard part once. Auditing whether it is still earning its keep is the easy part, done consistently.

Setting This Up This Week

Start smaller than you want to. Do not build all four parts and expect them to run perfectly from day one.

Week one, just do write. At the end of every session, capture genuine lessons using the format above. Do not worry about consolidation or recall yet. Get comfortable with distinguishing a real lesson from routine work.

Week two, add recall. Start every new session by scanning what you have written so far. Notice whether it is actually useful yet, if your memory folder only has three files, recall will not feel transformative. That is expected. The value compounds.

Week three or four, run your first consolidation pass. This is usually the most eye opening step, because you will discover how much of what you wrote in week one was actually duplicate or already-recorded information that should never have been captured in the first place. Use that discovery to tighten your write instructions going forward.

By week five or six, the full cycle should be running on its own, mostly invisible, and you will notice the specific moment it pays for itself: the session where Fable 5 avoids a mistake it would have made without the lesson sitting in memory, waiting to be recalled.

That moment is the entire point. Not a system that remembers everything. A system that remembers the right things, compressed enough to actually get used, and structured well enough that using them is automatic instead of something you have to remember to do yourself.

Follow @cyrilXBT for the exact memory system templates and Claude Project setups behind everything in this article.