Agent memory vs context window vs RAG
Agent memory, the context window, and RAG are three different things. What each one is, how they work together in a coding agent, and which problem each solves.
A developer asks why their coding agent forgot a rule they gave it yesterday. One answer says the context window was too small. Another says it needs memory. A third says add RAG.
All three can be right, because the terms describe different parts of one system. People mix them up constantly, and the mix-up leads to the wrong fix. This guide separates them, using Anthropic's documentation and engineering writing as the reference, checked on 5 November 2026.
The short answer
| Context window | Agent memory | RAG | |
|---|---|---|---|
| What it is | What the model can see in one request | Information stored between sessions | A way to fetch relevant text into the prompt |
| Where it lives | Inside the request | Files or a database outside the model | A search index plus the step that queries it |
| Lifespan | One session, until compacted or cleared | Until someone changes or deletes it | Each query |
| Problem it solves | Giving the model something to work with | Carrying knowledge across sessions | Choosing which stored text is relevant now |
| Fails when | It fills up or gets cluttered | Nothing loads it at the right moment | The best match is out of date |
Memory stores. Retrieval selects. The context window is where both end up, because a model can only act on what is in it.
What the context window is
The context window is everything a model can see in a single request: instructions, the conversation so far, files, and tool results, measured in tokens. Claude Code's documentation says each session begins with a fresh context window, and many current Claude models support up to 1 million tokens.
A bigger window is not the same as a better one. Anthropic's engineering post on effective context engineering describes context rot: as the number of tokens in the window grows, the model's ability to recall information from it decreases. The post calls context a finite resource with diminishing returns, and says models have an attention budget that every new token draws on.
So the window has two limits: its size, and how well the model uses what is in it.
What agent memory is
Agent memory is information kept outside the window so it survives the end of a session. Because the window starts empty every time, anything an agent should know tomorrow has to be stored somewhere and loaded back in.
In Claude Code, memory is files. CLAUDE.md files hold instructions you write. Auto memory holds notes Claude writes for itself, with a MEMORY.md index whose first 200 lines or 25KB load into the window at the start of every session. On the API side, Anthropic released a memory tool in public beta with Sonnet 4.5 that lets agents store and consult information outside the window through a file-based system.
The important word is loaded. Memory does nothing until part of it enters the window. A perfect memory store with no rule for when to load what is just a folder.
What RAG is
RAG, retrieval-augmented generation, is a technique for choosing what enters the window. A system searches a store of text, usually by embedding similarity, and adds the best matches to the prompt before the model answers. Anthropic's post describes this as embedding-based pre-inference time retrieval, and notes that many AI applications use it.
RAG doesn't make the window bigger, and it isn't memory by itself. It is a way of reading from a store. The store could be your docs, your tickets, or an agent's memory.
Its weakness is that similarity is not truth. Retrieval returns whatever was written that matches the query. An out-of-date runbook and a current one can match equally well, and the retrieval step has no way to know which one the team still believes. For more on that trade-off, see MCP vs RAG.
How they work together in a coding agent
The three are layers of one pipeline: memory and other stores hold information, retrieval picks some of it, and the window receives it.
Claude Code is a clear example. Anthropic's post describes it as a hybrid. CLAUDE.md files are loaded into the window up front at the start of each session. Then, instead of pre-indexing the codebase for RAG, Claude uses tools like glob and grep to find and read files just in time, keeping lightweight references like file paths and loading content only when needed. The post notes this avoids problems such as stale indexes.
When a session gets long, Claude Code compacts it: it summarizes the conversation and starts a fresh window with the summary. Memory files come back from disk after compaction. The conversation does not, except as the summary. That is why an instruction typed only into chat can disappear, while the same instruction in CLAUDE.md survives. For the details, see how Claude Code memory works.
Which one is your problem?
Most "my agent forgot" reports map to one of these:
| Symptom | Likely layer | Fix |
|---|---|---|
| Forgot something from yesterday's session | Memory | Write it to CLAUDE.md, auto memory, or a shared record |
| Forgot something from earlier in today's session | Context window | It was compacted away. Move it to a memory file that reloads |
| Followed an old version of a rule | Retrieval and memory | The store has stale text and nothing marks it replaced |
| Ignores a rule that is in its instructions | Context window | Too much in the window, or conflicting instructions |
| Doesn't know what a teammate decided | Memory scope | Personal memory doesn't cross people. You need shared memory |
The third row is the one more capacity and better search won't fix. When a decision changes, both the old and new versions exist somewhere. Memory stores both. Retrieval may return either. The window receives whatever it is given.
The missing property: status
What the three layers lack is a sense of which stored text is current. A memory file doesn't know it has been replaced. A retrieval index ranks by similarity, not by approval. The window can't tell an accepted decision from an abandoned idea, because both arrive as text.
For preferences and notes, that is fine. For decisions a team must follow, it is the gap. A decision needs an owner, a status, and a link to what replaced it, so that whatever loads it into the window loads the current version.
Where Lockstep fits
Lockstep is shared team memory for Claude Code that tracks that status. Decisions are captured from PRDs, Slack, and pull requests, become binding when their owner approves them, and are marked replaced when a newer version is approved. At the start of each Claude Code session, Lockstep briefs the agent on the current decisions that apply to the work, and any MCP agent can query the same record mid-session.
It isn't a general memory store or a RAG pipeline, and it doesn't replace CLAUDE.md or auto memory. Session briefings work with Claude Code today. See how it works.
Sources checked 5 November 2026
- https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- https://code.claude.com/docs/en/memory
- https://code.claude.com/docs/en/context-window
Related reading
For every Claude Code memory file and limit, read how Claude Code memory works. For retrieval versus live tools, see MCP vs RAG. For the layers of memory a coding agent uses, see the AI coding agent memory guide.
Frequently asked questions
- What is the difference between agent memory and the context window?
- The context window is the text a model can see in one request, and it starts empty in every new session. Agent memory is information stored outside the window, in files or a database, that survives between sessions and gets loaded back into the window when needed.
- Is RAG a kind of agent memory?
- No. RAG is a retrieval technique: it searches stored text and adds the relevant pieces to the prompt. Memory is a store; RAG is one way to read from a store. An agent can have memory without RAG, for example by loading a memory file at the start of every session.
- Does a bigger context window replace memory?
- No. A bigger window holds more within one session, but it still starts empty in the next one. Anthropic's engineering team also describes context rot: as the window fills, a model recalls what is in it less accurately. More room does not mean better use of it.
- How does Claude Code combine memory, context, and retrieval?
- It loads CLAUDE.md files and the start of its auto memory index into the context window at the start of each session. Then it retrieves files just in time with tools like grep and glob, instead of pre-indexing the codebase. Anthropic describes this as a hybrid approach.
Keep reading