Adding Memory to Your Agent
Give the course agent memory that lasts between sessions: what to store, where to store it, and how to load only what matters.
Tell your agent "I prefer temperatures in Fahrenheit" and it will happily comply, for exactly one run. Start it again tomorrow and it has no idea who you are. Every session begins from zero, because the only memory your agent has is the messages array, and that array is thrown away when runAgent returns.
In this lesson you'll give the agent memory that lasts between sessions. You'll decide what's worth remembering (far less than you'd think), store it in a small file you can read and edit yourself, and load only the memories that matter for each task, so memory helps the agent instead of filling its context with noise. You'll also see why memory is a security surface, and what to do about it.
Three kinds of memory
Your agent already has two kinds of memory. This lesson adds the third.
| Kind | Where it lives | Lifetime | Example |
|---|---|---|---|
| Working memory | The messages array | One run | The file it read three turns ago |
| Workspace | Files in workspace/ | Until deleted | reports/weather.md |
| Long-term memory | A memory store you manage | Across sessions | "User prefers °F" |
The workspace already persists, so why not just let the agent write notes to a file there? Two reasons. First, workspace files are the agent's output, and the agent can overwrite or delete them freely with write_file. Memory should change only through deliberate operations you control. Second, the agent would have to remember to go and read its notes, and it won't know they exist unless something tells it.
A real memory system answers three questions, which make up the rest of this lesson: what to store, where to store it, and how to load only what matters. If you want the bigger conceptual picture first, including file-based memory in tools like Claude Code, read Giving Agents Memory.