What You Need to Know
Two Containers, Two Jobs
Anthropic's Help Center describes a Project as a self-contained workspace with its own chat histories and knowledge base. It has two configurable halves, documented separately because they do different work. Custom instructions are where you set how Claude should behave and respond. They tailor Claude's responses: for example, a more formal tone, or answers from the perspective of a specific role or industry. Project knowledge is the material Claude works from. You upload relevant documents, text and files to the knowledge base. Claude draws on them to understand the context and background of chats in the Project. Instructions answer "how should this work be done?" Knowledge answers "what should it be done from?"
Take a window cleaning firm whose manager writes quotes and reminders every week. Each time, she tells Claude to write to homeowners in plain words and give the next visit date. Each time, she attaches the price list, the terms of service and good past replies. Both halves are ordinary setup steps in the Project screen: write and save the instructions, then use the add button to upload the knowledge files.
The Container Test
Setting a Project up well comes down to one sorting decision, applied piece by piece. Is this a rule about behaviour, or material to consult? For the window cleaning firm, "write to homeowners in plain words" is behaviour, so it goes in the instructions. The price list is material, so it goes in the knowledge.
The test matters because each container has properties the other lacks. Claude applies the instructions to every chat in the Project. Knowledge is consulted when the work calls for it. A knowledge file can be swapped in one step when the document is revised. A policy pasted into the instructions has to be found and cut out by hand.
The Two Wrong-Container Failures
The first failure is reference material pasted into the instructions, usually offered as thoroughness: put the whole policy where Claude can never miss it. The behavioural rules then drown in the pasted content. When the policy is revised, the stale text is trapped somewhere it can't be cleanly replaced. Paste the firm's terms of service into the instructions and its two rules sit inside pages of terms.
The second failure is the reverse: a rule buried in the knowledge base. A house style guide uploaded as a document is material about behaviour, not an instruction. Nothing marks it as governing every response, so it is applied only when the Project happens to consult it. The firm's style guide, uploaded as knowledge, would hold only some of the time. Sometimes is not a standard. A rule the work depends on every time belongs in the instructions, stated as a behaviour.
Build the Setup from What You Already Do
The method needs no fresh analysis, because anyone doing the work by hand already holds both lists. Whatever you re-explain at the start of every conversation is the instruction set: the audience, the tone, the format, the standing rules. Whatever you re-attach is the knowledge base: the policies, the templates, the past examples. At the window cleaning firm, the two rules become instructions and the three files become knowledge. Write the first list as behaviours and upload the second as files. Then run the next real task with a short task-only prompt, and note what you no longer had to say.
In the exam
This objective starts after the Project decision and tests setting the Project up well. Whether a piece of work deserves a Project at all is Domain 3's judgement. Where a Project sits in a wider process is Domain 4's. Most items here are the container test set inside a scenario, so drill it until it is automatic. Both wrong-container failures are common in real setups and make reliable distractors. Because the stem begins after that decision, "use a Project" is never the keyed answer here. An option that re-litigates it has wandered back into Domain 3.
Key Concept
When an exam item offers competing setups, apply the container test to each piece the stem mentions. The keyed answer routes behaviour to the instructions and material to the knowledge. The distractors route at least one piece the other way, usually dressed as thoroughness or tidiness.
Exam Traps
Pasting the reference document into the custom instructions so Claude can never miss it
The behavioural rules drown in the pasted content, and when the document is revised the stale text is trapped in the instructions instead of being swapped as a knowledge file. Thoroughness is exactly how this distractor is dressed.
Uploading the standing rule as a knowledge document and expecting it to govern every response
Knowledge is material Claude consults, not standing behaviour. A rule that must hold every time gets applied only sometimes unless it is stated in the instructions, which is the job instructions exist to do.
Skipping the Project and re-explaining and re-attaching everything in each chat, dressed up as keeping things current
Currency is handled by swapping the knowledge file when the source document changes. The per-chat workaround re-introduces the exact overhead the Project removes, and it depends on every user remembering to do it.
Practice Scenario
The secretary of a tenants and residents association has decided the estate casework and the monthly meeting papers belong in one Project and is now setting it up. Two pieces are in hand: the association repairs policy, and the rule that every letter must name the responsible officer and the date the repair was reported. Where should each go?
Build Exercise
Sort a Month of Manual Work into the Two Containers
What you'll learn
- How to identify the instruction set hiding in what you re-explain every chat
- How to identify the knowledge base hiding in what you re-attach
- How to apply the container test to ambiguous pieces
- How to confirm the setup worked by what you no longer had to say
- Pick a recurring piece of work you currently run in ordinary chats: something where you re-explain context and re-attach files each time
Why: The two lists a Project needs already exist in your manual habit; a recurring task makes them visible.
You should see: One line naming the task and how often it recurs.
- Write two lists from memory of your last few conversations: everything you re-explained, such as audience, tone, format and standing rules, and everything you re-attached, such as policies, templates, examples and data
Why: The re-explained list is the instruction set and the re-attached list is the knowledge base; the sorting is already done by your own behaviour.
You should see: Two written lists, one of behaviours and one of documents.
- Create a Project, write the first list into the custom instructions phrased as behaviours, and upload the second list as project knowledge
Why: Phrasing instructions as behaviours keeps them checkable, and uploading the real documents beats describing them.
You should see: A saved instruction set and a populated knowledge base in the Project screen.
- Apply the container test to every item that feels ambiguous: is it a rule about behaviour, or material to consult? Move anything sitting in the wrong half
Why: The ambiguous items are where real setups go wrong, and the test resolves them one question at a time.
You should see: At least one item you moved, or a note that everything survived the test in place.
- Run the next real task in the Project with a short task-only prompt, and note what you no longer had to say
Why: The proof of a good setup is a shrinking prompt; anything you still had to explain belongs in one of the two containers.
You should see: A first output comparable to your usual standard, from a fraction of the usual prompt.
Sources
- What are projects? — Anthropic
- How can I create and manage projects? — Anthropic
- How do usage and length limits work? — Anthropic
- Claude Certified Associate – Foundations Exam Guide — Anthropic