Why does Claude often say it doesn't remember when I ask, in a new conversation, "do you remember the plan we discussed last time?"
Because that "plan" most likely only existed within the previous conversation's context, and context doesn't carry over across conversations. Unless the key points from that discussion were judged worth retaining by the memory system (for example, you explicitly said "remember this for me"), it was only ever held temporarily in that now-closed conversation window. A new conversation starts with a completely independent, fresh context — Claude has no way to "look back" and pull up content from a previous conversation window.
This isn't a bug, it's a design boundary: context's scope is "this one conversation," while memory's scope is "across conversations" — the two can't substitute for each other. The most reliable way to make sure an important plan isn't lost is, once the discussion is finalized, ask Claude to summarize the key points into a document and paste it into a Claude Projects knowledge base file — that finalized content then automatically gets pulled into context every time you enter that Project.
Do the knowledge base documents in Claude Projects count as context or memory?
Strictly speaking, they get "reloaded into context every single time," rather than going through the memory system's filtering mechanism — this is the biggest practical difference between the two, and why knowledge base documents are more reliable than the memory system.
The memory system works by "summarizing after the fact, filtering automatically": it judges which information is worth keeping and worth carrying into the next conversation. You can't fully control its filtering criteria, and content that's too granular or mentioned too briefly may be judged unimportant and never get saved.
Knowledge base documents work differently: as long as a document is attached under a Project, every single time you open a conversation in that Project, the document's full content reappears in context (within the capacity limit) — it doesn't need to be "selected by the memory system" to show up. This means that if you have information you use constantly and absolutely cannot afford to get wrong (brand guidelines, a fixed project glossary, team contact points), putting it in a knowledge base document is far more reliable than hoping the memory system remembers it.
The trade-off: knowledge base documents consume this conversation's context capacity. Stuffing in too much or too-long documents can actually push other genuinely needed content out of the visible range — which is why knowledge base documents should stay lean, containing only core information you truly need every time.
If I want Claude to remember something, does directly saying "remember this" work? How does it differ from putting it in a knowledge base document?
Directly saying "remember this" usually works, but its reliability differs from knowledge base documents, and each suits different situations.
Telling Claude "remember this" is an explicit signal to the memory system: this information is worth retaining and worth carrying into future conversations. The benefit of this approach is that it's lightweight — no need to open and maintain a separate document — and it suits single, relatively stable pieces of personal information (your job title, your preferred communication tone, a fixed preference for a certain type of task). The downside: the memory system carries information into new conversations as a "summary," not a verbatim copy. If the original information is long or complex (a complete formatting spec, or several interlocking rules), the summarization process can lose detail or get compressed imprecisely.
Knowledge base documents, by contrast, are "full content, unaltered, appearing every time" — suited to information-heavy scenarios where details can't afford to be wrong (spec documents, terminology glossaries, templates).
The practical rule of thumb is simple: if it's one or two sentences and easy to state clearly → just ask Claude to remember it directly. If it has structure, detail, and needs precise reference → put it in a knowledge base document rather than relying on the memory system to summarize it.
Does memory carry over between different Projects, or is each one independent?
This is a point that's easy to misjudge in practice: memory isn't bound to a single Project — it spans your entire account. No matter which Project you open a conversation in, or even if you skip Projects entirely and just open a regular chat, background-accumulated memory summaries can potentially get carried in.
This has a real practical implication: if you discuss sensitive details about Client A within a "Client A Project," and the memory system judges those details worth retaining, they could theoretically surface as background information the next time you open a brand-new conversation in a "Client B Project" — even though you never intended for information between the two to cross over.
This stands in clear contrast to knowledge base documents, which are bound to a single Project and only load within that specific Project — they don't leak into other Projects.
Practical advice: if you're juggling multiple clients or projects that need to stay confidentially separated, be more careful when discussing genuinely sensitive information that shouldn't cross over — prioritize knowledge base documents for isolation, and stay mindful during conversations about what you don't want the memory system retaining long-term; if needed, explicitly tell Claude "you don't need to remember this part."
Scenario comparison: which approach fits which kind of information
Scenario 1 (suited to directly asking Claude to remember): Every time you discuss work tasks with Claude, you habitually ask for "replies in bullet points, not long paragraphs." This is a preference that fits in one sentence — tell Claude once, "remember I prefer bullet-point replies from now on," and the memory system will retain a summary of that preference, which will generally get auto-applied in new conversations going forward.
Scenario 2 (suited to a knowledge base document): Your team has a 12-point "client email reply standard" covering fixed honorific usage, a list of competitor names that must never be mentioned, and signature formats for each email type. This spec is long, structured, and can't afford a single wrong detail — if you only mention it verbally once in conversation and expect the memory system to retain all 12 rules, it will likely only retain the one or two points mentioned most often, and the rest of the detail will get lost. The correct approach is to compile those 12 rules into a document and attach it to the knowledge base of a "Client Communication" Project — then every time you draft an email in that Project, Claude sees the complete spec instead of guessing from a fuzzy memory summary.
Choosing to rely on the memory system versus proactively putting things in a knowledge base document is fundamentally a trade-off between "low effort" and "precision and control." Relying on the memory system costs almost nothing to maintain — you just have normal conversations, and the system judges and filters automatically — but the cost is you can't fully control what it retains or how it summarizes, and important details risk being compressed or dropped. Proactively compiling a knowledge base document puts you fully in control — content appears complete and word-for-word every single time — but it costs you time to compile and maintain, needs updating when it goes stale, and consumes that conversation's context capacity; overstuffing it can crowd out other content that should be visible. The practical compromise: leave personal, low-risk preferences to the memory system; put team-shared, unambiguous specs into knowledge base documents.