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. A Project has two configurable halves. The Help Center documents them 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 uses 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?"
This lesson uses one made-up example throughout: a publishing company whose sales assistant writes price quotes and payment reminders to bookshops every week. Each time, she tells Claude to write to bookshops in plain words and give the next delivery date. Each time, she attaches the price list, the terms of sale 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 same screen asks for a name and a description. Claude cannot see either of them, so a rule typed there has no effect. They only tell people what the Project is for.
The Container Test
Configuring a Project well depends on one sorting decision, which you apply to each piece in turn. Is this a rule about behaviour, or material to consult? For the publishing company, "write to bookshops in plain words" is behaviour, so it belongs in the instructions. The price list is material, so it belongs in the knowledge.
The test matters because each container has properties the other lacks. Claude applies the instructions to every chat in the Project, as directions on how to behave. Claude also uses the knowledge as context in every chat in the Project. You can replace a knowledge file in one step when the document is revised. You have to find a policy that is pasted into the instructions and remove it by hand.
A context window is the amount of text Claude can hold at one time. When the knowledge comes close to that limit, Claude switches to a search mode called RAG (retrieval-augmented generation). In that mode it loads only the parts of the knowledge that match each question. Lesson 5.2 explains this search.
The Two Wrong-Container Failures
The first failure is reference material pasted into the instructions. The usual reason given is thoroughness: put the whole policy where Claude can never miss it. Then the pasted content hides the behavioural rules. When the policy is revised, the old text stays in a place where you cannot cleanly replace it. If you paste the company's terms of sale into the instructions, the two behavioural rules then sit inside pages of terms.
The second failure is the reverse: a rule that is only in the knowledge base. Suppose the company uploads its house style guide, the document that sets how its staff write, and writes no instructions. Claude uses the style guide as context, together with the price list and the terms. Nothing in the Project tells Claude that the rules in the guide apply to every reply. Instructions apply to every chat, and the guide is only material to draw on. A large Project has a second risk: when Claude searches the knowledge, it may not load the style guide for a given quote. Leave the style guide in the knowledge as reference. Write each rule that the work needs every time, such as "write to bookshops in plain words", into the instructions 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 has 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 publishing company, 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 how well you configure the Project. 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 questions here are a scenario that asks you to sort each piece as behaviour or material, which is the container test, so practise the test until it is automatic. Both wrong-container failures are common in real setups and make effective wrong options. Because the question begins after that decision, "use a Project" is never the right answer here. An option that argues that decision again belongs to Domain 3.
Key Concept
When an exam question offers competing setups, apply the container test to each piece the question mentions. The right answer puts behaviour in the instructions and material in the knowledge. The wrong options put at least one piece in the other container, usually presented as thoroughness or tidiness.
Exam Traps
Pasting the reference document into the custom instructions so Claude can never miss it
Pasted reference text hides the behavioural rules. When the document is revised, the old text has to be found and cut out by hand, whereas a knowledge file can be replaced in one step. Keep the rules in the instructions.
Uploading the standing rule as a knowledge document and expecting it to govern every response
Claude uses knowledge as context, not as directions for every reply. Nothing tells it to apply a rule in a document every time, and in a large Project the search may not load that document. Put a standing rule in the instructions.
Skipping the Project and re-explaining and re-attaching everything in each chat, presented as keeping things current
Keeping material current 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
A team leader at an insurance company has decided the customer claim letters and the monthly team reports belong in one Project and is now setting it up. Two pieces are in hand: the company claims policy, and the rule that every letter must name the claim handler and the date the claim 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 contained in what you re-explain every chat
- How to identify the knowledge base contained 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 works better than 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 passed the test where it was.
- 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 evidence of a good setup is a prompt that gets shorter; 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
- Retrieval augmented generation (RAG) for projects — Anthropic
- Claude Certified Associate – Foundations Exam Guide — Anthropic