Field note
Claude Projects: Context Management
A Claude Project works best as a small, curated working space with a clear owner, not as a copy of the shared drive.
A Claude Project works best as a small, curated working space with a clear owner, not as a copy of the shared drive.
The pattern
A Project has three parts. Project instructions tell Claude how to behave in every chat inside the project. Project knowledge is the set of files and text you upload, which is available across all chats in that project. Then there are the chats themselves, each with its own context window.
Projects are available on every plan at the time of writing, with free accounts limited to five. On Team and Enterprise plans a project can be shared with colleagues with "Can view" or "Can edit" access, and organisation-wide where an admin allows it. Project memory is kept separate from memory in non-project chats, so moving a conversation into or out of a project changes what Claude remembers.
Two behaviours matter for context management:
- When project knowledge approaches the context window limit on a paid plan, Claude switches to a retrieval mode and pulls in the parts relevant to the question instead of loading everything. Bigger is still not better, but the project will not simply stop working.
- Content that is still cached counts less against usage limits when it is referenced again. Stable project files are cheaper than the same text pasted into each new chat.
The working rule: instructions describe the job, knowledge holds the reference material, and each chat is one task. If a project needs more than a screen of instructions, it is probably two projects.
A worked example
Take a ten-person accountancy practice that wants Claude to help draft client onboarding letters and engagement summaries.
Instructions, kept to about fifteen lines: the firm's name and tone, the required disclaimer wording, the house rule that every draft is marked "DRAFT for partner review", the date format, and an instruction to ask for the client's service list if it is missing.
Knowledge, six files: the current engagement letter template, the fee schedule, the services glossary, a one-page style guide, two anonymised examples of good letters. No client files. Client details go into the individual chat, not the project.
Chats: one per client, titled with the client name and date. When a letter is done, the final version is saved to the practice management system. The chat is not the record.
Ownership: one partner owns the instructions and the template. When the fee schedule changes, they replace that one file the same day and delete the old one. Every quarter they open the project, look at the file list, and remove anything no chat has used.
Result: each new chat starts with a small, current, cached set of material. Context problems become rare, answers stay consistent between staff, and the audit question "which template did this come from" has an answer.
Pitfalls we see most often
- The shared drive dump. Uploading forty policies "just in case". Retrieval mode helps, but contradictory old versions produce contradictory answers. Curate, and date-stamp filenames.
- Instructions that are really knowledge. Pasting the whole style guide into instructions loads it into every turn of every chat. Put long reference material in knowledge and keep instructions short.
- Stale files. A project set up in January still carries last year's price list. Give every project an owner and a review date.
- Client or staff data in project knowledge. Anything in knowledge is visible to everyone with access and used in every chat. Personal data belongs in the specific chat where it is needed, and HR material needs its own boundaries. See AI chatbot HR data boundaries.
- One endless chat inside the project. The project keeps the reference material; the chat still fills. Start a new chat per task and write a handover when switching. Our note on a full context window covers the recovery steps.
- Sharing too widely. Organisation-wide sharing is convenient and hard to unpick. Share with the team that does the work and grant "Can edit" to the owner only.
- Treating the project as the source of truth. The engagement letter template lives in the document management system; the project holds a copy. When they differ, the system wins, and the copy gets replaced.
A simple governance check
Before rolling projects out to a department, write down for each project: its purpose in one sentence, the owner, the audience, the list of files with dates, the data classes that are allowed and not allowed, and the review date. Keep that list with your other AI records. It takes twenty minutes and it is what an auditor, a new starter or a partner asks for six months later.
If you would like help designing the first few projects and the rules around them, our AI governance review covers exactly this kind of workspace design.