Treat custom rules and living documents as a RAG simulation: retrieve a small, trusted corpus at session start so the agent solutions against your decisions — not a guess rebuilt from random files.
A coding agent that “just greps the repo” is doing retrieval with no index and no ranking. It will miss the one business rule that is not visible in the file it happened to open. The fix is not a bigger context window. It is a designed corpus — rules files plus a what-document and a how-document — and the discipline to keep that corpus true.
This course walks the mechanism: what belongs in rules versus docs, how to simulate retrieval without a vector store, how stale context produces confident wrong edits, and how to compile a tiny ranker that picks the right files for a task. The labs run in this page.
Code encodes decisions. It rarely encodes why, what was rejected, or which existing flow to copy. That gap is where agents invent a second architecture.
An agent starts a session by searching. It reads a handful of files, forms a model, and starts editing. The model is locally consistent and globally incomplete. The file that would have contradicted it was never opened. You only notice after a near-duplicate helper ships, or a payment success is trusted from the client, or a migration is written without IF NOT EXISTS.
A larger prompt dump does not fix this. Pasting the whole repository into context burns the token budget on noise and still omits the decision that lived in a conversation two months ago. Retrieval is the job: given this task, which small set of trusted documents must be in context before the first edit?
Rejected alternatives, “copy this flow not that one,” and rules that exist to prevent a past outage. Those live in prose, not in a struct tag.
Grep returns string matches. It does not know that ARCHITECTURE.md is the how-document and should be read before inventing a new package.
A plausible rewrite of a pattern you already have. It compiles. It is wrong because it is a second source of truth.