# Configuring & Maintaining Claude Projects > A Claude Project is a self-contained workspace with its own chat history and its own knowledge base, configured through two layers: project knowledge (uploaded files) and project instructions (a standing behavioral brief). Nothing said in one chat automatically becomes visible to other chats in the same project - only what's explicitly placed in knowledge or instructions persists, and keeping those instructions swapped and current is a recurring maintenance task, not a one-time setup step. **Domain:** CCAOF-D5 · Configuration & Knowledge Management (12% of the exam) **Canonical:** https://claudearchitectcertification.com/concepts/configuring-claude-projects **Last reviewed:** 2026-05-04 ## Quick stats - **Configurable layers per project:** 2 (knowledge + instructions) - **Exam domain:** CCAOF-D5 - **Domain weight:** 12% - **Free-tier project cap:** 5 - **RAG capacity boost when knowledge grows:** up to 10x ## What it is A Project is distinct from a plain one-off chat: every chat started inside a Project belongs to that Project and draws on a shared knowledge base and shared instructions, so a recurring piece of work, a client account, a role, a workflow, doesn't require re-explaining context every conversation. What's shared is the knowledge and the instructions, not the conversational memory itself - each individual chat inside a Project is still its own separate thread, and one chat's back-and-forth is not automatically visible to another chat in the same Project. Two configurable layers do the sharing. Project knowledge is whatever gets uploaded, documents, text, or code the project can draw on. Project instructions is a standing brief telling Claude how to behave inside that project specifically, tone, role, or industry perspective, separate from any single chat's back-and-forth. Configuring a Project is only half the objective. The other half, informing, maintaining, and updating that configuration as needs change, is just as tested: a Project set up once and never revisited drifts stale exactly the way a document left unedited does. Swapping an outdated uploaded file for a current one, or editing instructions when a role or engagement changes, is the ongoing maintenance half of this skill, not a one-time task. ## How it works Setting up the two layers is a UI action, not engineering. To add knowledge, click "+" on the project's knowledge panel and upload documents, text, or code. To add instructions, click "Set project instructions," write the brief, and click "Save instructions." Projects are available to every user, including free accounts, though free accounts are capped at a maximum of five projects. Context does not silently carry across chats. A single chat's back-and-forth inside a Project does not automatically become project-wide context for other chats, only content explicitly placed in the knowledge base or the instructions persists across every chat in that Project. This is the single most commonly tested misunderstanding in this domain. Knowledge capacity scales without manual setup. RAG (retrieval-augmented generation) for Projects is now available on every plan, free, Pro, Max, Team, and Enterprise, and activates automatically once project knowledge approaches its context-window limit, retrieving only the most relevant snippets per query instead of loading the whole knowledge base every turn. This expands effective capacity by up to 10x with no configuration required, and the system can revert to standard processing if the content volume later shrinks. Instructions exist at three separate tiers, and only one is Project-specific. Account-wide "Instructions for Claude" apply to every conversation regardless of Project. Project instructions apply only inside that one Project. Skills add reusable behaviors or capabilities Claude can invoke, a related but distinct "styles" control also exists for response formatting specifically, so a business user configuring a Project should default to Project instructions for anything scoped to that Project alone, not the account-wide layer. Maintaining a Project (CCAOF-D5-O4) means keeping instructions concise and swapping stale knowledge, not writing a longer brief. Anthropic's own guidance is that Claude performs best when project instructions carry general context, key guidelines, and Claude's role, while task-specific detail for one particular ask belongs in the individual chat instead, because shorter instructions leave more context budget for the knowledge that actually needs to be retrieved. When an underlying document changes, a renegotiated contract, an updated policy, the maintenance action is replacing the uploaded file and revising instructions if the role or tone shifted too, not layering a correction into a single chat that other chats in the Project will never see. ## Where you'll see it in production ### Client onboarding Project A PM uploads the client's SOW, prior meeting notes, and a style guide to project knowledge, then writes project instructions telling Claude to answer as a senior consultant in a formal tone, every new chat inherits both automatically. ### Ongoing policy-reference Project maintenance An HR team keeps an internal policy-Q&A Project current by replacing the uploaded policy PDF each time a policy updates, rather than letting the Project answer from a stale document indefinitely. ## Comparison | Layer | Scope | Persists across chats in the Project? | Best for | | --- | --- | --- | --- | | Instructions for Claude (account-wide) | Every conversation, any Project | Yes, everywhere | General preferences that apply no matter what you're working on | | Project instructions | One Project only | Yes, within that Project | Role, tone, and general context specific to this Project | | Project knowledge (uploads) | One Project only | Yes, within that Project (via RAG once large) | Reference documents the Project needs repeatedly | | A single chat's own conversation | That one chat only | No | Task-specific, one-off instructions for the current ask | ## Decision tree 1. **Will multiple future chats in this Project need this information, not just the one you're in now?** - **Yes:** Put it in project knowledge (a document) or project instructions (a behavioral rule) so it persists. - **No:** Keep it in the current chat, it doesn't need to survive across chats. 2. **Is the underlying source document (contract, policy, SOW) now out of date?** - **Yes:** Replace the uploaded file in project knowledge, this is the maintain-and-update half of the objective, not a one-time setup task. - **No:** No knowledge update needed yet. 3. **Is the instruction general (role, tone, scope of the Project) rather than specific to one task?** - **Yes:** Belongs in project instructions, kept concise so it leaves context budget for retrieved knowledge. - **No:** Belongs in the individual chat instead, task-specific detail bloats project instructions and degrades performance. 4. **Does the Project's knowledge base now approach the context-window limit?** - **Yes:** No action needed, RAG mode activates automatically on every plan and expands capacity up to 10x. - **No:** Standard full-context loading applies as normal. ## Exam-pattern questions ### Q1. A consultant has a long, detailed discussion about a client's edge-case pricing scenario in one chat inside their "Client X" Project, then opens a fresh chat in the same Project expecting Claude to already know about it. What happens? By default, the new chat does not carry over that discussion - conversational context is not automatically shared across separate chats in a Project (a Project shares its knowledge + instructions, not each chat's memory). The exception is Claude's Memory/chat-search features, which, when enabled, can surface a summary of prior chats. The distractor "anything discussed in any chat within a project is automatically available to other chats in that project" overstates it - that blanket automatic sharing is not the default behavior. ### Q2. A PM writes a 2,000-word project instructions document containing step-by-step formatting rules for one specific Friday deliverable. Is this the right place for that content? No. Anthropic's guidance is to keep project instructions concise and general (role, tone, key context) and put task-specific detail in the individual chat instead, since shorter instructions preserve more context budget for retrieved knowledge. The distractor "put all task-specific detail into project instructions since it's more thorough" inverts the actual best practice. ### Q3. A free-tier user already has 5 active Projects and tries to create a 6th. What should they expect? They cannot, free accounts are capped at a maximum of five Projects; they would need to delete or archive an existing one, or upgrade, first. The distractor "free accounts have unlimited projects since Projects launched to everyone" confuses availability to all users with an unlimited count, Projects are available to free accounts, but with a five-project ceiling. ### Q4. A Team-plan Project's knowledge base grows past its context-window limit over several months of uploads. What does the admin need to configure to keep the Project working well? Nothing. RAG for Projects is available on every plan, free through Enterprise, and activates automatically once knowledge approaches the limit, retrieving the most relevant snippets per query and expanding effective capacity up to 10x with no setup. The distractor "the admin must manually enable RAG mode in project settings before it activates" describes a configuration step that does not exist, activation is automatic. ### Q5. A vendor contract inside a "Q3 Vendor Review" Project's knowledge base gets renegotiated with new terms. The PM pastes the new terms into today's chat so the current conversation reflects them. Is this sufficient maintenance? No. Pasting into one chat only fixes that single conversation, other chats in the Project, current and future, will still see the outdated uploaded contract. The correct maintenance action is replacing the stale file in project knowledge (and updating project instructions if the change affects role or tone), which is the update half of CCAOF-D5-O4. The distractor "paste the new terms into today's individual chat so this conversation has them" fixes the symptom in one chat, not the underlying stale configuration every other chat in the Project will keep seeing. ## FAQ ### Q1. Is everything discussed in one Project chat automatically remembered by other chats in the same Project? No. Only content explicitly placed in project knowledge (uploads) or project instructions persists across chats. A single chat's own conversation does not become project-wide context on its own. ### Q2. Do I need to manually turn on RAG when a Project's knowledge base gets large? No. RAG for Projects is available on every plan and activates automatically once knowledge approaches the context-window limit, expanding effective capacity up to 10x with no setup required. --- **Source:** https://claudearchitectcertification.com/concepts/configuring-claude-projects **Last reviewed:** 2026-05-04 **Evidence tiers**, 🟢 official Anthropic doc / API contract · 🟡 partial doc / inferred · 🟠 community-derived · 🔴 disputed.