Claude Projects: persistent, context-rich workspaces

I keep a separate Claude Project for every account I actually care about, and for every motion I run, and it took me embarrassingly long to start. For the better part of a year I paid what I now call the briefing tax: open a blank chat, re-paste the ICP, re-explain our positioning, remind Claude how I like things written, and only then get to the real question. Every single morning. Like onboarding a temp who quits at midnight.

A Project ends that. It is a workspace that holds your instructions and your knowledge and hands both to every chat you open inside it, so Claude walks in already briefed. That is the entire difference between an assistant with amnesia and a colleague who knows the account.

It is also the most misused thing in the Claude apps. Built well, it is the highest-value setup you have. Built lazily, it rots into a junk drawer that makes every answer a little worse. I have built both, so this is how to get the first one and avoid the second.

A Project is a workspace with a memory of its setup

A Project bundles two things and pushes them into every conversation inside it: custom instructions, which are how Claude should behave in here, and knowledge, which are the files it always has open. Start a chat in the Project and it already knows both. You are not re-establishing who you are, what you sell, or how you like the writing. The chat opens mid-briefing instead of stone cold.

Put the two experiences side by side, because the gap is the whole pitch. A normal chat is an empty desk you clear off and set up from scratch every time: here is the ICP, here is the positioning, here is the tone, now let's work. A Project chat is a desk someone already arranged the way you like it. Run that math across twenty chats a week and the briefing tax you have been quietly paying, in time and in consistency, is a real number.

So here is the reframe I wish I'd had on day one: a Project is not a folder for chats, it is onboarding, done once. Everything you would tell a sharp new hire on their first morning, the context, the rules, the reference material, is exactly what goes in it. Skip that step and what you have is a temp with a name tag and no training, which is most people's Projects.

Custom instructions: how Claude behaves here

The instructions are the standing rules for the workspace: your voice, your formatting, your ICP, the guardrails you would otherwise retype at the top of every prompt. Claude applies them to every chat in here without being reminded, so this is where you teach it your house style once instead of correcting the same thing until you retire.

Write them as rules you could actually catch being broken, not as a mood. 'Write like a peer, no hype words, lead with the number, never open on a rhetorical question' is a rule, and I can tell in one glance when Claude ignores it. 'Be helpful and on-brand' is a horoscope. The test for any line you add: could you point at the output and say that violated it? If not, it is decoration, so cut it.

And keep the whole block short. A bloated set of instructions competes with your knowledge and the task for the same attention, and the model starts skimming your rules the way you skim a terms-of-service page. When I notice Claude missing the same thing over and over, I do not re-nag it in the chat, I add one line here. That is the actual job of the instructions: turn a correction you keep making by hand into a rule you make once.

Knowledge: the files it always has

Knowledge is the set of files the Project keeps open, and it is the upgrade almost nobody bothers with. Because Claude sees these on every chat, its answers come out of your real material, your actual positioning, your real numbers, the way your customers actually talk, instead of a confident average of the internet. This is the single biggest jump in output quality available to a non-technical user, and it is a drag-and-drop.

What earns a spot is durable context, the stuff that stays true across many conversations, not the material for one task. Your positioning belongs here. A single prospect's deck does not; that goes in the one chat about that prospect. Get that line right and the Project stays sharp. Get it wrong and you are building the junk drawer again. It is the same context-versus-task discipline that governs the whole context window, just applied to a room instead of a message.

The rule under all of it: paste the source, not your summary of the source. I spent weeks paraphrasing our positioning into a Project and wondering why the writing felt thin, and the paraphrase was the culprit. My summary dropped the exact phrases, the proof points, the specific numbers, which are the only parts that make the copy sound like us and not like a competent stranger. Feed it the real doc and the quality shows up.

• Positioning and messaging: how you talk about what you sell
• Your ICP and personas: who you sell to, and why they buy
• Product one-pagers and pricing: the facts reps get wrong
• Winning call transcripts and case studies: proof and voice in one place

Project vs chat vs skill vs memory

Four things get tangled here, and pulling them apart is practical, not pedantic. A chat is one conversation, empty at the start. A skill is a reusable procedure for a single task that follows you wherever you invoke it. Memory is Claude's personal recall about you across chats. A Project is the shared, persistent room a whole body of related work happens in, with its own instructions and files.

The rule of thumb sorts itself once you see it that way: a chat for a one-off, a skill for a task you repeat, memory for your own defaults, and a Project when a stream of related work should share the same background. Here is the tell, if two chats would both want the same context pasted in at the top, they belong in one Project.

They also stack, and the setups worth copying use several at once. A Project holds the account's knowledge, a skill inside the workflow runs the account-brief procedure, and memory carries your personal preferences over the top. Layers, not rivals. The day you catch yourself cramming a procedure into the instructions, or pasting the same three files into every new chat, that is the sound of the wrong tool, reach for the layer built for the job.

Setting one up well

Creating a Project takes a minute. Creating a good one takes exactly one decision, and that decision is scope. Name it for the precise thing it serves, an account, a motion, a deliverable, write the instructions for how Claude should behave in that context, drop in the knowledge that context needs, and then actually start every related chat inside it. That last part is the step people skip, and then they wonder why the Project never seemed to learn anything.

Scope narrow, and be ruthless about it. A Project called 'Marketing' is a promise to fail: it will hoover up this campaign, that account, some half-related research, until every answer is a compromise between things that have nothing to do with each other. A Project called 'Acme Corp' or 'Outbound to fintech CFOs' stays sharp because everything inside it genuinely belongs together. Narrow scope is not housekeeping, it is the thing that makes the answers good.

And treat it as alive, not a form you fill out once. When the outputs start drifting, the fix is almost always in here, a rule to add, a stale file to swap, rather than a cleverer prompt or a bigger model. I tune my Projects far more often than I tune my prompts now, because that is where the real gains sit and the prompts were never the problem.

Patterns that actually work

A few shapes hold up across every GTM team I have watched try this, and they share one trait: each is scoped to a unit of work you genuinely repeat, with context that is actually shared. That is where the set-it-once payoff is largest, and it is the test for whether a thing has earned its own Project at all.

The instinct to fight is organizing Projects like an org chart, one per department. Organize them by the thing you make over and over instead, because that is what shares context. A department is too broad, a single task is too narrow, and the unit in between, the account, the motion, the deliverable, is the sweet spot every time.

• Per account: the company's research, transcripts, and your notes, so every brief and email is grounded in the real relationship
• Per motion: an outbound segment or a campaign, holding the ICP, messaging, and rules once
• Per deliverable: a recurring report or content series, holding the format and the source material

Where Projects go wrong

The junk-drawer Project is the most common failure, and yes, I have built one. It happens a chat at a time: an off-topic question here, an unrelated file there, until the workspace is a drawer of loose batteries and old takeout menus and every answer comes back a shrug. The fix is boring and it works, scope narrow and make more Projects, each about one clear thing.

The scar that actually taught me the second trap: I had a broad 'Marketing' Project whose knowledge still held positioning from two repositions ago, because nobody had pruned it. It cheerfully drafted a prospect an email built on a value prop we had killed months earlier, and it sounded completely sure of itself. The Project did not fail. My maintenance did. Stale, trusted knowledge does more damage than missing knowledge, because it comes wearing authority.

The third trap is over-stuffing, dumping every document you own into knowledge on the theory that more is safer. It is not. A bloated Project spends its attention on noise, so the three files that matter for this work end up fighting twenty that do not. Curate knowledge down to what a good answer actually needs, and be willing to delete things you were proud to add.

The GTM setup: one Project per account or motion

Here is the whole thing for a GTM team, said plainly. A Project per named account holds that company's research, transcripts, and history, so every touch is informed instead of starting cold. A motion Project holds your ICP, positioning, and rules once, so every rep working that motion sounds like the same company instead of ten interpretations of it. That is Claude going from clever stranger to something that compounds, and over a quarter, compounding is the only thing that actually moves a number.

It is also the quiet assumption under the automations on this site. A play that produces a grounded account brief or a follow-up in your voice is only ever as good as the context it can see, and a well-built Project is where that context lives. Skip it and the same play hands you competent, generic work. Add it and the output starts knowing your accounts and sounding like you wrote it.

So build one tonight, for a single account you care about. Put a week of real work through it, then run a Project chat next to a cold chat on the same task and look at the two. That gap will make the case better than I can. You will walk away wanting one for every account that matters, which is exactly the point. Where would you point the first one?

How to set it up

Frequently asked questions

Sources & further reading

• Claude Docs
• Anthropic news

Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.