Configuration and Knowledge Management · Lesson 1 of 4

5.1 — Configuring a Claude Project: Instructions and Knowledge Sources

Set up a Claude Project's two persistent configuration levers — custom instructions and an uploaded knowledge base — so reference material and standing behavior carry into every future conversation automatically.

A Claude Project is a persistent workspace, not just a single conversation. Everything you configure at the Project level — its instructions and its uploaded knowledge base — carries forward automatically into every conversation started inside that Project, for every teammate with access, not just the conversation where you set it up. That persistence is the whole point: a legal team's "Contract Review" Project should behave the same way in the fortieth conversation as it did in the first, without anyone re-explaining the team's conventions or re-uploading the templates each time.

Configuring a Project well means deliberately using its two separate levers for two separate jobs: instructions for standing behavior (role, tone, house rules) and the knowledge base for reference material (documents Claude should draw on). Treating a Project like a single scratch conversation — pasting reference text into one message instead of the knowledge base, or writing instructions that only make sense for today's specific task — throws away the persistence a Project is built to provide.

Two Levers: Instructions and Knowledge

The Project's custom instructions field is where standing behavior lives: the role Claude should take, formatting defaults, and rules that should apply across essentially every conversation in the Project. The knowledge base is a separate area where you upload the actual reference documents — templates, style guides, product specs, prior work — that give Claude something concrete to work from. A well-configured "Contract Review" Project might have instructions saying "You are reviewing vendor contracts against our standard terms; flag any clause that deviates from the uploaded template," with the actual standard-terms template and a library of past contracts sitting in the knowledge base for Claude to reference. Neither lever does the other's job well: instructions describing document contents in prose are a poor substitute for the real document being available to search and quote from, and an uploaded document with no instructions leaves Claude to guess how you want it used.

Supported Knowledge Base File Types

The knowledge base accepts common document formats directly — including DOCX, PDFs, and plain text — so a team can upload existing documents as-is rather than converting everything to plain text first. This matters in practice: most real reference material (contract templates, brand guidelines, onboarding docs) already exists as a Word file or a PDF, and requiring conversion before every upload would be enough friction that a team's knowledge base never gets properly filled in.

Configuring the knowledge base well is also about upkeep at upload time, not just format support: give files clear, current names, and avoid uploading two versions of the same reference document side by side (an old style guide next to its replacement) — conflicting versions in the knowledge base can lead Claude to draw on outdated guidance without any obvious sign that it did. As a side note, this is a different mechanism from prompt caching, which is a cost/latency optimization for repeated content within a session rather than the thing that makes uploaded knowledge available across conversations in the first place — the knowledge base upload is what does that.

Key Concept

A Project's instructions and knowledge base are both persistent and both automatic: once configured, every new conversation inside the Project inherits them without anyone re-pasting content or re-stating rules. Instructions carry standing behavior; the knowledge base carries reference material in its original common formats (DOCX, PDF, plain text, and more).

Common Exam Distractor

Watch for answers suggesting a team re-paste reference material into each new conversation, or convert every document to plain text before it can be used — both misunderstand what the knowledge base is for. Also watch for answers that reach for prompt caching to explain why uploaded knowledge is available in a fresh conversation; caching optimizes repeated content within a session, it isn't the mechanism behind a Project's persistent knowledge base.

Exam traps

Assuming a Project's knowledge base only accepts plain text files

Common document formats including DOCX and PDF are supported directly, letting teams upload existing documents without converting them first.
Assuming uploaded reference material must be re-pasted or re-described in each new conversation inside the Project

The knowledge base is available automatically to every conversation in the Project — that persistence across conversations is its core purpose.
Treating prompt caching as the mechanism that makes knowledge base content available across conversations

Prompt caching is a separate cost/latency optimization for repeated content within a session; it isn't what gives a Project's knowledge base its persistence across conversations.

Practice question

A team is setting up a new Claude Project for reviewing vendor contracts. They have a standard-terms template saved as a DOCX file and want every future conversation in the Project to check new contracts against it without re-explaining the process each time. What is the correct way to configure this?

A Paste the full text of the template into the first conversation's message, since every conversation in the Project shares that message history
Conversations in a Project don't automatically share each other's message history — pasting into one conversation doesn't make the template available in the next one.
B Upload the DOCX template to the Project's knowledge base and add instructions describing the review process and how to use the template Correct
This uses both levers correctly: the knowledge base holds the actual reference document in its native format, and the instructions describe the standing process — both persist automatically across every conversation in the Project.
C Convert the template to plain text first, since the knowledge base doesn't support DOCX files
The knowledge base supports common document formats including DOCX directly; conversion to plain text isn't required.
D Rely on prompt caching to keep the template available across conversations
Prompt caching optimizes repeated content within a session; it doesn't make a document available to future conversations. Uploading to the knowledge base is what achieves that.

Build exercise: Configure a Project's Instructions and Knowledge Base

Beginner · 20 minutes

You'll practice:

Distinguish what belongs in Project instructions versus the knowledge base
Upload a non-plain-text reference document to a Project's knowledge base
Confirm both configuration levers persist automatically into a brand-new conversation

In claude.ai, create a new Project. In its custom instructions field, write two or three sentences describing a role and a standing rule (for example: 'You are reviewing short vendor documents against our standard terms; flag anything that deviates from the uploaded template and explain why in one sentence').

This sets up the standing-behavior half of Project configuration, separate from any specific document.

You should see: The instructions saved in the Project's settings, visible whenever you reopen the Project's configuration panel.
Hints
1. ```
Keep the instructions general enough to apply to more than one specific document you might review.
```
2. ```
Avoid mentioning a specific file name in the instructions — that belongs in the knowledge base, not the standing rule.
```
3. ```
If you don't have a real template, invent one conceptually (e.g. 'payment terms must be net-30 or shorter').
```
Upload a reference document to the Project's knowledge base. Use a DOCX file if you have one, or another common document format, and give it a clear, current file name.

This confirms hands-on which file types the knowledge base actually accepts, and establishes the reference-material half of Project configuration.

You should see: The document listed in the Project's knowledge base without needing to be converted to plain text first.
Hints
1. ```
If you don't have a DOCX file handy, create a short one in any word processor and export it.
```
2. ```
Name the file something specific and dated (e.g. 'standard-terms-template-2026.docx') rather than something generic.
```
3. ```
Note in one sentence what would happen if you later uploaded a second, conflicting version of the same document without removing the first.
```
Start a brand-new conversation inside the Project (not the one where you set anything up) and ask a question that depends on both the instructions and the uploaded document, without restating either.

This is the real test of Project-level configuration: both levers should apply automatically to a conversation that never directly saw them being set.

You should see: A response that follows the standing rule from your instructions and correctly references the content of the uploaded document, in a conversation where you never pasted or described either one.
Hints
1. ```
Ask something specific enough that Claude must have actually used the uploaded document to answer correctly.
```
2. ```
If either the rule or the document content is missing from the response, double-check both were actually saved at the Project level rather than left in a single conversation.
```
3. ```
This is the pattern that scales to a real team: configure once, reuse automatically across every future conversation and teammate.
```

Sources

Reused/adapted from Associate lesson 2-6-caching-and-knowledge-base-files (knowledge base file types), reframed around Project configuration
Anthropic docs — Projects