How AI Agents Remember Things When the AI Itself Has No Memory

Here’s a thing that should bother you more than it does: the AI inside your “agent” has no memory. None. Every single message it answers, it answers from a blank slate. So how does an agent that “learns from experience” actually do that?

The model is amnesiac. The agent isn’t.

An “agent” is the model plus the scaffolding around it — tools it can call, files it can read, rules it follows. The model is stateless. The scaffolding is where memory lives. Anthropic’s memory documentation describes the same idea formally: persistent behavior comes from files the model loads, not from anything the model itself retains.

The simplest, ugliest, most effective version of this is a plain text file called LEARNINGS.md (or any name you like). The agent reads it at the start of every run. It can append to it during a run. The file persists between runs because… it’s a file. That’s it. That’s the trick.

Four mechanisms a LEARNINGS.md actually captures

1. Error-driven rule addition

The agent does something wrong. You correct it. Instead of just thanking you and moving on, it appends the rule to LEARNINGS.md before continuing. Next run, it reads the file first, sees the rule, doesn’t repeat the mistake. The model still has zero memory. The file remembers for it.

2. Pattern codification

Three different runs solve similar problems with similar approaches. After the third one, the agent notices the pattern and writes it down as a reusable convention. That convention now shapes every future run. This is how an agent gets “better at your project” without anyone retraining a model.

3. Process-bug discovery

Sometimes the lesson isn’t a content rule, it’s a workflow rule. “When publishing, always verify links AFTER the post is live, not before, because internal links 404 until the post exists.” Captured once, applied forever. Your agent now has a workflow your team didn’t have to write down anywhere else.

4. API quirk documentation

Every external service has weird behavior. The WordPress REST API doesn’t accept a tag name — it wants a tag ID. The first time the agent hits that, it documents the quirk. Future runs skip the dead end.

Why this beats fancier solutions

You could build a vector database. You could fine-tune a model. You could run a RAG pipeline. None of that is wrong, and at scale they all matter. But for a single-operator workflow, a plain text file the agent reads on every turn is faster to set up, easier to debug (just open the file), and impossible to silently corrupt. You can also override it instantly — delete a rule, edit a rule, and the next run reflects the change.

The closely related pattern is the CLAUDE.md file from Claude Code — same shape, different role. CLAUDE.md is the rules you wrote on day one. LEARNINGS.md is the rules the agent has discovered for itself since. The full reasoning behind why both files exist is in the CLAUDE.md pattern.

A practical starting point

Two files at the root of your project: CLAUDE.md (rules you wrote) and LEARNINGS.md (rules the agent appends). One instruction in CLAUDE.md: “Read LEARNINGS.md at the start of every reply, and append to it whenever you discover a rule worth remembering.” That’s the whole infrastructure.

If you haven’t set up the surrounding scaffolding yet, start with the three things to set up before any long Claude project. The drift problem this prevents is described in why your AI sounds different at hour 3 than it did at hour 1.