Claude Projects: How to Organise Knowledge and Context for Team Workflows

What Are Claude Projects?

Every time you start a new conversation with Claude, it starts fresh. No memory of previous conversations, no awareness of your context, no understanding of your terminology or preferences. That's appropriate for casual use — but it's a significant friction point for knowledge workers who use Claude as a daily work tool.

Claude Projects solves this. A Project is a persistent workspace that maintains context across conversations. Within a Project, you can upload reference documents, write custom instructions, and have multiple conversations — and Claude carries the knowledge from each of these into every new interaction. You explain your context once. Claude remembers it indefinitely.

This is one of the most underestimated features in the Claude product suite. The difference between using Claude without Projects (re-explaining context every session) and using Claude with Projects (starting every session with full context) is the difference between a tool and a colleague. For organisations doing a serious Claude enterprise implementation, Projects are not optional — they're foundational.

Anatomy of a Claude Project

A Claude Project has four components that work together to give Claude the context it needs to be genuinely useful.

The first is the Project Instructions: a text block that Claude reads at the start of every conversation in the Project. This is where you define who Claude is in this context, what it knows about your organisation, what tone and format it should use, and what it should prioritise. Good project instructions are specific, not generic — they reference real departments, real workflows, real terminology from your business.

The second is Knowledge Files: documents you upload that Claude can reference. A product spec, a style guide, a competitive analysis, a set of financial reports, a legal agreement — anything Claude might need to do its job well in this Project. The knowledge files are available in every conversation without re-uploading.

The third is Conversation History: all previous conversations within the Project are preserved and accessible. Claude doesn't automatically use every previous conversation in each new chat, but you can reference previous discussions, and the continuity of working in a shared space accumulates value over time.

The fourth is Tool Configuration: for Projects connected to MCP servers or specific Skills, the tool configuration defines what Claude can do in this Project. A legal Project might have access to contract databases via MCP; an engineering Project might have access to the code repository and CI/CD system.

How to Set Up Your First Claude Project

1. Create the Project

   In Claude (Desktop or browser), click "New Project" from the sidebar. Give it a specific, descriptive name — "Q2 Compliance Review" is better than "Compliance". Specificity helps when you have many Projects.

2. Write Project Instructions

   This is the most important step. Write 200-500 words describing who you are, what this Project is for, what Claude should know about your context, and how it should behave. Include specific details: team names, product names, terminology, output format preferences.

3. Upload Knowledge Files

   Upload the documents Claude needs to be genuinely useful in this Project. Don't over-upload — prioritise the documents that Claude will actually reference. PDFs, Word documents, spreadsheets, and text files are all supported.

4. Configure Tools (if applicable)

   If this Project needs MCP server access or specific Skills, configure them in the Project settings. Skills configured at the Project level are automatically available in every conversation without manual invocation.

5. Test with Representative Tasks

   Start a conversation and ask Claude to complete a task you'd typically do in this Project. Evaluate the output. Iterate on your instructions until the output quality meets your standard. This is worth the investment.

Enterprise Claude Project Patterns

There's no single right way to structure Projects for an enterprise deployment. But patterns emerge from the 50+ implementations we've managed. Here are the four most effective patterns, with examples of what they look like in practice.

Writing Great Project Instructions

Project instructions are the highest-leverage configuration you can do in a Project. Most users write one or two generic lines. The enterprises that get the most value from Projects write 400-600 words of specific, actionable context. Here's what to include.

Role and Purpose

Define what Claude's role is in this Project. "You are the AI assistant for Acme Corp's Legal team. Your primary function is to support contract review, regulatory research, and compliance analysis. You work alongside three senior lawyers and a paralegal." This framing shapes how Claude prioritises and presents information.

Organisational Context

Include the facts Claude needs to be accurate: your company name, industry, key products, major clients, relevant regulatory environment, and any industry-specific terminology. If your team uses specific abbreviations or internal terms, define them. Claude will use them correctly in every response.

Output Preferences

Specify your format and style preferences. "Always produce executive summaries before detailed analysis. Use bullet points for risk lists. Flag items requiring urgent action in bold. Keep responses under 800 words unless the task requires more detail." These instructions eliminate reformatting work downstream.

Scope and Constraints

Define what Claude should and shouldn't do in this Project. Legal Projects typically include: "Do not provide legal advice or recommend specific legal positions. Flag items for attorney review rather than reaching conclusions." Finance Projects might include: "Do not speculate on stock prices or make investment recommendations. Summarise factual information and flag uncertainties."

Shared Projects for Team Collaboration

Claude Team and Enterprise plans support shared Projects — a single Project workspace accessible to multiple team members. Shared Projects are one of the most powerful features for collaborative work: every team member's conversations contribute to the shared context, knowledge files are available to everyone, and the Project becomes a genuine team AI workspace rather than an individual tool.

Shared Projects require thoughtful governance. Who can modify the Project instructions? Who can add or remove knowledge files? Who has access to conversation history? Claude Enterprise's admin console includes Project-level access controls — set these up at the start of deployment, not after a governance incident forces the issue. Our Claude governance service includes Project access policy frameworks.

For enterprise deployments, shared Projects pair naturally with a Skills library: the Project provides the context (instructions + knowledge files), the Skills provide the capability (reusable task instructions), and together they create a highly capable, consistently-performing AI workspace that any team member can use without deep Claude expertise.

Projects vs Conversations: When to Use Each

Not every task needs a Project. Projects add overhead — setup time, knowledge file management, instruction maintenance. For a one-off question or a task you'll never repeat, a regular conversation is faster. The test is recurrence: if you're doing the same type of work with the same context more than twice a week, it belongs in a Project.

The other signal is context depth. If you find yourself spending more than two minutes at the start of a conversation explaining background, you need a Project. That explanation time is wasted every single session. Put it in Project instructions once, and it never happens again.

Knowledge File Strategy: What to Upload

The temptation is to upload everything. Resist it. Projects have file size limits, and more importantly, Claude performs better when it has focused, relevant context rather than a large undifferentiated document library. A few principles for knowledge file selection: upload documents Claude will actually reference frequently (product specs, style guides, regulatory frameworks); upload factual reference material rather than process documentation (the what, not the how — the how goes in instructions); keep files updated when they change, or Project outputs will reference outdated information.

For very large document libraries — thousands of contracts, research papers, or technical documents — Projects aren't the right architecture. That's a RAG system built on the Claude API, where documents are retrieved dynamically based on relevance rather than loaded wholesale into context.

Related Articles