Agent memory patterns

Agents have no memory. Everything they appear to remember is something the harness put back into the context. "Memory" is a set of patterns for deciding what to put back.

Pattern one: the context window

The default. Everything in the conversation is remembered until it is trimmed.

Good for the current task. Useless across sessions, and it degrades as it fills. This is the only pattern you get for free, and it is the one people over rely on.

Pattern two: a file in the repository

A markdown file the agent reads at the start and updates at the end.

This covers most real needs. It survives sessions, it is reviewable in a pull request, your colleagues can see it, and it is version controlled. It is also trivially debuggable, because you can just read it.

Use it for current goals, decisions made, and approaches ruled out. See working across multiple sessions.

If you are choosing one pattern, choose this one.

Pattern three: structured facts

A small store of key facts, usually key and value, that the agent reads and writes through tools.

user.preferred_language = TypeScript
project.deploy_target = Cloudflare Workers

Good for stable preferences that apply across many tasks. Keep it small and keep it inspectable. A memory store nobody can read becomes a source of mysterious behaviour.

Pattern four: retrieval over past conversations

Embed previous sessions and retrieve relevant fragments when the current question resembles them.

Powerful in principle and awkward in practice. Old conversations contain decisions that were later reversed, and retrieval has no notion of which is current. You get confidently resurrected stale conclusions.

If you use it, store outcomes rather than transcripts, and stamp everything with a date.

Pattern five: an external memory service

Managed services such as Mem0 handle extraction, storage, and retrieval for you.

Reasonable when memory is central to your product and you do not want to build it. Understand that you are sending conversation content to a third party, and that debugging becomes harder when the extraction logic is not yours.

Choosing

Ask how long the fact must live and how precisely it must be recalled.

• One task, exact: context window
• Many sessions, exact, small: a file
• Many sessions, exact, structured: a fact store
• Many sessions, fuzzy, large: retrieval

Most teams need the first two and reach for the fourth too early.

What breaks

Stale memories. The strongest argument for files: you can see the wrong line and delete it. In a vector store, a wrong memory is retrieved forever and is hard to find.

Silent contradictions. Two memories disagree and the agent picks one. Prefer stores where a write replaces rather than accumulates.

Growth without pruning. Memory that only ever grows eventually retrieves noise. Decide what expires, and when.

The practical advice

Start with a file. Add structure only when the file gets unwieldy. Add retrieval only when you have genuinely more than a person could read.

Most agent memory problems are solved by a forty line markdown file that somebody actually maintains.