Agent memory

A persistent store, separate from the context window, that an agent loads at the start of a session and can add to as it works, so facts and preferences survive across sessions instead of resetting when the context window does.

How it works

An agent that supports memory keeps durable memory, separate from the conversation, that it reads into context at the start of a session and can append to as it learns. Because each session begins with an empty context window, that file is the bridge: instructions a person writes once and learnings the agent records on its own both persist across sessions, so neither has to be supplied again. Writing to memory is deliberate rather than automatic for most of what matters, so a fact enters memory because someone, the agent or its operator, judged it worth carrying forward. What lives in memory is plain, human-readable text, so the persisted knowledge stays inspectable and editable rather than opaque.

Why it matters

Persistent memory is what lets an agent improve across sessions instead of starting from zero each time, carrying a team's conventions and the corrections it has already been given. The cost is that memory competes for the same budget as everything else: what a session loads from memory is read into its context window, so a store that grows without curation quietly taxes every session that loads it and crowds out the room the task itself needs. Memory also drifts, because a fact that was true when written can go stale, and an agent that trusts a stale memory is worse off than one with none, since it acts on a confident wrong premise. The value is not in storing more but in keeping a small, current, high-signal set of what genuinely has to persist.

In practice

A team rule such as always branch before committing is written once into a project memory file and loads automatically in every later session, so the agent is not told again. A learning the agent records on its own, such as a build quirk it hit and resolved, persists the same way; but once that quirk is fixed upstream the memory recording it is now misleading and has to be pruned, or the agent keeps designing around a problem that no longer exists.

Practical considerations

Memory files form a scope hierarchy from broad to narrow: an organization or user-level file carries preferences that apply across projects, while a project-level file carries conventions that belong to one repository and travel with it for everyone who works there. Human-authored memory such as a CLAUDE.md file and agent-authored memory differ in who maintains them: the first is curated by a person and changes deliberately, the second accumulates as the agent records what it learns and needs its own pruning discipline so it does not silently bloat. How much of it loads is not uniform: human-written instructions at the launch scope are read in full at the start of a session, while a larger agent-written store loads as a bounded index with individual entries recalled when relevant, so a bloated index taxes every session while a long recalled tail costs only the sessions that reach it. A file-based memory of this kind is also a distinct mechanism from a tool-based memory an agent touches only by making explicit tool calls during a request, where its stored memory enters context only through those tool calls and the model itself issues the reads and writes against a store the application manages. The practical failure mode of memory is not loss but accumulation, since stale or redundant entries are easy to add and easy to forget, so the recurring cost is review rather than initial setup.

Defined by Ready Solutions AI