You tell Claude something important on Tuesday. You open a new chat on Thursday. It remembers your tone preferences, half-remembers the project, and loses the one decision that actually mattered.
A lot of people call that a memory problem.
Usually it’s a placement problem.
Claude now has several continuity surfaces, and they don’t do the same job. Profile preferences are account-wide. Standalone chat memory summarizes non-project conversations and updates on a daily cycle. Paid users can search old chats instead of hoping the model recalls them on its own. Projects have instructions and a knowledge base. Claude Code starts each session fresh and carries continuity through CLAUDE.md and auto memory. Cowork adds another operating surface inside Claude Desktop for longer, multi-step work.
If you treat all of that like one big thing called “memory,” your setup gets sloppy fast.
The useful question is smaller.
What kind of continuity does this piece of context actually need?
That’s the difference between a workflow that gets sharper over time and one that keeps making you restate the same job.
Where people usually create their own mess
They drop durable project rules into a disposable chat.
They turn one-off task instructions into permanent project settings.
They upload a mountain of files and expect active recall instead of retrieval.
They move from the web app into Claude Code and assume the same continuity model follows them into the terminal.
Then they say Claude forgot the plot.
Sometimes it did. A lot of the time, the system was never set up to carry that context in the first place.
Profile preferences are the broadest layer
Profile preferences are for broad defaults that should follow you across lots of unrelated work.
Your preferred tone. The way you like tradeoffs framed. The habits that should show up again and again. Broad methods. Recurring terminology. Communication preferences.
That’s a good fit for “how I generally like Claude to work with me.”
It’s a bad fit for one publication’s article rubric. It’s a bad fit for this week’s operating review packet. It’s a bad fit for one team’s research workflow.
Those belong somewhere narrower.
Standalone chat memory helps outside projects
Claude’s standalone memory and chat search matter, but they solve a different problem than most people think.
Memory helps Claude build continuity across non-project conversations. Search helps Claude go find something old when you need it. Those are not the same mechanism. One is background synthesis. The other is retrieval.
That distinction matters in practice.
If you discussed something last week in a regular chat, Claude may be able to carry some of it forward through memory or surface it again through search. If you discussed it inside a project, you shouldn’t assume the same behavior unless you deliberately moved the durable parts into the project’s actual continuity layers.
That’s where a lot of the confusion starts. People experience one kind of continuity in regular chats, then expect identical behavior everywhere else.
Projects have more than one continuity surface, and they still aren’t one shared brain
Project instructions are the standing rules for that workspace.
This is where repeatable standards belong:
what a good output looks like
how the work should be structured
what should be flagged instead of guessed
what kind of evidence bar the project should use
what needs human review before it leaves the room
If every article in one project should follow the same tone, structure, and sourcing posture, that belongs in project instructions.
Project knowledge is different. That’s the reusable source library.
Prior memos. Transcripts. Meeting notes. Product docs. Archived research. Old packets. Definitions. Background files you’ll want Claude to pull from again.
This is where a lot of users still overestimate what the system is doing.
Project knowledge is incredibly useful. It cuts repeated uploads. It keeps source material in one place. On paid plans, Anthropic says project knowledge can shift into RAG mode as the knowledge base grows. That’s powerful.
It’s still retrieval.
It is not the same thing as every document being loaded into working memory all the time.
There’s one more wrinkle here, and it’s the part people should be more honest about. Anthropic now describes project memory summaries on some paid plans. At the same time, its project docs still say context is not shared across chats within a project unless that information is added to project knowledge.
Those two ideas don’t fit together perfectly.
So the practical rule stays the same: don’t assume one project chat carries the full working state of another just because they live in the same workspace.
Put standing rules in project instructions.
Put reusable material in project knowledge.
Treat anything beyond that as helpful continuity, not guaranteed state.
Some context should expire
Not everything deserves promotion into long-term context.
The weird issue for this week. The one-off framing choice for a deliverable. The odd edge case you want handled before anything gets sent. The temporary tradeoff you want debated in this run.
That belongs in the active session.
A lot of users try to solve forgetfulness by storing more. What they usually do is make future sessions noisier.
More stored context is not automatically better context.
Sometimes the best thing you can do for a workflow is let temporary context die when the job is over.
Claude Code has its own memory model
This is where serious users usually trip over their own assumptions.
Claude Code does not behave like “my Claude project, but in terminal form.”
Each Claude Code session starts with a fresh context window. Continuity comes from two places:
CLAUDE.md, which you writeauto memory, which Claude writes from corrections and recurring preferences
Both are loaded at the start of a session. Anthropic is also explicit that Claude treats them as context, not as hard enforcement.
That means repo conventions, build commands, architectural constraints, and recurring lessons belong in CLAUDE.md or auto memory. Session-specific chatter is still session-specific chatter.
If you don’t separate those, you end up re-briefing the same codebase every time you reopen the tool.
This is also why so many builders are creating elaborate memory workarounds around coding agents in general. The pain is real. They want stable continuity across sessions. Claude Code gives you a structure for that, but it still expects you to place the right things in the right layer.
Cowork helps with continuity, but it doesn’t solve architecture for you
Cowork changes the surface area, not the underlying logic.
Anthropic positions Cowork inside Claude Desktop as a more visual, agentic environment for longer-running tasks. It can work with local files, coordinate multi-step work, and produce outputs like spreadsheets and presentations.
That’s useful, mostly because it cuts down handoff and setup work.
It doesn’t magically decide where your durable context should live.
Cowork won’t decide what belongs in project instructions. It won’t decide which source material belongs in project knowledge. It won’t decide what should be written into CLAUDE.md. It won’t decide whether something is a one-session exception or a standing rule.
You still have to do that part yourself.
A continuous thread is useful. It is not a substitute for context architecture.
A better way to place context
Before you store anything, ask what kind of continuity it actually needs.
If it’s broadly true across how you like to work, put it in profile preferences.
If it belongs to one project’s standing behavior, put it in project instructions.
If it’s reusable source material you’ll want Claude to pull from again, put it in project knowledge.
If it’s a recurring repo rule or engineering lesson, put it in CLAUDE.md or let Claude Code’s auto memory carry it.
If it only matters for the job in front of you, leave it in the current session.
That’s less exciting than “make Claude remember everything.”
It’s also a lot closer to how the product actually works.
One example
Take a weekly operating review.
The standing packet structure belongs in project instructions.
The KPI definitions, prior packets, team updates, and meeting notes belong in project knowledge.
The odd issue that only matters this week belongs in the active conversation.
If part of the workflow moves into terminal-based implementation, repo-specific rules and commands belong in CLAUDE.md, not in a chat you hope the next coding session will rediscover.
Once you separate broad preferences, reusable project material, coding conventions, and temporary working state, Claude gets less mysterious and a lot more dependable.
You don’t need Claude to remember everything.
You need the right context to survive in the right place.
We were already using Guru for about a year before adding Claude Cowork. Once we were able to plug Claude into Guru, he had all the context he needed. Would love to see some Claude pros talk more about these types of connections for context for Claude.
Spot on!
Many "experts" get lost on an issue you solved in one post!