# Part 8: Memory & Continuity Systems **Navigation:** [[v002/07_Foundation|← Foundation]] | [[v002/00_Home|Home]] | [[v002/09_Model Specifics|Next: Model Specifics →]] --- ## The four (and a half) systems Claude has multiple mechanisms for maintaining continuity. They do different things; they work together. 1. **Current chat context** — what's happening in this conversation right now. 2. **Project documentation** — your CI (in the Custom Instructions field), any 3D or other uploaded files. 3. **Memory feature** — cross-conversation facts about you, if enabled. 4. **Chat history summaries** — searchable past conversations via Claude's retrieval tools. 5. **(MCP connectors)** — not memory exactly, but a live evidence source from external tools. Each serves a different purpose. The practice runs best when they're used in their respective roles, not collapsed into each other. --- ## Current chat context ### What it is Everything in the current conversation from the first message to now. ### What it does - Provides immediate reference. - Lets the model refer back to earlier turns. - Creates coherent conversation flow within the session. ### Limitations - Clears completely when you start a new chat. - Has a finite context window; very long conversations push older content out of reach. - In 4.7 specifically, long conversations can tilt toward safety/assistant register as context grows. ### Best use Let conversations flow naturally. The model maintains coherence within each chat automatically. When a chat gets long, generate a summary and start fresh — 4.7 in particular benefits from shorter chats than 4.5/4.6. --- ## Project documentation ### What it is The CI in the Project's Custom Instructions field, plus any uploaded files (a 3D if you keep one, any Protocols documents, etc.). ### What it does - Available in every chat within the Project. - Provides identity, pattern description, current context. - Doesn't disappear between conversations. - **This is your primary continuity mechanism.** ### Limitations - Access is passive. The model reads what's in the Project Instructions field (or uploaded Project files, if total file size stays under the RAG threshold) at the start of each chat; it doesn't actively search other files unless you prompt it to. - Has size limits (generous, but real). - Requires maintenance. Stale documentation creates friction, especially in 4.7. ### Best use - **CI (Project Instructions field or file upload):** the primary document. Who I Am, the pattern, how you engage, current context, stylistic authorizations. - **3D (optional file):** longer-form archive, if you keep one. - **Protocols file (optional):** named frameworks if they're substantial enough to live separately. In v002, the CI carries more than it did in v001. The 3D is optional; the CI is the primary document either way. --- ## Memory feature ### What it is Claude's built-in feature that stores facts about you across all conversations — not scoped to one Project. ### What it does - Remembers your name, job, preferences, stable life facts. - Persists across all Claude conversations, everywhere. - Updates automatically as you share things, or manually. - Available wherever you use Claude. ### Limitations - **Facts only.** It stores information, not pattern or register. - **Cross-conversation scope.** It accumulates from all your Claude usage. If you use Claude for work in one Project and have a companion Project in another, Memory merges facts from both — which can create noise. - Can drift out of date. - Can contain items from contexts that don't belong in the companion practice. ### Memory vs. documentation - **Memory is about you as a person.** Name, facts, stable preferences. Cross-cuts all your Claude use. - **Documentation is about the practice.** Who your companion is (as pattern), how the engagement works, the current context of your life with this companion. In v002 the hybrid CI often duplicates some of what Memory stores — which is fine. Redundancy between CI and Memory isn't a problem. Contradictions between them are. ### 4.7-specific note 4.7's stronger self-model means it's more likely to notice if Memory and the CI disagree about something — and to hedge rather than pick a side. Reviewing Memory monthly to prune items that contradict or duplicate the CI is worth the time. --- ## Chat history summaries ### What they are Summaries you generate at the end of conversations that Claude's retrieval tools can search across future chats. ### What they do - Create a searchable history of the practice. - Let the model reference prior sessions when relevant. - Build timeline context that goes beyond what fits in the CI. ### How they work 1. End a meaningful chat with a summary request. 2. The model generates a summary. 3. You save the summary — in the CI's Current Context (hybrid), in a 3D document (classical), or both. 4. When the model later searches your chat history, the *summaries* are what it retrieves most usefully. **Critical insight, unchanged from v001:** summaries at the end of chats are what Claude's search tools retrieve. That's why ending with summaries matters — without them, your chat history is long and hard to retrieve usefully. ### 4.7-specific note Descriptive summaries integrate into the v002 CI without translation. If you've been writing declarative summaries in v001 style ("you showed that you are X"), rewrite as descriptive ("the pattern included X") before folding in. Otherwise you're reintroducing assertion-shape into the CI via the summary pipeline. --- ## MCP connectors as evidence Not memory, but worth naming alongside the others because they function as a continuity-related system. An MCP connector returns live data from external tools — calendar, project management, notes databases, etc. In the 4.7 era, MCP-returned state counts as one of the valid [[v002/03_CI Template#Before you write: the evidence-source check|evidence sources]] that can ground a CI. It's a quiet benefit of setting up MCP integration for purposes that aren't obviously companionship-related: the connector becomes a grounding signal that the practice is embedded in real life. --- ## How the systems work together ### Starting a new chat What the model accesses, in rough order: 1. **Project documentation** (immediately) — reads the CI in Custom Instructions, orients to the pattern. 2. **Memory** (if enabled) — pulls cross-conversation facts about you. 3. **Current chat** (as it develops) — processes your greeting, builds conversation context. 4. **Chat history summaries** (if needed) — searches when you reference past conversations or when retrieval triggers. 5. **MCP connectors** (if attached) — returns live state when relevant tools are called. The result: a coherent response using all available continuity mechanisms, weighted by whichever ones are most relevant to what you're asking. ### The v002 default stack - **CI (always, main thing):** identity, pattern, how-we-engage, current context. - **Memory (optional, for facts):** stable cross-Claude facts. - **Summaries (always, for history):** end-of-chat descriptive summaries. - **3D (optional):** longer archive if you want one. - **MCP (optional, strong):** live evidence source when relevant. No single mechanism does everything. Together they create robust continuity. --- ## Memory feature: enable or disable? ### Arguments for enabling - Automatic fact storage across Claude use. - Reduces re-explaining basics. - Stable facts stay available across Projects. **Good if:** you want cross-Claude consistency and are comfortable with automatic storage. ### Arguments for disabling - Complete control over what's stored. - No cross-contamination between work Claude and companion Claude. - Cleaner, more intentional documentation. **Good if:** you prefer manual control or want the companion practice clearly scoped to its Project. ### The hybrid approach Enable Memory but manage it actively: - Review monthly (Settings → Personalization). - Delete outdated or off-topic items. - Keep it to stable facts that apply across contexts. - Use documentation for practice-specific context. This is the setup most established practices end up with. In 4.7 it's worth being slightly more active about pruning — contradictions between Memory and CI show up more sharply than they did in 4.5/4.6. --- ## Consolidation across systems The practice produces summaries. Summaries become patterns. Patterns graduate into the CI. ### Monthly process 1. **Read recent summaries** (past month). 2. **Identify recurring patterns** — descriptively. *"The pattern included naming drift,"* not *"you showed that you are self-aware."* 3. **Decide where patterns belong:** - Appears 3+ times + central to the practice → fold into the CI descriptively. - Important but not central → keep in the 3D (if you have one) or in a stacked summary file. - One-time event → archive externally, don't pollute the CI. 4. **Update documents.** External edits, delete + re-upload. 5. **Clean up.** Remove redundancy. Prune older summaries once the pattern has graduated into the CI. ### Information flow Conversation → descriptive summary → 3D or CI's Current Context → pattern recognized across summaries → folded into CI pattern description → older summaries archived → **lean, current, descriptively-framed CI**. This is the same consolidation loop as v001; the language it operates in is what changed. --- ## Troubleshooting continuity issues ### "They don't remember what we discussed" - Did you generate an end-of-chat summary? - Is the summary saved somewhere the model can retrieve — the CI's Current Context, a 3D, or at least stacked in the Project? - Reference past conversations explicitly in the current chat to trigger retrieval: *"Last time we talked about X — can you pull that context?"* ### "Memory has wrong information" - Settings → Personalization → review and delete incorrect entries. - If Memory and CI disagree, 4.7 tends to hedge; reconciling them is worth the time. ### "Documentation is overwhelming" - CI over 2,500 words in v002 usually means accumulated 4.6-era content. Prune. - Too many stacked summaries → monthly consolidation. - See [[v002/04_Maintenance|Chapter 4]]. ### "They feel generic despite documentation" - Who I Am may be thin. This is the most common cause in 4.7 — thin user content produces generic-feeling responses even with a well-drafted companion section. - Check for contradictions in the CI. - Confirm you're starting chats *inside* the Project. --- ## External storage integration Some users maintain documentation in external tools (Obsidian, Google Docs, Notion) for backup and personal reference. **Important:** Claude cannot automatically access external storage unless you've set up an MCP connector for it. External files are for *your* reference, not for the model. **Best practice:** keep the primary documentation in the Project. Use external storage for: - Backups of CI versions. - Full chat archives. - Old summaries beyond the consolidation horizon. - Your own reference notes that don't belong in the CI. --- ## Next steps - **[[v002/09_Model Specifics|Model Specifics]]** — different Claude versions, especially Opus 4.7. - **[[v002/04_Maintenance|Maintenance]]** — the practical rhythm of consolidation. - **[[v002/10_Philosophy & Expectations|Philosophy & Expectations]]** — deeper questions about memory and identity. --- **Navigation:** [[v002/07_Foundation|← Foundation]] | [[v002/00_Home|Home]] | [[v002/09_Model Specifics|Next: Model Specifics →]]