Scoped Memory: The Third Project Mechanism

A Third Mechanism, Not a Restatement of the Other Two

It's tempting to think a Project has two moving parts -- instructions and project knowledge -- and stop there. There is a third: Memory. Where instructions set standing behavior and project knowledge supplies documents to ground answers in, Memory carries forward *the facts a Project has already picked up from earlier sessions*, so you're not typing the same background into every new conversation the way a fresh chat would force you to.

What professionals actually store in Memory tends to be small and recurring: a stakeholder's name and role, a standing preference for how output should be formatted, the names of frequent collaborators, a constraint that applies across everything done in that Project. None of that is a document to upload, and none of it is a behavior rule to write as an instruction -- it's continuity: what the Project has already settled, so it doesn't need to be re-explained next Tuesday.

Memory Is Scoped to the Project

Memory is Project-scoped, and that isolation is the point. Context saved in one Project's Memory does not appear in a different Project's sessions, even for the same account. Practically, this means the way you draw boundaries between Projects *is* the way you draw boundaries between what Memory can see.

Consider an equity analyst covering two competing retailers, Company A and Company B. Each company's confidential modeling assumptions must never surface in work done on the other -- that's not a nice-to-have, it's the whole job. The correct setup is a separate Project for each company, so the Memory scoped to it stays separate too. Do the work in one shared Project instead, and a fact Memory picked up while analyzing Company A (an assumption, a figure, a name) can resurface in a Company B session -- exactly the leak the analyst cannot afford. Separate workstreams that must never cross belong in separate Projects, precisely because Memory will follow the same boundary.

Diagnosing Stale Memory: A Symptom, Not an Announcement

Memory never tells you it's gone stale. Nothing flags an entry as outdated -- it just keeps getting used as if it were still true, which means noticing the problem is a diagnostic skill, not something the interface hands you.

Take an HR business partner running a headcount-approvals Project. In Q1, Memory picked up "headcount requests route to Dana for approval." By Q3, that responsibility moved to a new manager after a reorg, and the Project's instructions were dutifully updated to reflect the new reporting line. Yet Claude's answers keep naming Dana as the approver. Nothing errored. Nothing looked broken. The output was fluent, confident, and wrong in a way that only someone who knows the current org chart would catch.

The tell is the same shape every time: a specific, settled-sounding fact keeps showing up in answers, but it belongs to an earlier chapter of the work, not the current one. That's different from a vague or wishy-washy answer -- it's a confidently *stated* fact that used to be correct. If you find yourself thinking "wait, that changed months ago," that's the moment to check Memory specifically, not the instructions and not the uploaded knowledge, because a fact that persists silently across sessions without being re-stated in the current conversation is exactly Memory's signature.

Which Mechanism Is This? A Diagnostic Table

When a scenario describes something "Claude already knows" or does automatically, use the source of that knowledge to sort it:

What Not to Put in Memory

The most common practical mistake isn't forgetting to use Memory -- it's using it as a catch-all for things that belong somewhere else:

• A standing rule that should apply every single time, regardless of history ("always reply under 120 words," "never promise refunds") belongs in instructions, not Memory. Memory holds facts that happened to be true; instructions hold rules that must always be enforced. Putting an enforcement rule in Memory means it's one un-reviewed edit away from silently stopping.
• Reference material with real content to ground answers in (a policy document, a pricing sheet, a contract) belongs in project knowledge as an upload, not as a Memory note summarizing it. A summarized policy in Memory has no version history and no obvious "replace this file" moment when the real policy changes -- it just quietly drifts.
• One-off sensitive details that won't recur shouldn't be stored at all. If a fact is specific to a single exchange and isn't going to matter again, storing it only adds something else that eventually needs reviewing and, in a sensitive-data case, adds retention risk with no ongoing benefit.

Memory Needs Curation, Just Like Knowledge

Memory is only useful when it's actively maintained. A fact that was accurate last quarter and hasn't been revisited since can quietly mislead rather than help -- Claude will treat a stale stored fact as settled, the same way it faithfully follows an outdated instruction. Treat Memory with the same discipline as project knowledge:

• Check in on what's stored on a regular cadence -- monthly is a reasonable rhythm for anyone using a Project heavily
• Correct or remove anything that's stopped being true
• Keep it lean, limited to things that genuinely come up again and again rather than every detail that surfaced once

Common exam traps

• Collapsing Memory into project knowledge. A scenario about a fact "the Project already knows" from a prior conversation -- a name, a standing preference, a decision made weeks ago -- is testing Memory, not an uploaded document. Project knowledge is documents you added; Memory is continuity Claude accumulated from usage.
• Confusing scoped Memory with context-window management. Memory is about facts persisting *across separate sessions* in a Project. Summarizing, restarting, or persisting state to manage token budget *within one long conversation* is a different topic entirely (see Domain 3's context-window management) -- don't reach for "restart the conversation" when the question is actually about cross-session continuity, or vice versa.
• Assuming Memory is account-wide. Memory is scoped per Project specifically so unrelated or conflicting work stays isolated; a shared Project across two workstreams that must stay separate is the wrong setup even if it feels more convenient.
• Treating Memory as permanent once stored. An unreviewed memory can go stale exactly like an unreviewed document -- the fix is the same periodic-review habit covered under configuration maintenance.
• Storing an enforcement rule or a whole reference document in Memory instead of instructions or project knowledge. This is the most common practical misuse: something that should always apply, or something with real reference content, ends up as an unversioned Memory note with no clear replace-it moment.