How to stop your AI agent forgetting what it learned

The single most frustrating thing about building with AI agents, once you're past the novelty, is the forgetting. The agent that brilliantly untangled your auth flow on Monday has no idea any of it happened on Tuesday. You explain it again. It re-introduces a bug you already killed. You become the project's backup drive.

This isn't a flaw in the model and it won't be fixed by a smarter one. It's structural — and once you understand the two ways agents forget, the fix is straightforward.

Two ways agents forget

One: the session ends. An agent has no persistent memory between sessions. Close the laptop and everything it understood about your project evaporates. Tomorrow it wakes up blank.

Two: the context window fills. Within a single session, the agent can only hold so much at once — the context window, a finite budget. As it fills, the model degrades. It starts dropping details, losing the thread, and producing output that's confident and wrong. The phenomenon even has a name: the memory wall, where the working memory fills before the job is done and the agent keeps running on degraded information anyway.

So you lose knowledge two ways: all at once when the session ends, and gradually as the window fills mid-task.

Why chat history isn't memory

The natural assumption is that the chat is the memory — it's all right there in the scroll. It isn't, for three reasons:

• It scrolls past the window limit. Once it's out of the window, the agent can't see it.
• Nobody else can read it. Your collaborator, and tomorrow's agent, never see your chat.
• It vanishes when the session ends.

Stuart Leo

Chat history feels like memory, but it's a transcript that disappears. Real memory is something you write down where the next session will read it.

A transcript you can't rely on isn't a memory. It's a recording you'll lose.

External state as memory

Anthropic's engineers, writing about long-running agents, land on the same answer that careful builders reach on their own: keep the important state outside the model. Write intermediate findings, decisions, and progress to files. If the context compacts or the session ends, the agent re-reads those files and picks up where it left off.

That's the core move. The model's memory is a sieve — so you stop relying on it. You put the durable stuff in files the agent reads on its way in. Memory becomes something you own, in git, instead of something the model loses.

Compaction: surviving a full window

External files fix the cross-session forgetting. For the within-session kind — the window filling mid-task — the move is compaction: keeping the working set lean so the agent never hits the wall.

The practical version: don't track raw token counts, watch the fill level. Keep the original intent and the last couple of steps, summarise what's gone stale, and drop what no longer matters — before the agent starts guessing. When you sense a session getting long, have the agent write down where it's up to, then start fresh from that note. You're trading a bloated, rotting window for a short, sharp one.

The contextbase as durable memory

Put both together and you get a simple discipline: a written record the agent reads before it acts, and updates as it learns. Decisions in a file. Gotchas in a file. A few lines at the end of every session — what changed, what's verified, what's next. All committed to git.

That record is a contextbase, and it's the cure for forgetting. The next session doesn't start blank — it reads what the last one learned and starts ahead. The agent still has no memory of its own. It doesn't need one, because you built it a better one.

An agent's memory isn't in the model — it's in what you write down and commit.

Start here: see compaction in detail, what a contextbase is, or read the method.