What an Agent Should Remember

How cognitive science shapes my thinking about memory systems for AI agents.

I think of an AI agent's memory system as a place to keep what it learns and to find it again later.

There are a few ways to go about it. The simplest starting point is a single file. You write down what the agent should know and hand it the whole thing at the start of every session. When the file gets long, you split it into several. Either way the knowledge sits in one pile. A fact about the database next to the story of a bug you fixed in March, next to a rule about how you name things. To the file it is all just text.

The trouble is not the size of the file, or how many files there are. Nothing tells the agent that these are different kinds of knowing, good for different moments. What it needs is a taxonomy: a few distinct kinds of memory, each with its own place and its own job.

How people remember

Psychologists stopped treating memory as one thing decades ago. In 1968 Atkinson and Shiffrin described it as a set of separate stores, with information moving between them. A few years later Baddeley and Hitch looked harder at the short-term store and found it was not a shelf where things sat. It was a workspace, the place where you hold a phone number while you dial it and then let it go. They called it working memory.

The long-term side split too. Endel Tulving, in 1972, drew a line between two ways of knowing. One is knowing that something is true. Paris is the capital of France. Water freezes at zero. He called this semantic memory. The other is remembering something that happened to you, the morning you first stayed up to watch the sun come over the hills. He called this episodic memory. Later work, much of it by Larry Squire, added a third. Knowing how to do a thing, ride the bike, tie the knot, is procedural memory, and it lives apart from the other two. People with certain kinds of amnesia lose their episodes and keep their skills.

So memory has shape. Working memory for the moment. Semantic for what is true. Episodic for what happened. Procedural for how to do it. Each holds a different kind of knowledge, and each earns its keep in a different way.

The same shape, for agents

In 2023 a group of researchers at Princeton wrote a paper called Cognitive Architectures for Language Agents. They took this old map of human memory and laid it over a language model agent. An agent, they argued, needs the same kinds of memory a person does. A working memory, which is the context window, the text the model can see right now. A semantic memory of facts about its world. A procedural memory of how to carry out its tasks. An episodic memory of what it did before.

The fit is good because the problem is the same. An agent, like a person, meets more than it can hold. It has to decide what to keep, where to put it, and how to find it again.

Stephen Chin, at Neo4j, adds one more layer that the textbooks usually fold into the others. It holds the reasons behind a choice. Why this path won and the other one lost. For an agent this matters more than it first appears, because the same questions keep coming back. Have we been here before? What did we settle on, and why? Call it reasoning memory.

Here is the whole shape, and what each kind is for.

Semantic what is true
coding-conventions.md
Money is stored in integer cents, never floats.Format only at display time.
Procedural how to do it
how-to-cut-a-release.md
1. Bump the version and update the changelog.2. Tag the commit and push the tag.3. The release workflow builds and publishes.
Episodic what happened
auth-refactor.md
Moved auth to short-lived tokens. The old cookie path fought the new middleware for an hour before I saw the order was wrong.
Reasoning why we chose
database-choice.md
Chose Postgres over SQLite. We need concurrent writers and JSON queries. SQLite would have meant a rewrite within the year.
Working the session in progress
the context window

Not written down. It lives in the context window and is let go when the session ends.

For an agent that writes software, each layer has plain work to do. The semantic layer holds what the project is and how it is built. The procedural layer holds the steps for things the project does often, the way you add a migration or cut a release. The episodic layer holds the record of past work, what was tried and how it went. The reasoning layer holds the decisions, so the next person, or the next agent, does not reopen a settled question without knowing it was settled.

The part that makes it learn

A filing system is not yet a learning system. The layers, on their own, only sort what you already wrote down. The interesting part is the movement between them.

Think about how a person turns a day into knowledge. You do a hard thing, you struggle, you find the way through. That night, or that week, the specific episode fades and something general stays. You do not remember every keystroke. You remember the lesson. The episode became a fact, or a skill.

Agent systems can do the same, and the good ones do. When a piece of work ends, the agent looks back over what happened and asks what is worth keeping. A bug we hit twice becomes a rule we write down. A sequence we worked out by hand becomes a recipe. The raw episode stays as history, but its lesson moves up into the semantic and procedural layers, where the next session will find it without reading the whole story. The researchers who built agents to imitate human behavior named this step reflection. It is the same word a person would use.

a session ends
look back what did we learn?
a fact semantic
a step procedural
kept, and found again

This is what self-learning means here, and it is less magic than it sounds. The system gets better over time because experience does not stay stuck as experience. It gets read and distilled and pushed up into the kinds of memory that are cheap to use.

What does not need to last

One layer does not need to persist: working memory, the context window, the agent's scratch space for the task in front of it. It fills with half-finished thoughts and tool output and dead ends. Most of that is noise. The signal is whatever changes what the agent should know or do next time. The aim is to capture that signal without preserving all the scratch space around it. A person does not write down everything that crosses their mind while they work, and they should not. What survives the session is what was worth surviving. The rest is meant to be let go.

The engineers who built MemGPT made this concrete by borrowing an old idea from operating systems. A computer gives each program the illusion of vast memory by keeping only the active part close and paging the rest to disk. An agent can work the same way. Hold a little, in working memory. Reach for the rest when it is needed.

Why the shape is the point

Thinking of what an agent knows as several kinds of memory makes the hard questions easier to answer. What belongs? The lessons, not the noise. Where does it go? Into the layer suited to that kind of knowledge. How does the system get better? By moving up, from what happened to what is true. A store holds things. An architecture decides where they go and how they travel. That is what an agent needs in order to remember well.

Sources

Nick Van Exan

Software & Privacy

Hi, I'm Nick Van Exan, a software developer from Toronto. Currently, I work on product and technology at CodeLantern, a software development consultancy that helps teams adopt human-centred agentic workflows for safe and maintainable software.

Nick Van Exan

Writing

  1. What an Agent Should Remember 2026.06.01
  2. The End of Software Development. And Its Beginning. 2026.04.12

About

Hi, I'm Nick Van Exan, a software developer and privacy engineer based in Toronto.

I've been building things on the web for about twenty years, long enough to have been through a few complete turns of the wheel and to have strong opinions about which turns were worth making.

These days I'm focused on agentic development. I build tooling for agentic development workflows, and I help teams onboard those workflows so they can deliver safe and maintainable software. I'm a Co-Founder at CodeLantern, a small consultancy built around that work.

My career in software hasn't always followed a straight line. I started making websites in the early 2000s, and won a SXSW Web Award in 2003. I loved designing and coding applications, but after watching a bit too much Law & Order, I felt the pull towards law school (nobody's perfect). I continued working as a web developer to pay for law school, before going on to practice litigation at a big Toronto firm for a few years. In 2015, I found my way back to software development and later into the field of privacy engineering, which has now led to over a decade of consulting with startups, enterprises, and governments on how to build things that don't hurt the people using them.

When I'm not at a keyboard I'm usually out for a run, listening to jazz, obsessing over stationary, or walking my dog.

Experience

  1. Co-founder & Chief Product Officer
    CodeLantern
    2026–present
  2. Co-founder & Principal Consultant
    Fieldwork Inc.
    2015–present
  3. Product & Privacy Counsel
    Hootsuite
    2017–2018
  4. Litigation Associate
    Davies Ward Phillips & Vineberg LLP
    2011–2015
  5. Software Development Consultant
    ObjectSharp
    2002–2008

Certifications

  1. Certified Information Privacy Professional/Canada (CIPP/C)
    International Association of Privacy Professionals
    2017–present
  2. Certified Information Privacy Professional/Europe (CIPP/E)
    International Association of Privacy Professionals
    2020–present

Open Source

  1. Markdoc
    Contributor to Stripe's markdown authoring framework
    2022–present

Work together

I take on a small number of engagements each year. Areas I'm currently working on include agentic development methodology and tooling, AI governance, and privacy engineering. If you think we might have something worth working on together, send me a note: nick@vanexan.ca. I'd love to hear from you.

Colophon

Designed by
Nick Van Exan
Built with
Astro
Typeset in
Söhne · Söhne Mono, by Klim Type Foundry
Photography
Carmen Cheung
Subscribe
RSS
Tracking
None. No analytics, no cookies.

Designed mostly by not designing much.