In Claude, use a plain chat for a one-off question, a Project for ongoing work that needs the same files and rules every time, and Research when you need a careful look across many sources.
Imagine you open a new chat on Monday, and the rules you typed last week are gone, so you type them all again. A Project fixes that. It works like a labeled drawer: your instructions, your files, and the related chats stay together.
This continues Learn Claude from scratch. By the end, you will have a simple starter Project you can copy.
The map: chat, Project, files, Research
People mash four ideas together in casual conversation. Keep them separate in your own head:
| Thing | What it is | Lives across chats? | Best for |
|---|---|---|---|
| Bare chat | One conversation thread | No (only that thread’s history) | One-off tasks, experiments, disposable drafts |
| Project | Workspace with its own chats, instructions, knowledge files | Yes, for material you put in the Project | Recurring work with stable rules and docs |
| Chat file upload | Attachment for this conversation | No | One document review, one screenshot, one CSV peek |
| Project files / knowledge | Files attached to the Project | Yes, for chats inside that Project | Style guides, specs, glossaries, long-running briefs |
| Research | Multi-step search mode with citations (paid plans) | Result lives in the chat you ran it in | Comparisons, multi-source digs, longer reports |
Anthropic’s help center describes Projects as self-contained workspaces with their own chat histories and knowledge bases. You can upload documents, set project instructions, and run focused chats inside that box. Free accounts can use Projects too, capped at five of them. Paid plans raise that capacity and make large knowledge bases more practical, including a smarter retrieval behavior once the content inside grows large.
When bare chat is enough
Start in bare chat when the work is disposable or a one-time thing:
- Rewrite this one email.
- Explain a concept you will not revisit this month.
- Brainstorm names you will paste into a ticket and then forget.
- Debug a one-line formula with no house style attached.
- Try out a prompt pattern before you decide it belongs in a Project.
Bare chat is also the right place to fail safely. If the thread gets messy, start another one, because you have not polluted a knowledge base yet.
Rule of thumb: if you cannot name the Project in five words, stay in bare chat. “Stuff” is not a Project. “Q3 board narrative” is.
When a Project earns its keep
Create a Project when at least two of these are true for the work in front of you:
- You will return to it more than twice this month.
- The same instructions should apply every time, such as tone, audience, and hard refusal rules.
- The same documents should be available without re-uploading them each time.
- You want related chats grouped together so you can actually find them later.
- On Team or Enterprise, you may want to share the workspace with others, since sharing is a paid org feature.
Examples that usually deserve a Project:
- Course or certification prep with a fixed reading list.
- Product launch messaging with brand voice notes attached.
- An internal analytics glossary and metric specs for draft SQL and explanations. SQL is the language for asking a database questions.
- A client engagement, with careful redaction rules written into the instructions.
- Book or paper notes you expect to query, meaning ask questions of, for months.
Examples that usually do not deserve one: one resume tweak, a single travel itinerary, a joke thread, or a throwaway translation. None of those come back often enough to be worth the setup.
Project instructions versus project knowledge
These are two different knobs, and it helps to keep them apart:
- Project instructions are standing orders: how to write, what to refuse, who the audience is, which vocabulary to prefer. Keep them short enough that you will actually maintain them.
- Project knowledge (files) is source material: specs, PDFs, glossaries, outlines, sample spreadsheets. Claude uses them as background for chats inside the Project.
Instructions without files make a polite chatbot with a personality but nothing to point at. Files without instructions make a pile of paper with no house rules attached. Use both together for anything serious.
On larger knowledge bases, paid plans can search project content on demand instead of stuffing everything into one context window at once. The context window is how much text the model can hold in mind at once. Treat that as a capacity tool, not magic. If the wrong section gets pulled up, you still get a wrong draft back, so ask Claude for citations that point back to your file names and section headings whenever accuracy actually matters.
Files: chat uploads versus project knowledge
You can attach files inside a single chat, or add them to a Project’s files area instead. The two behave differently.
Chat uploads
Use a chat upload when the document only matters for this one task. Anthropic documents generous per-file size limits for chat uploads, on the order of hundreds of megabytes per file, along with caps on how many files you can attach per chat and how many pages a PDF can run. Images and multi-page PDFs have their own rules: shorter PDFs can include visual analysis of charts and layouts, while very long PDFs shift toward plain text extraction instead. Check the current upload help article when something fails, since these limits move over time.
Commonly supported document types include PDF, DOCX, CSV, TXT, HTML, RTF, EPUB, and JSON, along with everyday image formats such as JPEG, PNG, GIF, and WebP. Spreadsheet files often need code execution and file creation turned on in your capabilities settings before Claude can open them properly.
Project files
Project file limits work differently: a smaller per-file size in Anthropic’s docs, with the total content needing to fit inside usable context or the retrieval system. Project knowledge is meant for material you expect to reuse again and again, so prefer clean, current sources over dumping an entire drive into it.
Practical hygiene worth keeping:
- One canonical metric spec beats five conflicting decks sitting side by side.
- Date the filename, such as
brand-voice-2026-06.md. - Remove files you have replaced so the model does not blend old and new versions together.
- Prefer text-extractable docs over scanned image-only PDFs when exact wording matters.
- Do not put credentials, private keys, or full production dumps into knowledge “for convenience.”
What files are good at, and not
| Good fit | Weak fit |
|---|---|
| Style guides, glossaries, rubrics | Live databases (use exports or safe samples) |
| Stable product briefs | Hourly-changing ops numbers without a refresh habit |
| Syllabus and chapter PDFs you may use | Entire cloud drives “just in case” |
| Redacted schemas and sample rows | Real customer data, secrets, unrestricted extracts |
| Prior approved messaging | Conflicting drafts all marked final |
Research: multi-source digs with citations
Research is available on paid Claude plans (Pro, Max, Team, Enterprise) across web, desktop, and mobile. It is not the same as a quick web search. Anthropic describes Research as an agentic multi-search mode: Claude runs a sequence of searches that build on each other, then returns a thorough answer with citations you can actually check yourself. Web search has to be turned on for Research to work at all.
When to prefer each mode:
| Mode | Use when | Skip when |
|---|---|---|
| Ordinary reply (no tools) | You already pasted the source material | You need current external facts |
| Web search | Quick factual checks, a couple of lookups | You need a multi-angle report |
| Extended thinking / higher effort | Hard reasoning on material you already have | You mainly need fresh sources |
| Research | Comparisons, multi-source synthesis, digs that take about one to three minutes with citations | You only need a one-line fact or you are near usage limits |
Research counts against the same usage pool as ordinary chat, but it can burn through that pool faster, because it retrieves many sources and writes longer answers than a normal reply. Turn it on from the plus-sign menu next to the message box when your plan supports it, then ask a scoped question. If Claude does not seem to actually research anything, steer it explicitly: “Use the research tool to…”
If you connect workplace tools, such as Google Workspace connectors where they are available, Research can also pull in internal context you have already authorized. That is powerful, and it is also easy to overshare by accident. Prefer the smallest access you can get away with, and never treat a connector as a substitute for a real access review. A later post in this series goes deeper on privacy and paste rules; the short version is that if the document is sensitive, ask first whether it should be in Claude at all.
A Research prompt that stays honest
Use Research.
Question: Compare [A] and [B] for [specific decision].
Audience: [role].
Time horizon: sources from the last [N] months preferred.
Deliver:
1) One-page decision brief
2) Table of criteria with what each source supports
3) Open questions and conflicts between sources
4) Full citations with links
Refuse:
- Do not invent statistics
- Mark confidence low when sources disagree
- Separate fact from vendor marketing languageAfter the report lands, open at least two citations yourself before you trust any of it. Research reduces your hunting time. It does not replace your judgment on whether a given source is junk.
Starter Project kit
Build one Project this week, and keep it small enough that you will actually maintain it.
1. Name and purpose
Pick a name a future version of you will still understand:
AMS writing desk
Purpose: Draft AMS-style outlines and rewrites using house rules.
Not for: confidential client data, credentials, production dumps.Swap “AMS” for your own team or class name. The “not for” line belongs in the written instructions, not only in your head where you will eventually forget it.
2. Project instructions (copy and edit)
You help me draft for human review. I will edit before anything ships.
Voice:
- Plain English, concrete examples
- No hype, no empty praise
- No em dashes in drafts I will publish
Defaults:
- Ask for missing audience, goal, or length when absent
- Prefer bullets and short sections
- Flag assumptions and unknowns explicitly
Refuse:
- Invented numbers, quotes, citations, or case studies
- Pretending a draft is final
- Requests that need secrets I did not provide
When project files are present:
- Prefer them over general knowledge
- Name which file you used when it matters
- Say when the files do not cover the question3. Seed files (start with three)
| File | What to put in it | Why |
|---|---|---|
voice-and-refuse.md | Your tone rules and hard no’s | Reinforces instructions with examples |
glossary.md | 10 to 30 terms with your definitions | Stops synonym drift |
good-example.md | One past deliverable you actually liked | Beats abstract style advice |
Add more files only when a chat keeps missing the same fact. Grow the Project because something actually hurt, not because you thought you might need it someday.
4. First three chats inside the Project
Chat A: stress-test the instructions
Using only project instructions and files, draft a 200-word intro
for [topic] aimed at [audience]. Then list which rules you applied
and which files you used. If a rule blocked something, say so.Chat B: file Q&A
From glossary.md, explain [term] in two sentences for a new hire.
If the term is missing, say "not in glossary" and propose a draft
definition for me to approve. Do not invent org-specific policy.Chat C: rewrite against the good example
Rewrite the draft below to match the voice in good-example.md.
Keep my facts. Show a short diff-style list of changes after.
Draft:
[paste]If Chat A ignores your refusal rules, tighten the instructions and retest before you add ten more files on top.
Worked example: metric glossary Project for analytics
Say you support a weekly retail metrics review, and people keep arguing about what “active store” and “net revenue” actually mean. Bare chat keeps “helpfully” inventing its own definitions. You build a Project instead.
Name: Retail metrics desk
Instructions (short form):
You draft explanations and checklists for retail metrics.
Only use definitions from project files.
If a metric is missing, say so and propose a draft for human approval.
Never invent SQL table names.
When writing SQL drafts, label them "draft for review" and list assumptions.
Refuse customer-level raw extracts; sample rows only if I paste them.Files:
metric-active-store.md(grain, inclusion rules, known exceptions)metric-net-revenue.md(gross minus discounts, tax treatment, refund lag)sql-style.md(prefer explicit joins, noSELECT *in shared drafts)
Chat: “Explain active store for a new ops analyst in 150 words, then give three common mistakes.” Claude should stick to your file. If it invents a fourth rule anyway, your file is incomplete, or the model drifted, so fix the file rather than only scolding the chat.
When you later need current competitor pricing or public benchmark chatter, a benchmark being a standard test used to compare tools, that is a Research chat on a paid plan, not something you permanently stuff into the metrics Project without review. Keep durable definitions in knowledge. Keep transient web digests in ordinary or Research chats, then promote only the bits you verified into a dated note file once you trust them.
For SQL that might leave the Project, keep How to check AI-written SQL next to you. Project context reduces invention. It does not certify a query as correct.
Decision guide you can screenshot
- One task, no reuse: bare chat.
- One document, one pass: chat upload.
- Same rules and docs, many chats: a Project.
- Need multi-source external synthesis with citations: Research on a paid plan.
- Need hard reasoning on text you already have: higher effort or extended thinking, not Research.
- Need live, always-current numbers: not Claude at all; use the database, warehouse, or ticket tool directly.
Common mistakes with Projects and files
| Mistake | Symptom | Fix |
|---|---|---|
| Everything is a Project | Five empty Projects, zero good chats | Cap yourself: one Project per real recurring job |
| No instructions, only files | Inconsistent voice, soft refusals | Write a half-page instruction block |
| Conflicting PDFs in knowledge | Confident mashups | One canonical file; archive the rest outside |
| Stale knowledge | Last quarter’s prices and policies | Date files; replace, do not only append |
| Research for a dictionary definition | Slow, expensive answer | Ordinary chat or a single web search |
| Never opening citations | Polished wrong brief | Spot-check sources every time stakes are real |
| Secrets in project files | Long-lived exposure | Redact; use samples; follow the privacy habits from later in this series |
| Assuming Free equals Max knowledge scale | Surprise limits | Read plan caps; keep knowledge lean on Free |
How this fits Free versus paid plans
Projects exist for Free users too, with a small project count cap. As of September 2026, Anthropic’s projects help page is the place to confirm that cap. That is enough to learn the pattern. Paid plans matter once you live in Projects daily, need larger knowledge bases with retrieval scaling, want Research as a normal tool, or work inside Team or Enterprise shared projects. If you are still deciding whether Claude is a weekly habit, build one lean Project on Free and graduate when limits actually block real work, not the moment a pricing page makes you anxious.
Promoting a good chat into a Project
You will often start in bare chat simply because you did not know the work would repeat. That is fine. Promotion into a Project is a deliberate step, not a default.
Promote when you notice any of these:
- You re-pasted the same style rules three times this week.
- You re-uploaded the same PDF twice.
- You keep saying “remember, our definition of X is…”
- A teammate asks for the same explanation you already drafted once before.
How to promote without dragging the junk along with it:
- Create the Project with a clear name and a one-line purpose.
- Write the instructions from the rules you actually repeated, not from a fantasy style guide.
- Add only the current source files, and leave exploratory dead ends in the old bare chats.
- Run one stress-test chat inside the Project before you trust it for anything you would actually send.
- Archive or ignore the old bare threads so you stop editing in the wrong place by habit.
Do not try to migrate every historical message into the new Project. Memory and chat search, where your plan offers them, are different tools entirely. A Project is a curated workspace, and curation means leaving things out on purpose.
Questions people ask about this setup
How many Projects should I have?
As few as still match your real recurring jobs. Free accounts cap at five, as of September 2026 on Anthropic’s projects help page, which turns out to be a useful limit. On paid plans you can create more, and Team plans can share them, but sprawl still hurts you either way. Three well-kept Projects beat twelve half-empty ones every time.
Can project instructions replace a good prompt?
They cannot. Instructions set the defaults, but each chat still needs a concrete task, an audience, and an output shape of its own. Think of instructions as the employee handbook and the chat prompt as today’s ticket. A handbook without a ticket produces vague helpfulness. A ticket without a handbook produces an inconsistent voice.
Is Research always better than web search?
It is not. Research is better when you need synthesis across many sources plus a cited brief at the end. Web search is better for a quick factual check. Extended thinking or higher effort is better when the hard part is reasoning over text you already provided. Anthropic’s own chooser article frames it the same way: match the tool to the job, and remember that Research burns usage faster than the others.
Should every file go into knowledge?
No. Knowledge is for durable reference material. Meeting notes from Tuesday that will be irrelevant by Friday belong in a chat upload, or not in Claude at all. If you put transient noise into project knowledge, you teach the model the wrong background, and you will likely forget to clean it up later.
What if the retrieval behavior I read about does not match what I see?
Plan features and help articles move over time. The durable habits do not: keep knowledge lean, date your files, refuse invention in the instructions, and verify anything you ship. If a large upload fails or the quality drops, shrink the corpus and split the work into separate Projects by topic rather than building one giant shared file base.
Practice drill (this week)
- List five recent Claude, or other AI, tasks. Mark each one “bare chat would have been enough” or “a Project would have helped.”
- Create one Project with the starter kit: instructions plus three files.
- Run Chats A through C from above and note anywhere the model ignored a rule.
- If you are on a paid plan, run one Research question you actually need answered, then open two citations by hand.
- Delete or archive any file that is no longer the current source of truth.
Quick recap
- Bare chat for one-offs; Projects for recurring rules and docs.
- Instructions steer behavior; knowledge files supply source material; use both together.
- Chat uploads are temporary; project files are for reuse and need real hygiene.
- Research is a paid multi-source mode with citations, and it spends usage faster.
- Start one small Project, and grow the files only when repeated pain shows the gap.
- Citations and a human edit pass still close the loop at the end.
Series notes
This is Part 4 of Learn Claude from scratch. The next post moves into everyday jobs, writing, summarizing, studying, and planning, with prompt patterns that do not depend on a perfect Project. A later post covers memory, privacy, and what never to paste, and another covers workplace connectors and the cases where Claude is the wrong tool. Product flavors like Claude Code and Cowork get their own series once chat, Projects, and files feel normal to you.
Sources
Confirm plan availability and limits in Anthropic’s help center when the product interface changes.
- Anthropic Help Center, What are projects?: https://support.claude.com/en/articles/9517075-what-are-projects (workspaces, knowledge, instructions, Free cap of five projects, paid RAG scaling, Team sharing)
- Anthropic Help Center, How can I create and manage projects?: https://support.claude.com/en/articles/9519177-how-can-i-create-and-manage-projects
- Anthropic Help Center, Retrieval augmented generation (RAG) for projects: https://support.claude.com/en/articles/11473015-retrieval-augmented-generation-rag-for-projects
- Anthropic Help Center, Upload files to Claude: https://support.claude.com/en/articles/8241126-upload-files-to-claude
- Anthropic Help Center, Use research on Claude: https://support.claude.com/en/articles/11088861-use-research-on-claude (paid plans, citations, web search required, usage)
- Anthropic Help Center, When should I use web search, extended thinking, and research?: https://support.claude.com/en/articles/11095361-when-should-i-use-web-search-extended-thinking-and-research
- Anthropic Help Center, Get started with Claude: https://support.claude.com/en/articles/8114491-get-started-with-claude
- Analytics Made Simple, What are LLMs, ChatGPT, generative AI, and more: https://analyticsmadesimple.com/analytics/what-are-llms-chatgpt-generative-ai-and-more/
- Analytics Made Simple, Practical AI series: https://analyticsmadesimple.com/series/practical-ai/
- Analytics Made Simple, How to check AI-written SQL: https://analyticsmadesimple.com/tutorials/how-to-check-ai-written-sql/
- Analytics Made Simple, Learn: https://analyticsmadesimple.com/learn/
Keep going
Same lessons in your feed
Short diagrams, hooks, and weekly tutorials on Substack, Instagram, X, and Facebook.
