Every team has the same problem with AI chat: someone opens Claude, pastes a wall of context, gets a decent answer, and tomorrow a colleague repeats the whole ritual from scratch. The context never accumulates. Claude Projects fixes exactly that — it gives you a shared workspace where documents, instructions, and knowledge persist across every chat, and (on a Team or Enterprise plan) across every teammate.
This guide walks through setting up Claude Projects for real team workflows: what to upload, how to write instructions that actually work, how sharing and permissions behave, and the workflow patterns teams use in practice.
What Claude Projects actually are
A Project on claude.ai is a container with three parts:
1. Project knowledge — documents Claude can always consult (PDFs, text files, Word docs, spreadsheets, and other common formats). Paid plans support up to 100 files per project, and when knowledge gets large, Claude automatically switches to a retrieval mode that pulls the most relevant chunks rather than reading everything.
2. Project instructions — standing directions that apply to every chat inside the project ("answer from our docs first", "use British English", "say you don't know rather than guessing").
3. Chats — individual conversations that inherit all of the above. Context is not shared across chats unless it lives in the project knowledge base, so the knowledge base is the team's single source of truth.
Think of it as the Claude equivalent of a team's long-term memory: the briefing happens once, and every conversation starts fully briefed.
Before you start: the plan requirement for sharing
Projects exist on all Claude plans, but sharing projects with teammates requires a Team or Enterprise plan. On individual plans, Projects are personal workspaces. If your goal is a team workflow rather than a personal one, the organization plan is the prerequisite — otherwise you'll be maintaining duplicate copies of the same knowledge in every person's account.
Step 1 — Create the project with a narrow purpose
Open claude.ai, click Projects in the left sidebar, then New Project. Give it a clear name that reflects one deliverable: "Support playbook", "HR policies Q&A", "Release notes", "Sales call prep". One deliverable per project is the rule that keeps answers sharp — vague catch-all projects produce vague answers.
Step 2 — Upload the knowledge (quality over quantity)
Click into the project and add your documents. Five accurate, current documents beat fifty contradictory ones. Practical rules:
- Upload the approved, final versions of policies, playbooks, pricing, product docs, templates — not drafts and not superseded files.
- Remove duplicates before uploading; conflicting versions are the number-one cause of wrong answers in Projects.
- Keep each file focused. A 200-page manual and a one-page FAQ can live in the same project, but per-topic documents retrieve better.
- Images can be referenced inside individual chats but don't behave as persistent project knowledge the way text documents do, so convert key visual reference material into described text where it matters.
Step 3 — Write the standing instructions
This is the step most teams skip, and it's the most valuable one. Click Set project instructions and write in plain English:
- Who the audience is — "You're answering questions from our support agents, not customers."
- Source priority — "Answer from the uploaded documents first. If the answer isn't in them, say so instead of guessing."
- Tone and format — "Use short paragraphs, cite the document name you used, and match our brand voice."
- What not to do — "Never invent policy numbers, prices, or dates."
Good instructions save more time than any amount of extra uploaded files. Test the project before the team touches it: ask the questions people actually ask. If an answer is wrong or thin, fix the knowledge or the instructions — that's almost always the cause.
Step 4 — Share it with the team
On a Team or Enterprise plan, open the project, click Share project next to the project name, and add teammates by name or email (bulk invites via pasted email lists work too). Choose the permission level for each member:
- Can view — sees the contents, knowledge, and instructions, and can chat within the project, but cannot change anything.
- Can edit — can modify instructions and knowledge, update member settings, and contribute fully.
Practical default: give most of the team Can view and a small set of owners Can edit. You can change roles later from the sharing menu, see who's on the project, and remove access when someone leaves.
Team workflow patterns that work
Once the mechanics are set up, Projects tend to settle into a few repeatable patterns:
1. The knowledge oracle. Upload HR policies, benefits docs, or product specs; the whole team asks everyday questions in one chat each and gets consistent answers. Reduces the "ask the one person who knows" bottleneck.
2. The output factory. One project per deliverable type: a proposal template, a release-notes template, a campaign-brief template. Knowledge holds examples of past good outputs; instructions hold the formatting rules. Every new chat produces work that already matches house style.
3. The onboarding assistant. New hires chat inside the project instead of reading a 40-page handbook cold. Instructions tell Claude to point them at the relevant document and quote it, which doubles as self-service training.
4. The review workflow. Upload coding standards, design guidelines, or review checklists. Team members paste drafts into chats inside the project for feedback that's calibrated against the team's own standards, not generic advice.
Keeping it fresh as the team grows
Shared Projects decay without ownership. Assign these three habits:
- One owner per project (a Can-edit member) responsible for updating knowledge when policies or docs change.
- A quarterly prune: delete outdated documents rather than letting them linger and contaminate answers.
- A starter message or pinned examples: when you invite people, show them two or three example questions and state what the project does and doesn't cover. Most early frustration comes from unclear scope, not bad answers.
Limits worth knowing
- Chats inside a project don't see each other's content — only the shared knowledge base is shared. If something needs to persist across conversations, put it in the knowledge, not in a chat.
- Deleting a project deletes its conversations and knowledge for good — there's no recovery. Save valuable outputs elsewhere first.
- Very large knowledge bases trigger retrieval mode on paid plans, which expands capacity but means Claude is sampling documents rather than reading them whole; the pruning habit matters more here.
- The Claude mobile app supports Projects, so teammates can access shared workspaces on the go, though the interface is simpler than desktop.