> [!question] Lingering Questions > - Who reviews what enters the field guide? If the agent distills its own lessons unreviewed, a misdiagnosed correction becomes durable instruction — an error that compounds instead of washing out. > - How do you prune? Nothing in the technique removes entries, and a guide that only grows will eventually contain contradictions the agent resolves arbitrarily. > - Is a field guide a security boundary? It's instruction an agent obeys — in a shared repo, who can write to it, and does review treat it like CI config or like a README? > [!tip] Article Ideas > - "Are my MOCs routers or summaries?" — `init.md` (links + one-line descriptions, optimized for routing) is structurally identical to a Konik MOC. Test whether this vault's MOCs are currently written as routers or as summaries, and whether that's the less useful shape for both agents and me. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Raw Provenance and Distilled Guidance Serve Different Memory Jobs]] — the claim this note promotes > - [[3. Resources/Permanent Notes/Capable Models Need Fewer Constraints Not More]] — same context-budget concern from a different source, same week > [!quote] Vocabulary > - *field guide* — the author's term for a directory of agent-distilled, generalized (not raw) corrections, indexed rather than preloaded > - *init.md* — a routing file of links plus one-line descriptions, read first so the agent fetches only relevant guide entries instead of loading the whole corpus ## Bib capsule ThePrimeagen posted a short field-note describing a personal workflow, adapted from Cursor's rules-file practice, for making coding-agent corrections persist across sessions: log every exchange with its commit hash, have the agent periodically distill generalized lessons into a separate field-guide directory, and index that directory behind an `init.md` so the agent retrieves entries on demand instead of preloading everything. ## Author's thesis Corrections given to a coding agent evaporate when the session ends because they're treated as conversational exhaust rather than as an artifact to maintain; separating the raw interaction log from a distilled, indexed guide fixes the persistence problem without blowing the context budget the guide was meant to save. ## Key arguments (≤3) 1. **Distillation, not accumulation, is the actual mechanism.** A raw log grows without bound and its signal density falls; a distilled guide is meant to hold only what generalizes beyond the instance that produced it. 2. **Index the knowledge base instead of preloading it** — an `init.md` of links and short descriptions lets the agent retrieve exactly what it needs via ordinary tool calls, no vector store required. 3. **Commit hashes make the log auditable, not just voluminous** — pairing each exchange with the hash of the resulting change joins instruction to outcome, turning a transcript into a checkable dataset. ## Claim atoms ### Distilled guides beat raw logs for agent memory > [!quote] ID:rw_pending > have the agent review the back and forth and the changes and come up with durable and generalized feedback Where/why: post body, third step. The separation of raw log from distilled artifact is the actual contribution — most people conflate these and end up with a file too big to load and too noisy to help. ### Index the knowledge base instead of preloading it > [!quote] ID:rw_pending > This way I don't blow the context, but instead it can do some basic tool calls and operations to find exactly what it's looking for. Where/why: post body, fourth step. Retrieval-augmented context with a table of contents and a filesystem — no embedding pipeline required. For project-scale corpora, very likely the right engineering call, and the most portable idea in the post. ### Commit hashes make the instruction log auditable > [!quote] ID:rw_pending > every single back and forth is recorded to the markdown file. Along with each commit hash for the change. Where/why: post body, second step. Easy detail to skip past — it's what turns a transcript into a dataset, joining each instruction to the diff it actually produced. ### Project-specific feedback is the right scope > [!quote] ID:rw_pending > Now the feedback is project specific, and is not universal. I am okay with that. Where/why: closing line. Reads as a limitation, functions as the design constraint keeping the artifact small and correct — most of what accumulates is local convention, and a guide attempting universality would be both enormous and wrong. ## Permanent candidates - **P1 — Externalized memory needs a router, not just a store.** Promoted below; direct structural parallel to how MOCs function (or should function) in this vault. ## Processing checklist - [x] Port claim atoms and permanent candidate from the existing deep-read notes field - [ ] Audit whether this vault's MOCs are written as routers (short descriptions optimized for deciding what to open) or as summaries — they may currently be closer to summaries, the less useful shape - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Personal Knowledge Management MOC]] ## Links - [[3. Resources/MOCs/Personal Knowledge Management MOC]] — the `init.md`-as-router pattern is a direct structural question about this vault's own MOC design - [[3. Resources/Readwise/Tweets/The “Field Guide” Technique — Persisting Agent Feedback Across Sessions|The "Field Guide" Technique — Persisting Agent Feedback Across Sessions]] — source document