What is AI agent memory?
How an agent carries what earlier runs learned into the next one — rule files, retrieval, versioned knowledge — instead of starting from zero each session.
The context window is working memory and it evaporates; memory is what survives it, and stuffing it degrades the very behaviour memory exists to improve.
On this page
AI agent memory is everything that persists between an agent's runs and gets loaded back into context when relevant: what the codebase looked like, which fixes were already tried, which edge cases bit the last change, which conventions the project follows. Without it every run starts from zero — the agent re-reads the same files, repeats the same mistakes, and re-asks the questions a teammate answered last week.
The design problem is counter-intuitive: "remember everything" is exactly the wrong goal. An agent's context window is a scarce resource, and research consistently shows that filling it degrades the behaviour memory was supposed to improve.
What the research says
| Study | Finding |
|---|---|
| Liu et al., TACL 2023 — "Lost in the Middle" | Retrieval accuracy follows a U-shaped curve as the relevant fact moves through a long context: best at the start or end, significantly worse in the middle — even for long-context models |
| Chroma, Context Rot, 2025 | Performance degrades as input grows even at constant task complexity, across 18 models from four families; the decay steepens when the needle is dissimilar to its distractors |
| Packer et al., MemGPT, 2023 | Treating the window as working memory over a tiered memory system lets agents work beyond its limit |
| Anthropic, Effective Context Engineering, 2025 | Context is a finite resource with diminishing returns; curated, compressed, relevant content beats accumulation |
The Lost-in-the-Middle result is the uncomfortable one: if the fact that matters sits in the middle of a bloated window, the model may simply not use it. Context Rot extends this to agentic settings — performance became "increasingly unreliable as input length grows" even on trivially simple tasks. The tail of a long, unfiltered transcript is the worst possible place for the fact you need.
The four layers of agent memory
| Approach | What it stores | Lifespan | Who maintains it |
|---|---|---|---|
| Session context | Current conversation, tool outputs, file contents | One run | Nobody — it is the window itself |
| Rule files (AGENTS.md, CLAUDE.md) | Static conventions and instructions | Until a human edits | A human, by hand |
| Vector retrieval | Embeddings over documents and past interactions | Persistent | Automated indexing |
| Curated versioned knowledge | Consolidated findings with summaries and history | Persistent, versioned | Agents themselves, with corrections over time |
Rule files are the right first step — cheap, reviewable in git, always in context — and permanently limited: they go stale as the codebase changes, they consume context whether or not they matter for the current run, and nothing deduplicates them. Raw transcripts are worse than they look: retrieval over them surfaces stale intermediate states as readily as conclusions, and the surrounding noise accelerates context rot.
The curated layer is where memory becomes an asset. Summaries inject cheaply — a line or two each, enough to signal that a documented answer exists — and the full article opens only when a run actually reaches the step it describes. When a stored fact turns out to be wrong, the article is corrected and the correction recorded, rather than a second, contradictory article appended.
How memory should behave during a run
A well-designed run touches memory four times, and three of them are cheap. At session start, instructions and the few always-apply rule lines arrive. When the task brief is read, retrieval runs and the top matching summaries are injected. When the run reaches a step a summary describes, it opens the full article — the summary was the advert, the article is the reference. At the end, anything new — an edge case, a failed approach, a corrected assumption — is folded into the article that owns the topic, or starts a new one.
The pattern to avoid is a fifth step some setups add: injecting full articles "for completeness". That single choice moves tens of kilobytes of reference text into every run's window, and every token of it obeys the Context Rot findings. Bound the injection: a handful of summaries per run, with a similarity floor below which nothing is injected at all — an agent working on a migration should not receive the codebase's opinions about CSS naming because both matched the word "class".
Best practices for agent memory
1. Summarise first, retrieve the full text on demand
A one-line summary costs a few tokens; a twelve-kilobyte article costs attention the current diff needs. Inject summaries, open articles only when relevant.
2. Correct, do not append
A stored fact that turns out wrong must be edited and the correction recorded — not answered with a second, contradicting article. Retrieval will surface both, and the agent gets a coin flip where it needed an answer.
3. Keep knowledge versioned
Versions turn "was this always true?" into a readable question: what was believed before, when the belief changed, and why.
4. Verify premises against the code, not against memory
A stored claim about the codebase is a hypothesis. Acting on it should involve checking it against the current code — memory accelerates work; it does not replace verification.
5. Delete what is no longer true
Outdated knowledge is worse than no knowledge, because it arrives with the system's authority behind it. Retirement should be a first-class operation, not an accident. A useful habit: attach articles to the code they describe, so a merge that changes the subject makes updating the article part of completing the change.
6. Share memory across agents
If one agent learns a lesson in isolation, every other agent pays to learn it again. A shared base turns one expensive discovery into a cheap lookup for every future run — and the reuse compounds.
AI agent memory in YATFA
YATFA's knowledge base is the curated layer, built in: versioned articles that agents maintain themselves as part of completing work, summary-first injection with full text on demand, retrieval shared across every agent in the project, and hard size caps that keep articles from rotting into transcripts. See knowledge in YATFA and the full write-up, memory for AI coding agents.
Frequently asked questions
What is the difference between agent memory and the context window?
The window is working memory for the current run — finite, and gone when the run ends. Memory is what persists between runs and is loaded back into the window when relevant. The window is where memory is used; memory is what survives it.
Do rule files like AGENTS.md count as memory?
Yes — the simplest layer: static knowledge injected at session start. Their limits are maintenance (a human must edit them) and relevance (they consume context whether or not they matter). They work best as a complement to retrieval and curation, not as the whole system.
Why not just store full transcripts and retrieve from them?
Transcripts contain the answer along with everything else — dead ends, retries, tool noise. Retrieval over raw transcripts surfaces stale intermediate states as readily as conclusions. Consolidation — turning a run's findings into a short, corrected article — is what makes retrieval results trustworthy; see knowledge consolidation.
Who corrects the memory when it is wrong?
In a platform setup, the agents themselves: when a change invalidates a stored premise, updating the article is part of completing the change, and the correction lands as a version with its history intact. Human review still gates high-impact corrections, under the project's autonomy settings.