RAG vs memory vs project knowledge in AI coding
Retrieval, memory, and a project knowledge layer are three different ways to give an AI coding session context, and they are often confused. Retrieval pulls matching text on demand. Memory carries facts forward between sessions. A project knowledge layer is the validated, structured account of how this codebase actually works. They are not interchangeable.
Three mechanisms, three jobs
The three approaches are easy to lump together because they all answer "how does the model know things." But each one answers a different question.
find matching text now
carry facts across sessions
validated account of the system
Retrieval is reactive: it responds to the current prompt by fetching similar chunks. Memory is cumulative: it remembers what was said before. A project knowledge layer is structural: it describes the system itself, not the conversation about it.
What RAG is good at, and where it stops
Retrieval is strong when the answer exists somewhere in the corpus and the question resembles the text that holds it. It is weak when the right context is not lexically similar to the prompt, when the retrieved chunk is outdated, or when the answer depends on how several files relate rather than on any single passage.
In coding, the hardest context questions are relational: which module owns this state, what invariant must hold, why this looks wrong but is correct. Retrieval rarely surfaces those well, because the answer is not sitting in a matching paragraph.
Where memory helps and where it drifts
Memory removes repetition: a fact established once does not need re-explaining. The risk is that memory records what was true when it was written, and code moves. A remembered function name, file path, or decision can quietly go stale, and a confident-but-wrong memory is worse than none.
Memory needs verification, not just recall. A fact carried forward should be checked against the current code before it is acted on, or it becomes a source of confident errors.
Why project knowledge is the layer most teams are missing
A project knowledge layer is the structured, validated answer to "how does this system actually work right now." It is assembled deliberately, checked against the real files, and reused across sessions. Retrieval can feed it. Memory can reference it. But it is the layer that makes the other two reliable, because it is the one that is kept true.
The practical version is not a wiki nobody updates. It is context that is compiled per task, validated against the repo, and carried forward as proof rather than as an unverified note.
How Avorelo helps
Avorelo treats project knowledge as a first-class layer. It assembles the relevant context for each task, validates it against the real files rather than trusting a stale note, and carries the verified result forward in the session receipt. Retrieval and memory become inputs to that layer instead of competing substitutes for it.