Agent Memory vs RAG vs Bigger Context Windows

Ask why a coding agent forgot last week's architecture decision and you will get three different answers: use a model with a bigger context window, wire up RAG over your docs, or add a memory layer. They sound like three routes to the same destination. They are not. A context window is a buffer for one session, retrieval is a search over documents someone already wrote, and memory is a store of facts somebody decided were worth keeping. Pick the wrong one for your symptom and the agent still starts cold on Monday.

The comparison below covers mechanisms rather than products, because the useful question is which layer your missing context should have come from.

A bigger context window is a buffer, not a memory

The context window holds the tokens the model can see on the current call: the conversation so far, the files that have been read, tool results, and the instructions loaded at startup. It grows by appending. Nothing in it is chosen for durability, because nothing in it is chosen at all.

When the session approaches the limit, the agent harness has to make room. In Claude Code, /compact frees up context by summarizing the conversation so far, and the documentation says it "replaces the conversation with a structured summary." The automatic pass works the same way. After it runs, what remains in context is the startup content, a structured summary of the conversation, the files modified most recently, and the body of each skill that was invoked. The raw history is gone.

A larger window buys more room before that happens. It does not change what happens. Anthropic's documentation says that on the 1 million token window available on Sonnet 5 and other recent models, "compaction works the same way at the larger limit." And /clear starts a new conversation with empty context when you switch tasks.

So window size is a capacity number, not a memory architecture. A bigger buffer has no rule for noticing that your team rejected a library, no place to put the reason, and no way to hand either to tomorrow's session. Every mechanism that survives a session boundary lives somewhere else.

RAG retrieves documents, it does not decide what is worth keeping

Retrieval-augmented generation gives the agent selective access to a corpus it is not holding in context. An ingestion pipeline splits documents, tickets, or code into chunks and indexes them. When a query arrives, a retriever pulls the few chunks that look relevant and puts those in the window for that one request. Everything else stays out.

Selective retrieval solves a real problem, and it has a specific blind spot. Retrieval ranks documents by how well they match the query, and a superseded architecture note can match a query beautifully. The model answers from it confidently, because nothing in the retrieval step carries a signal that a later decision replaced it. You can add version metadata, recency weighting, and removal rules, but you are adding them around the mechanism rather than getting them from it.

The deeper limit is upstream. RAG can retrieve a document recording why your team dropped a dependency, but only if somebody wrote that document and something indexed it. Retrieval has no opinion about what should have been written down. A decision settled in a code review and never written anywhere is an absence, not a retrieval failure.

Persistent memory keeps facts, but not always your team's facts

A memory layer stores extracted facts rather than whole documents or whole conversations: a decision, a rejected option, a constraint, the reasoning behind a fix. The runtime can inject relevant entries at session start or when a related task comes up, which is why memory tends to show up without being asked for, while retrieval waits for a query.

Curation is the hard part and the part that distinguishes implementations. A memory store is only as useful as its rules for resolving facts that conflict, replacing decisions that were reversed, and dropping detail that stopped being true. Storage alone gives you an append-only pile that ages badly.

Scope is the second variable, and it is the one teams overlook. A stored fact may belong to one user, one agent, one project, or a shared workspace. The category label tells you nothing about which choice a given tool makes. Before adopting a memory layer, Mem0, Zep and Cognee included, check whether a fact your agent learns today is readable by a teammate's agent tomorrow, or whether it lives under your account.

Repository files like AGENTS.md and CLAUDE.md are a related but distinct approach. Git shares them with everyone who has the repository, so their scope is settled. What they lack is the curation half: a committed file does not notice that its build command was renamed. Coding agents read a stale instruction file with exactly the confidence they read a current one, which is why a stale AGENTS.md is worse than no AGENTS.md. Persistence becomes memory only when something keeps the stored facts current.

What each mechanism stores, when it runs, and what it misses

The cost shapes differ too. A context window costs tokens on every call, retrieval costs indexing and search infrastructure, and a memory layer costs the extraction and storage of durable facts.

Match the symptom to the mechanism

Start from the failure you have. A bigger context window does not fix any of these, because all four cross a session boundary.

A memory layer can solve three of the four, if it captures the right facts. The fourth is about who can read what persisted, not about persistence.

The gap all three leave: memory that belongs to the repository

Look at what the three mechanisms sort on. Every one of them answers how long knowledge survives. None of them answers who can reach it. A context window belongs to a session. A RAG corpus can serve a whole organization, but it usually indexes published documents rather than the decisions made while the code is being written. A memory layer holds those decisions, and who can read them depends on how it was scoped.

Scope is a separate axis from persistence, and teams building their own setup tend to answer it the same way. In our webinar on where agent memory lives, Dosu CEO Devin Stein said putting knowledge in the Git repo is by far the most common thing Dosu sees when teams build something custom. Agents can reach it with bash, so there is no search layer to build, and your team works there every day. Git also gives you versioning, which the survey paper behind the series does not cover but which production knowledge needs, because you want the historical record of what changed and the ability to rewind it.

Git carries a second property worth naming, because it matches how engineering work happens: knowledge branches. Some of what you learned this morning is true on your branch and not yet true for anyone else, and it should stay scoped there until the work merges and reconciles into what the organization knows.

Where the repository runs out is maintenance. In the same conversation, Stein called current Git workflows heavy on human intervention to keep information updated, which makes the repo a great place to start and a poor place to stop. Version control distributes knowledge and preserves its history. It does not notice when a line in it stopped being true.

Keeping repository knowledge true is the gap Dosu is built for. Dosu captures engineering knowledge from the work your team does and maintains repository-scoped context that coding agents read over MCP and the Dosu CLI. When an agent saves a note with write_knowledge, the note is append-only. If the repository is connected to the Library, the note is scoped to that repository and branch, and other members of the Library can read it. Access follows the Library, so an agent retrieves only from the Libraries an administrator connected it to. Dosu also generates and maintains AGENTS.md, README.md, architecture.md, and deps.md, and for documentation stored in git, accepted updates can produce a documentation pull request. Dosu is SOC 2 Type II compliant.

Where is the line? Dosu does not maintain CLAUDE.md or .cursor/rules. Recent versions of Claude Code read AGENTS.md directly when a repository has no CLAUDE.md. If your team keeps a CLAUDE.md, import AGENTS.md from it so both tools read the same maintained file. And Dosu is infrastructure for engineering teams using coding agents, not a memory API for building them. If you are shipping a product that needs per-user personalization memory, the memory layers above are the right category and Dosu is not.

Shared context can reduce repeated investigation, though how much depends on the task and on whether the retrieved context is relevant to it.

FAQ

Can you use all three together?

Yes. They operate at different layers: the window holds active work, retrieval reaches documents nobody loaded, and memory carries decisions across session boundaries. Using all three is not redundancy, because each one does a different job.

Does a bigger context window remove the need for RAG or memory?

No. Extra capacity cannot surface a document that was never loaded, and it does not survive the end of a session. On a 1 million token window, compaction works the same way it does on a smaller one. A bigger window delays compaction without changing what compaction keeps.

Why does my agent still suggest a library we rejected, even with RAG connected?

Usually one of two reasons. The rejection was never written anywhere the index could reach, so retrieval has nothing to find. Or it was written, but an older document recommending the library matches the query better and ranks above it. Retrieval ranks by similarity, not by which document is current.

Does agent memory replace documentation?

No, and they degrade differently. Memory is good at recent working decisions and rejected options. Documentation is better for stable architecture, interfaces, and procedures that a new engineer reads front to back. Teams usually need both, and both need someone or something keeping them current.

Is a CLAUDE.md or AGENTS.md file a memory system?

It is shared persistence without curation. Git distributes it to everyone with the repository, but the file has no mechanism for noticing that what it says stopped being true. An instruction file is a good place to put maintained knowledge and a risky place to put knowledge nobody maintains.

See what your agent starts from

Open Claude Code in a repository your team works in daily and run /context. Look at what loaded before you typed anything, then read the instruction files it lists and mark every line that no longer matches the code. That list is the context your agents are currently working from, and the marked lines are what they will follow anyway.

If the answer is that each developer's agent is rebuilding the same context privately, the missing layer is repository-scoped and maintained. Install the Dosu CLI:

curl -fsSL https://cli.dosu.dev/install | sh

Then connect your first repo to Dosu and let the next session start from what your team has worked out.