Give Your Agent a Memory File: Persistent-Lesson Skills for Long-Horizon Runs

Here's a pattern every heavy agent user recognizes. You correct the agent — "no, this repo uses ISR, not force-dynamic" — it fixes the code, does great work, and the session ends. Next week, fresh session, it reaches for force-dynamic again. Not because it's careless, but because it has no memory. Every session starts from zero, and every lesson you taught evaporates when the context window closes.

Anthropic's Fable 5 prompting guidance points at the fix directly: the model "performs strongly with a markdown memory system." Give it a file to write lessons to, tell it the format, and tell it to consult that file in future sessions. Announced June 9, 2026 and built for long-horizon agentic work, Fable 5 is the kind of model you run for hours and across many sessions — exactly the regime where a memory file stops being a nicety and becomes the difference between an agent that compounds and one that forgets.

This is a skill you can build once and reuse everywhere. Let's build it right.

Key Takeaways

• Fable 5 works well with a markdown memory system — a directory of lesson files it reads at the start of a session and writes to at the end.
• One lesson per file. A one-line summary on top, the lesson below. Small, searchable, easy to delete.
• Record corrections and confirmed approaches — both "don't do X" and "X is the right way here" are worth keeping.
• Don't duplicate, and delete what's wrong. A memory file that accumulates stale or contradictory notes is worse than none.
• Package it as a reusable skill so every agent you run gets the same memory discipline for free.

Why a memory file, not a bigger context window

Fable 5 ships with a 1M-token context window. It's tempting to think memory is solved — just keep more in context. It isn't, for two reasons.

First, context doesn't survive the session. When the window closes, everything in it is gone. A 1M-token context is a big desk, not a filing cabinet; clear the desk and the papers are gone. A memory file is the filing cabinet — it persists to disk and outlives any single run.

Second, more context isn't more learning. Stuffing a transcript into the next session's prompt is expensive, noisy, and gives the model the raw material without the conclusion. A memory file stores the distilled lesson — "this repo caps serverless functions at 10 seconds; move long jobs to a background worker" — not the thousand tokens of debugging that produced it. The whole value is compression: the mistake happened once, the lesson is one line, and next time the agent reads the line instead of repeating the mistake.

This is also why the memory file plays well with everything else in the Fable 5 toolkit. It complements — rather than competes with — the model's built-in memory tool, context editing, and compaction. Those manage the live session. The memory file manages what survives between sessions.

The format Anthropic recommends

The guidance is refreshingly specific, and you should follow it literally because the specifics are what make it work:

• One lesson per file. Not one giant notes.md that grows forever. A directory of small files.
• A one-line summary at the top of each file. This is what the agent scans to decide whether a lesson is relevant, without reading every file in full.
• The lesson body below. What happened, what the right approach is, and how to apply it next time.

Here's a concrete shape for a single lesson file:

# Serverless functions time out at 10s on this host
Long-running agent turns can't live inside a request/response function here.

**What happened:** A background categorization job set maxDuration: 300
and silently timed out at 10s — the host caps execution regardless of config.

**The lesson:** Move any work that runs longer than a few seconds to a
scheduled/background job. The web tier only kicks it off and reports status.

**How to apply:** Before deploying anything that calls an external API or
runs a long loop, check whether it fits in 10s. If not, don't put it in a
function — dispatch it to a worker.

And an index file the agent maintains, so it can find lessons fast:

# Memory index
- [serverless-10s-timeout.md] — long turns can't live in a function here
- [repo-uses-isr.md] — use ISR (revalidate=N), never force-dynamic on listing pages
- [supabase-url-from-jwt.md] — no NEXT_PUBLIC_SUPABASE_URL; derive it from the key

The one-line summaries in the index are the search surface. At the start of a session the agent reads the index, spots which lessons touch the current task, and opens only those files. It scales because the agent never has to read every lesson to find the relevant one.

What to write down — and what to skip

Not everything is a lesson. A memory file that records the obvious becomes noise, and noise is what makes the agent stop reading it. Two categories are worth keeping:

• Corrections. You told the agent it was wrong and why. That's the highest-value memory there is, because left unrecorded it will recur. "This project blocks aggressive bots in middleware — always add new crawlers there, not just robots.txt."
• Confirmed approaches. You told the agent it was right, or a hard-won approach worked. Positive confirmations matter as much as corrections — they save the agent from re-deriving or second-guessing a settled decision.

And a firm rule: don't duplicate. Before writing a new lesson, check whether one already covers it — update the existing file instead of adding a near-copy. Two files that say almost the same thing force the agent to reconcile them and erode trust in the whole system.

The counterpart rule matters just as much: delete lessons that turn out to be wrong. A memory note reflects what was true when it was written. If the codebase moves and a lesson goes stale, a confidently-worded but obsolete note is worse than no note — it steers the agent wrong with authority. Treat the memory directory like code: prune it.

Finally, don't save what the repo already records. Code structure, git history, and existing docs are already available to the agent. If you're tempted to memorize one of those, ask what was non-obvious about it and save that instead.

Packaging it as a reusable skill

The real leverage is that this doesn't need to be reinvented per project. Package the memory discipline as a skill and every agent you run inherits it. A memory skill bundles three things:

1. A location convention — where the memory directory lives, so the agent always knows where to look and write.
2. The format rules — one lesson per file, one-line summary on top, index maintained, no duplicates, delete what's wrong.
3. The lifecycle instructions — read the index at the start of a session; write or update lessons at the end when something was corrected or confirmed.

That's a skill in the truest sense: a small, portable capability you install once and reuse across projects. It's exactly the kind of thing the agents channel exists to catalog, and the sort of building block that turns a one-off prompt trick into infrastructure. If you're already assembling workflows or automation loops, dropping a memory skill underneath them means the loop gets smarter every time it runs instead of repeating the same dead ends.

A quick adoption checklist

Rolling this out on a Fable 5 agent takes an afternoon:

1. Create the memory directory and an empty index file.
2. Write the skill that tells the agent the location, format, and read/write lifecycle.
3. Seed a few real lessons from corrections you already know you've had to give repeatedly.
4. Instruct the agent to read the index first every session — make it the first thing it does.
5. Instruct it to write at the end — after a correction or a confirmed approach, capture the one-line lesson.
6. Review the directory periodically and prune anything stale.

The one non-negotiable is step four. A memory file nobody reads is just a log. The value only materializes when reading the index is the agent's opening move, so the lesson from last week actually shapes the work this week.

Where this goes next

The models keep getting more capable per turn, but capability-per-turn isn't the same as competence-over-time. A brilliant agent that forgets everything between sessions will always feel a little junior — it never stops making the same class of mistake, because it never remembers making it before. A memory file is how you close that gap without a bigger model or a longer context.

Fable 5's long-horizon design is what makes this worth doing now: you're running these agents across hours and sessions, and each session is a chance to either compound what the last one learned or throw it away. Give the agent a filing cabinet, teach it the format, and tell it to read the index first. Then watch it stop reaching for force-dynamic. For where memory fits alongside the model's other behavioral shifts, start from the Fable 5 series overview, and if you're auditing prompts at the same time, the piece on refactoring prescriptive skills pairs naturally with this one.