How to Use Claude Projects to Run a Business
A project in Claude holds three things: knowledge files, standing instructions, and the chats inside it. The first two are what matter for running a business, because chats in a project cannot read each other. Nothing you worked out in Monday's conversation carries into Tuesday's unless somebody wrote it into project knowledge. Once you treat that knowledge as the only memory the business has, a project stops being a folder of attachments and becomes the reason your answers stay consistent across a hundred separate chats. Below is the structure I run, what goes in each project, what to keep out, and the one habit that makes the arrangement compound instead of rot.
What a project actually is
The mental model most people arrive with is a folder. You drop files in, and the assistant has read them. That part is roughly right. The part that catches people out is the isolation between chats, which Anthropic's own documentation describes plainly: each project has its own knowledge base, and each conversation inside it stands alone (Anthropic support).
So the first time you open a chat and ask "what did we decide about the pricing page last week," you get a confident answer assembled out of nothing. The model is not lying to you on purpose. It has no access to that conversation, and a question phrased as recall invites it to produce something recall-shaped.
That single fact reorganizes how you use the feature. The chats are disposable. The knowledge is the asset. Every useful thing a chat produces is lost at the moment you close the tab unless you move it.
The projects a small business actually needs
Five is usually enough, and the boundary between them is the material they share rather than the task you happen to be doing. If two jobs read the same facts, they belong in the same project. If they would each need their own set of files, split them.
Site and copy. The brand facts, the page inventory, the current copy as plain text, the voice rules, the design decisions. This is the project where you ask for a new section or a rewritten headline, and it is the one that benefits most from being tightly specified. The input artifact I use for this is covered in how to give Claude a design system to work from.
Offer and pricing. What you sell, what is included, what is deliberately not included, the price and why it is that number, the refund terms, the objections you have actually heard. Every sales email and every FAQ answer comes out of this project, and keeping it separate from the site project is what stops stale claims leaking into live copy.
Content. Published posts with their target queries, the topic queue, the rules about what you will and will not write. A content project with twenty of your own posts in knowledge produces drafts that sound like you. One with nothing in it produces drafts that sound like everyone.
Customers. Support replies you have already sent, common problems and their fixes, the boundaries of what support covers. The value here is consistency: the fourteenth person who emails about file access gets the same answer as the first.
Numbers. Revenue by month, traffic exports, ad spend, anything you want to ask questions of rather than read. Keep this one free of prose so a query returns figures instead of paragraphs about figures.
Three more will suggest themselves as you go. Resist adding a sixth project for a task you will do twice. A project earns its existence when the same material gets re-explained in three or four separate chats.
What belongs in knowledge, and what just bloats it
My test is one question: would I have to explain this again in every new chat? If yes, it goes in knowledge. If no, attach it to the one chat that needs it and let it disappear.
Things that pass the test tend to be stable and short. Prices. Brand voice rules. The list of pages on the site. Decisions with their reasons attached. Terminology you use in a specific way. A one-page summary of a customer segment is worth more than the forty-page research document it came from, because the summary is what the model will actually quote back.
Things that fail the test are the ones people upload most eagerly. Raw CSV exports you will never query. Entire PDFs where two paragraphs matter. Old drafts of documents that have since changed. Meeting transcripts. These do not just waste capacity. On paid plans, large knowledge bases switch to retrieval rather than being read whole, which Anthropic says can extend capacity by roughly ten times (source). Retrieval is good, but it means Claude fetches the parts that look relevant to your question. Bury a pricing fact inside a 200 page transcript and it may simply not surface.
A stale file is worse than a missing one. If the price changed in June and the old number is still sitting in a file from March, you will get the March number back in a sales email, stated with complete confidence. I now delete and re-upload rather than add a corrected file alongside the wrong one.
Instructions are a standing contract
The instructions field is not a personality setting. It is the set of rules you are tired of typing, written once. Mine tend to have four parts.
First, the role and what it covers: who I am, what this project is for, what counts as finished. Second, decision rules for the choices that come up repeatedly. In the copy project that means things like "prices are stated as one payment, never as a monthly figure." Third, formatting defaults, because the alternative is asking for plain text in every message. Fourth, a do-not list, which is the part that does the most work.
Each do-not line is paired with a replacement, because a prohibition on its own just moves the problem. "No em dashes, use a period or parentheses" works. "No em dashes" produces en dashes. The structure of a single request is a separate skill, covered in how to prompt Claude for a website; instructions are for the rules that should hold across every request you will ever make in that project.
Keep them short enough to read in one screen. Instructions that run to two thousand words get skimmed by the model in the same way a contract gets skimmed by a human, and the specific line you cared about is the one that gets missed.
The write-back habit
This is the step that separates a project that gets better from one that stays where it started, and almost nobody does it.
When a chat produces something durable, write it into knowledge before closing the tab. Not the whole conversation. The output: the decision, the paragraph you approved, the answer you will send again. I keep one file per project called decisions, and it is a list of dated lines. "2026-09-14: refund window is fourteen days, no questions, because the support cost of arguing exceeds the refunds." Four months later that line is why the model stops re-proposing a thirty day window.
Ninety seconds per chat is the whole cost. The payoff is that you stop re-litigating settled questions, which is where most of the time goes in practice. Six weeks of this and the project knows things you have forgotten you told it.
One warning from doing it badly for a month: do not paste raw chat transcripts in. You end up with knowledge full of your own half-formed thinking and the model's rejected suggestions, and retrieval starts surfacing the ideas you threw away. Write the conclusion, not the argument that got you there.
Where projects fall down
Four limits are worth knowing before you build a business process on top of this.
Chat isolation is the one that bites hardest, and it bites through hallucinated recall rather than an error message. Ask about a previous conversation and you get an answer rather than a refusal. The habit that fixes it is to stop asking recall questions entirely and instead paste in the thing you want referenced.
Retrieval means you cannot assume every word was read. Once knowledge is large, the model is working from fetched excerpts. For facts that must never be missed, repeat them in instructions, which are not subject to retrieval.
There is no version history on knowledge files. Replace a file and the old one is gone. For anything you would be upset to lose, keep the canonical copy somewhere else and treat the project as a working copy.
And projects do not travel between accounts. Moving from an individual plan to a team plan does not bring them with you, so the migration is manual re-uploading. Worth knowing before you build forty of them on the wrong account.
Setting it up without losing a weekend
Start with one project, not five. Pick the job you do most often, which for most people selling something online is writing copy.
Create it, write eight lines of instructions, and upload three files: the brand facts, the current copy as plain text, and an empty decisions file. That is twenty minutes of work and it is already better than a blank chat, because the two things a blank chat lacks are your words and your rules.
Then use it for a week and let the gaps tell you what to add. Every time you find yourself typing the same explanation twice, that explanation belongs in knowledge or instructions. This is a far more reliable way to build the thing than trying to specify it upfront, because you cannot predict which facts you repeat until you catch yourself repeating them.
Add the second project when the first one starts collecting material that does not belong in it. In my experience that takes two or three weeks, and the split is usually copy against offer, because sales material wants the objection list and page copy does not.
The feature is simple. The discipline is not, and it comes down to one shift: stop treating conversations as where the work lives. A chat is a place to think. Project knowledge is where the business keeps what it concluded.
Get that right and the compounding is real in a way most AI advice promises and does not deliver. Month one, you are explaining your pricing in every chat. Month four, you ask for a sales email and get back one that quotes the right number, respects the refund terms, and sounds like the last twelve you sent. Nothing clever happened. You just wrote things down in the place that reads them.
Common questions
Do I need a paid plan to use Claude Projects?
No. Projects are available on every plan including free accounts, which can create up to five of them. Paid plans (Pro, Max, Team and Enterprise) scale the knowledge capacity automatically and switch to retrieval when a project's knowledge grows past the context window, so the practical difference is how much material one project can hold.
How much can I put in project knowledge?
Enough that capacity is rarely the real constraint. A paid project holds a large knowledge base and moves to retrieval once it exceeds the context window. The constraint that actually matters is relevance: a project with ten tight files answers better than one with eighty, because retrieval has fewer wrong places to look.
Can Claude see my other chats in the same project?
No, and this is the detail that causes the most trouble. Conversations inside a project are isolated from each other, so asking what you decided in a previous chat tends to produce an invented answer rather than a refusal. Anything that needs to persist has to be written into project knowledge or instructions.
Should I use one big project or several smaller ones?
Split by shared material rather than by task. If two jobs read the same files, keep them together. If each needs its own set of facts, separate them, because mixing unrelated material makes retrieval return the wrong excerpts. Five projects covers most small businesses: copy, offer, content, customers and numbers.
What is the difference between project instructions and a writing style?
Instructions apply only inside that project and can cover anything: role, decision rules, formatting, prohibitions. A style is a separate account-level setting that shapes tone across any chat, with or without a project. Use instructions for rules specific to the work, and a style for how you want writing to sound generally.
How often should I update project knowledge?
Whenever a fact changes and after any chat that settles something. Replacing a changed file matters more than adding new ones, because a stale price or an outdated claim sitting in knowledge will get quoted back with full confidence in a customer-facing email.
The prompts and the structure, already built
ShipWolf is the kit I work from: 60+ Claude prompts, two starter codebases, and the action path with screenshots. One payment of $97, no subscription. Take a look at ShipWolf.
See what's inside · $97
Built by