Projects · 8 of 20
What Projects Are
A Project pairs a knowledge base with standing instructions, so Claude already knows the context every time you open it.
A single chat is perfect for a quick question. But live deal work is not a quick question: you return to the same CIM for weeks and brief Claude the same way every session. The moment you find yourself re-attaching the same files and re-explaining the same context every time you open Claude, you have outgrown the chat box. That is exactly what a Project is for.
What a Project is
A Project is a dedicated workspace that holds two things together:
- A knowledge base: a set of files Claude always has in view. Upload a target’s documents once and every chat inside the Project can read them, with no re-attaching.
- Custom instructions: a standing brief that tells Claude who it is helping, how to behave, and how to format its answers. You write it once and it applies to every conversation in that Project.
Think of it as giving Claude a desk with the right files already laid out and a note pinned above it explaining the job. You walk up, ask your question, and it answers in context immediately.
Instructions
You are assisting a private equity team screening Project Atlas, a mid-market field-service software target. Be precise, cite the source document for every figure, and flag anything the materials leave unclear.
Project knowledge
Why this beats re-attaching files each chat
Working inside a Project is not just tidier. It changes the quality and the safety of the work in three concrete ways.
Persistent context
In a plain chat, the file lives only in that one conversation. Start a new chat tomorrow and Claude has forgotten everything. In a Project, the knowledge base and the instructions persist. You can open the Project on Monday, ask three questions, close it, and pick up on Thursday exactly where the context left off. The materials are always loaded and the brief is always applied.
Consistency
Because the custom instructions sit above every chat in the Project, Claude answers the same way each time. If your brief says “cite the source document for every figure” and “flag anything the materials leave unclear”, it will do that in the first conversation and the fiftieth. You stop re-typing the same framing and you stop getting the wandering, inconsistent output that comes from briefing Claude slightly differently every session.
Confinement of data
This is the one that matters most for Private Equity work. Each Project is a container. A live opportunity’s documents go into that opportunity’s Project and nowhere else. A chat in one Project cannot see the files in another. That separation is what lets you keep each opportunity siloed.
When to use a Project (and when not to)
You do not need a Project for a one-off task. If you want a quick read of a public teaser, a plain chat is faster. Reach for a Project when any of these are true:
- You will return to the same material more than once.
- You want consistent behavior across many conversations (the same role, tone, and format).
- The material must stay separated from other work.
- Several people on the team will work against the same shared knowledge base.
Almost all serious deal work meets at least one of those tests, which is why Projects, not loose chats, are where it belongs. If you want to see this in action before reading further, the Project Atlas walkthrough runs a full opportunity through one.
A first picture, before the detail
The example above is a single Project for a single live opportunity. That is one of two kinds of Project you will use, and the distinction between them is the most important idea in this whole section. Some Projects are reusable and persist across many opportunities (your methodology and templates). Others are one-time and exist only for one live opportunity (its data room, siloed and then archived).
The next page lays it out in full: Reusable vs Deal Projects.