Claude Cowork Projects: Self-Contained Workspaces That Actually Remember

Large language models have amnesia. Every new chat starts from nothing. This is the single biggest constraint of working with AI, and most people try to solve it with longer prompts and bigger memory files. That works up to a point — and then it collapses.

Projects are Claude’s answer to statelessness, and they are the most underused feature in the entire product. If you learn one thing past the basics, learn projects.

What a project actually is

A project is three things stitched together:

1. A set of files you upload (roughly 30 max). These act as permanent context for every chat inside the project.
2. Custom instructions — a few paragraphs of rules that get injected into every prompt in that project. Tone, output format, jargon, hard rules.
3. A rolling memory Claude builds from the conversations inside the project. It refreshes every few days based on how actively you use it.

Every chat inside the project inherits all three. Start a new chat, and Claude already “knows” the reference material, your rules, and the context from past conversations — without you re-explaining.

Where projects sit in the reliability hierarchy

Claude has many ways of “knowing” things about you and your work. Some are more reliable than others. Roughly, from most to least:

1. The current prompt — 100% reliable. If you said it, Claude sees it.
2. Files uploaded in the current chat — very reliable while the chat is open.
3. Project custom instructions — injected verbatim into every prompt. Reliable.
4. Project files — surfaced via retrieval. Very reliable for focused queries.
5. Past chats pulled in by reference — reliable when you explicitly invoke them.
6. Stored memory — “background osmosis.” Useful but not precise. Cannot be fully trusted.

Projects sit in the sweet spot. They’re much more reliable than memory, much more flexible than stuffing everything into every prompt, and they persist across chats without you having to remember to invoke them.

Best practices for naming and scoping projects

This is the part most people get wrong. A healthy project lifecycle starts narrow and expands.

Bad project names

• “Work”
• “Reading list”
• “Tesla” (if you’re an investment analyst — too broad)

Good project names

• “Tesla monthly reporting”
• “Investor letters — Howard Marks style”
• “Weekly content calendar for newsletter”

The principle: name projects by outcome, not by topic. The outcome tells you what files belong in the project and what rules apply. A topic-named project becomes a dumping ground and hits the 30-file limit with junk.

Once you have a scoped project running well, expand it if you need more — but only after you know what “working well” looks like.

Custom instructions: the evergreen rules layer

Custom instructions are written by you and applied to every chat in the project. They should contain things that are true across every conversation, not one-off preferences.

Example custom instructions for an investor letter project:

- Write in Howard Marks's voice: conversational, analogy-heavy,
  frames arguments by establishing principles first.
- Length: 2,000-3,000 words.
- Quote percentages with no decimal points.
- Figures in millions or thousands, never billions.
- All currency in US dollars.
- Never quote specific company names unless they are in
  the reference memos.
- End with a single-sentence summary.

That block gets injected ahead of every prompt inside the project, free of charge. You don’t have to remember to say it.

Creating your first project (walkthrough)

Let’s build one. The example: a project that writes investor letters in Howard Marks’s style.

1. In the left sidebar, click Projects, then New Project.
2. Name it: Write investor letters (Howard Marks style).
3. Click Files → Upload from device.
4. Upload seven or eight of Howard Marks’s public memos as PDFs.
5. Click Custom Instructions and paste the instructions block above.
6. Start a new chat inside the project and try:

Describe the style of these newsletters.

Claude will read the uploaded memos and return a style guide: voice and tone, common rhetorical moves, topic range, structural patterns. This proves the project is wired up correctly — the files are being retrieved and read.

Now a real query:

What is Howard Marks's view on AI?

Claude will search the project files and return a grounded answer — not “here’s what Howard Marks probably thinks” but “here’s what he actually wrote in his November 2024 memo.” This is the power of a well-scoped project.

Referencing a project from outside

If you’re in a regular chat (not inside the project) and you want to borrow a project’s context for one question, you can. Click the + icon in the chat input, select Project, and choose the project. The chat turns blue to indicate the project context is attached.

Useful when you want to ask a one-off question without setting up a new chat inside the project.

Pulling past chats into a project

Chats you’ve had outside a project can be moved in. Useful when you’ve been working on something for a while and realize it deserves its own workspace.

Search your chat history, find the relevant chat, and use the Move to project option. The conversation becomes part of that project’s reference context.

Projects in Cowork vs projects in Chat

Conceptually identical. The difference is mechanical.

• Chat projects live in the cloud. Files are uploaded via drag-and-drop. If you edit a file on your computer, you have to re-upload.
• Cowork projects sit on top of a folder on your machine. Edit a file in that folder and the project sees the new version next time it reads. No re-uploading.

For any ongoing workflow — monthly reports, weekly content, recurring analyses — Cowork projects are the right choice because your reference material changes over time.

We cover the full Cowork project setup in a later module. For now, start with a chat project on something concrete.

The 30-file limit is a feature

Most people hit the file limit and get frustrated. It’s actually doing you a favor. If your project needs more than 30 files, your project is too broad. Split it into two projects scoped by outcome.

A monthly reporting project needs: the reporting template, the last three months of reports (for style consistency), and maybe a style guide. That’s five files. If you’re at 28, you’re probably mixing outcomes.

Common mistakes

• “Work” as a project name. You’re going to regret it in a week.
• Uploading everything you can find. Focus. What’s the outcome? What do you actually need?
• Using custom instructions for one-off preferences. Those belong in the prompt. Custom instructions are for rules that apply every time, forever.
• Treating project memory as precise. It’s helpful background, not a system of record. If something is critical, put it in custom instructions or in a file.
• Never sharing. If you’re on Teams or Enterprise and you’ve built a project that works well, share it. One person maintains, everyone benefits.

Next up

Projects are the layer that makes a workflow repeatable. The next step up is skills — packaging a workflow into a reusable, portable text file that Claude can invoke automatically. If a project is a workspace, a skill is a playbook.