Most bad results with AI don't come from the model: they come from asking it to do work without giving it context. A Project solves that. It's the container where you keep the documents that explain how the work is done well, plus the instructions that set the standard, so you don't have to repeat them in every conversation.
This guide is the complete manual: what it is and what it isn't, when to use one versus a one-off conversation, which documents go in, how to name them, how to write the instructions with a copyable template, how to version your knowledge, six structures by department, monthly hygiene, real limits and when to make the leap to the API or to agents. Everything cited comes from official documentation consulted in September 2026.
Short answer: A Claude Project is a workspace with its own history, a knowledge base of documents and a set of fixed instructions that apply to every conversation inside it. It's for work that repeats with the same standard and the same material. A one-off conversation is for one-off needs. The practical difference: in a Project you don't have to explain again who you are, what you sell and how you want things done.
- What is a Project in Claude, and what isn't it?
- When should you use a Project, and when is a one-off conversation enough?
- Which documents belong in the knowledge base, and which don't?
- How should documents be organized and named so they actually work?
- Project instructions: the complete template, ready to copy
- How do you write instructions Claude will actually follow?
- Version control for your knowledge: so nobody uses the old price list
- Six project structures by department, ready to copy
- Sharing, permissions and visibility: what changes on Team and Enterprise
- Hygiene: what should you review in the knowledge base every month?
- Real limits and common mistakes with Projects
- When does a Project fall short and it's time to move to skills, the API or agents?
- Tricks they don't put in the manual
- What to do this week with your knowledge base
What is a Project in Claude, and what isn't it?
A Project is a space with three pieces: its own conversation history, a knowledge base with the documents you upload, and project instructions that apply to everything that happens inside it. It isn't a file folder, it isn't a chatbot trained on your data and it isn't a database: it's persistent context that saves you from repeating the same thing twenty times.
The official Projects documentation defines it as a space with its own history and knowledge base. Three practical consequences worth understanding before you build anything:
- Documents persist across conversations. In a normal chat, whatever you upload only serves that conversation; in a Project, the material is available in all of the project's conversations.
- Project instructions are the memory of your standards. That's where you write who you are, who you're addressing, what tone you use, what should never be done and how you want the outputs. It's the difference between an intern who's been there six months and one who starts today.
- On paid plans it works with retrieval. When the knowledge base approaches the context limit, Anthropic documents the use of RAG for Projects, which expands capacity up to ten times. More fits than you'd think, but your whole Drive doesn't fit and quality drops with noise.
And now what it is not, because this is where the frustration comes from:
| What people expect | What actually happens |
|---|---|
| "I upload everything and now it knows everything about my company" | The more noise you upload, the worse it answers. You curate the base, you don't empty things into it |
| "It learns from my corrections and stays that way" | Whatever you don't write into the instructions or a document doesn't stick |
| "It checks my inventory in real time" | That needs a connector or an integration, not an uploaded document |
| "It's training the model on my data" | There's no training: it's context that gets retrieved when it answers |
| "It replaces the CRM or the document manager" | It's a working layer on top of them, not a replacement |
In the phased implementation guide, Projects are phase 1: the pilot's first knowledge base.
When should you use a Project, and when is a one-off conversation enough?
Use a Project when the task repeats, when the quality standard is stable and when reference material is needed. Use a one-off conversation for one-off, exploratory work you won't repeat. The quick rule: if you're about to explain the context for the third time, you should already have a Project.
Anthropic doesn't publish a comparison under that title, so the rule is built from what is documented: Projects have a persistent knowledge base and instructions, and normal chats don't retain documents. That's where this table comes from.
| Situation | One-off conversation | Project |
|---|---|---|
| Drafting a one-off email | Yes | Unnecessary |
| Understanding a document you'll never see again | Yes | No |
| Sales proposals with a template and catalog | No | Yes |
| Support replies with your own tone and policies | No | Yes |
| Monthly analysis with the same report format | No | Yes |
| Work several people do to the same standard | No | Yes, and shared |
| Confidential material that needs clear permissions | No | Yes, with controlled visibility |
There's a third case that causes confusion: memory and chat search, which pulls context from earlier conversations (official documentation). It's a personal convenience, not a company knowledge base: it isn't curated, it isn't shared deliberately and nobody maintains it.
The rule of three. The first time you do a task, a one-off conversation. The second time, save the prompt that worked. The third time, create the Project with that prompt turned into instructions and with the two or three documents you had to paste in. Almost every useful Project is born on that third attempt, not from planning ahead.
Which documents belong in the knowledge base, and which don't?
In goes whatever explains how the work is done well: approved templates, policies, current catalogs, real examples of good outputs, an internal glossary and real customer FAQs. Out stays whatever changes daily, whatever is pure bulk tabular data, anything duplicated, anything obsolete and anything you can't upload under internal policy.
The base is a curated library, not a hard drive. The admissions criterion is one question: does this help decide how to do the task? If the answer is "no, but just in case," it doesn't go in.
| Goes in | Why | Stays out | Why not |
|---|---|---|---|
| Approved proposal template | Sets the structure and tone of the output | Twenty old proposals with no labels | The model can't tell which one was good |
| Catalog with current prices and a date | Prevents invented prices | A price list from two years ago | It contradicts the current one and causes errors |
| Discount policy and terms | It's pure standard-setting | Entire internal email threads | Noise, contradictions and personal data |
| Two or three examples marked "good output" | Teaches the standard better than any description | A 40,000-row database | That's analytics, not context |
| Real customer FAQs | The market's actual language | A 300-page manual with no index | Better to extract the 10 pages that matter |
Three curation rules that save you months
- One document, one purpose. No "miscellaneous" file with the discount policy, the template and contact details all in one. When they contradict each other, you won't know where to fix it.
- Every document carries an effective date inside it. The first line of the file says when it's valid from and who maintains it. Without that, in six months nobody will know which one rules.
- Prefer the excerpt to the full file. Ten relevant pages are worth more than a three-hundred-page manual: the model retrieves better and you spot what's missing sooner.
On formats, the file upload documentation spells out what's supported. Practically: plain text or documents with selectable text. A scanned PDF with no text layer is an image, and an image of a catalog is a bad catalog.
Copyable template — mandatory header for every document.
DOCUMENT: [clear name of what this is]
AREA: [sales / finance / support / operations]
EFFECTIVE FROM: [date] · REVIEW ON: [date]
MAINTAINED BY: [role, not a person's name]
WHAT IT CONTAINS: [one sentence]
WHAT IT DOESN'T CONTAIN: [one sentence, to keep it from being misused]
REPLACES: [previous document, if applicable]
Want a hand applying this?
Free 30-minute working session. Uniamos is a remote AI automation agency (Austin and Mexico City) working over video calls and WhatsApp.
How should documents be organized and named so they actually work?
With a three-part naming convention — area, document type and effective date — and with an index document at the front of the base explaining what's there and what each thing is for. The order matters less than the clarity of the name: the file name is the first clue about when to use it.
The convention that holds up best over time is this one:
AREA_TYPE_TOPIC_YYYY-MM.extension
- SLS_TEMPLATE_standard-proposal_2026-09.docx
- SLS_POLICY_discounts-and-terms_2026-07.md
- SLS_CATALOG_public-price-list_2026-09.xlsx
- SUP_FAQ_customer-questions_2026-08.md
- ALL_GLOSSARY_internal-terms_2026-06.md
- SLS_EXAMPLE_good-proposal-industrial_2026-05.docx
This isn't bureaucracy: the name already says whether the document is a standard, data or an example; the date reveals what's expired without opening anything; and when you ask it to "use the current discount policy," it'll know which one that is.
The index document: the most important file of all
The first document in every base should be an index that explains the library. It's what keeps the model — and new people — from using the wrong file.
Copyable template — 00_INDEX_knowledge-base.md
What this project is for: [one sentence]
Who maintains it: [role] · Monthly review: [fixed day]
Documents and when to use each one:
· SLS_TEMPLATE_standard-proposal — mandatory structure for every proposal. Always use it.
· SLS_POLICY_discounts — discount limits and payment terms. Check it before offering terms.
· SLS_CATALOG_prices — current prices. It's the only source of prices; if it's not here, ask.
· SLS_EXAMPLE_good-proposal — example of an approved output. Match its level of detail, not its content.
What is NOT here: individual customer data, signed contracts, internal cost information.
If something is missing: ask [role] for it and don't make it up.
That last line looks decorative and isn't: it's part of the implicit instructions and it sharply reduces the odds of gaps getting filled in on its own.
Project instructions: the complete template, ready to copy
Project instructions are a short text that defines context, audience, quality standards, prohibitions and output format. Written well, they save you an explanation in every conversation. Written badly — vague or contradictory — they produce worse results than having none at all.
This template covers the seven blocks that matter. Copy it, fill it in and delete what doesn't apply. It should fit on one screen: if it takes three, nobody maintains it and it starts contradicting itself.
Copyable template — project instructions (7 blocks).
1. WHO I AM. I work at a [type of company] in [industry] in [Mexico / Paraguay], with [size] people. We sell [what] to [whom]. Our real differentiator is [one, specific].
2. WHO READS WHAT YOU PRODUCE. Usually [recipient profile: technical buyer, SMB owner, purchasing manager]. Their level of knowledge about us is [low/medium/high] and what they care about most is [price / lead time / support / compliance].
3. WHAT YOU DO HERE. In this project we work on [specific task: sales proposals / support replies / month-end close analysis]. Other tasks belong in another project.
4. WHAT A GOOD OUTPUT LOOKS LIKE. Length: [range]. Tone: [described in three words]. Structure: [fixed sections]. Always include [mandatory elements]. The quality standard is in the document SLS_EXAMPLE_good-proposal.
5. WHAT TO NEVER DO. Don't invent prices, lead times or references: if they're not in the knowledge base, say so and ask. Don't use [banned words]. Don't promise [commitments we can't keep]. Don't include customers' personal data in examples.
6. WHAT TO DO WHEN INFORMATION IS MISSING. Before drafting, tell me what you're missing and ask at most three questions. If a piece of data is still missing, leave it marked as [PENDING: what's missing] instead of filling it in.
7. DELIVERY FORMAT. Return it as [text ready to paste / a table / a document]. At the end, add a line with the internal sources you used and with whatever you couldn't verify.
Block 6 is the one that changes results the most and the one almost nobody writes. Forcing it to ask before drafting turns the model into someone who requests the brief instead of inventing it, and it wipes out much of the fabricated data in one stroke.
How do you write instructions Claude will actually follow?
With four techniques documented by Anthropic: explain the reason behind each rule, give three to five varied examples, separate the parts with tags, and put long material before the question. The quality test is official too: show your instructions to a colleague with little context; if they get confused, the model will too.
The official prompting best practices recommend thinking of the model as "a brilliant but new employee who doesn't know your norms or your workflows." That translates into four moves.
- Explain the reason, not just the rule. The example in the documentation itself is clear: instead of "never use ellipses," write "this will be read by a voice engine that can't pronounce ellipses, so don't use them." A sales version: instead of "don't mention lead times," write "don't mention lead times because production confirms them case by case and a wrong lead time costs us the order."
- Give three to five examples. The official guide recommends that number, with varied examples that cover edge cases: one alone produces literal imitation, five produce judgment. In a Project they live as documents marked "good output" and get cited from the instructions.
- Separate the parts with tags. Wrapping context, instructions and data in tags like <context>, <instructions> and <data> keeps it from confusing an example with an order. It works the same inside project instructions as in each conversation.
- Long material at the top, question at the end. For long contexts, the documentation says that putting queries at the end can improve answer quality by up to 30% in their tests. If you paste a 60-page tender document, the instruction goes after it.
The five bad habits that ruin a set of instructions
- Adjectives with no standard behind them. "Professional," "approachable" and "powerful" mean nothing. Replace them with verifiable rules: "sentences under 25 words," "no superlatives," "address the reader directly."
- Accumulated contradictions. Adding rules over months leaves you with "be brief" and "develop each point." Review the whole text, not just the new paragraph.
- Instructions that repeat the document. If the policy is already in the base, point to the document instead of copying it: two copies guarantee two versions.
- Prohibitions with no alternative. "Don't invent data" works much better as "if it's not in the base, write [PENDING] and tell me what's missing."
- One project for everything. Instructions that cover sales, support and finance end up generic: better to have three sharp projects.
The equivalent applied to day-to-day sales work is in Claude prompts for sales teams.
Version control for your knowledge: so nobody uses the old price list
You control it with three simple mechanisms: an effective date inside every document, a single current document per topic — the previous one gets deleted from the base, not left there "just in case" — and a change log in the index where you record what changed, when and who requested it.
The most expensive failure isn't missing information: it's leftover expired information. If July's price list and September's coexist, the answer will be plausible and wrong, and nobody will notice until the customer complains.
| Mechanism | How it's done | What it prevents |
|---|---|---|
| Date inside the document | First line: effective from, review on, who maintains it | Using a repealed standard |
| One current version per topic | When the new version goes up, the previous one is removed from the base | Silent contradictions |
| Change log in the index | Three columns: date, what changed, who requested it | Arguments about "who changed this" |
| Historical archive outside the project | A folder in your document manager, not in the base | Losing history without cluttering the context |
Copyable template — project change log.
| Date | Document | What changed | Who requested it (role) | Previous version archived in |
| 2026-09-15 | SLS_CATALOG_prices | 4% increase on the industrial line | Sales management | Drive/archive/2026 |
| 2026-09-02 | SLS_POLICY_discounts | New 12% cap without authorization | General management | Drive/archive/2026 |
Rule: nothing new enters the base without a line in this log.
A warning for Enterprise: audit logs capture events for creating, deleting and changing the visibility of projects, but not the content. Traceability for your knowledge comes from your change log, not from the platform.
Six project structures by department, ready to copy
One project per department and per task, not one per company. These six structures — sales, marketing, support, finance, operations and HR — cover 90% of what a small or mid-sized business needs, and you can set them up in one afternoon with documents you already have.
1. Sales: proposals and follow-up
Knowledge base: approved proposal template, catalog with current prices, discount and payment terms policy, two examples of a good proposal, buyer FAQs, spec sheet. Instructions: the typical buyer profile, tone, a ban on inventing prices and lead times, format ready to send. Permissions: view access for the whole sales team.
2. Marketing: content and campaigns
Knowledge base: the brand manual or, if there isn't one, a tone document with ten right sentences and ten wrong ones; positioning; product glossary; three published pieces marked as the standard. Instructions: audiences, banned words, lengths by format and a requirement to propose three headlines before drafting.
3. Customer service and support
Knowledge base: catalog of approved replies, warranty and return policies, escalation rules (what gets resolved and what goes to a person), real FAQs in the customer's own language. Instructions: tone, maximum length, a rule against committing to lead times and a requirement to flag cases that must be escalated. As volume grows, this project is the natural precursor to an agent: see chatbots and AI agents.
4. Finance and administration
Knowledge base: chart of accounts and cost centers, expense policy, calendar of obligations, monthly report format, definition of each indicator. Instructions: what gets analyzed and what doesn't get decided here, plus a requirement to cite the source figure and flag assumptions. See finance.
5. Operations and logistics
Knowledge base: current procedures, standard times, delivery terms by region, quality checklist and typical incidents with their resolution. Instructions: safety takes priority over speed, and a requirement to point out when a figure depends on a live system.
6. Human resources
Knowledge base: job descriptions, onboarding handbook, internal AI usage policy, staff FAQs. Instructions: institutional tone, an absolute ban on including employees' personal data and a notice that no employment decision gets made here. The policy that should live there is in AI usage policy and governance.
| Project | Minimum documents | Sign it's set up well |
|---|---|---|
| Sales | 6 | A proposal comes out in 15 minutes and passes review on the first try |
| Marketing | 5 | Two different people produce the same tone |
| Support | 4 | Replies don't promise anything outside policy |
| Finance and operations | 5 | Nobody asks the project for data that only exists in the ERP |
| HR | 5 | Zero personal data in the conversations |
The catalog of what to ask each project for, task by task, is in use cases by department at SMBs.
Sharing, permissions and visibility: what changes on Team and Enterprise
On individual plans, projects are personal. On Team and Enterprise they can be shared with specific people, in view or edit mode, with a group or with the whole organization. That choice is a governance decision, not a convenience one: it defines who can change the working standard for an entire department.
The visibility and sharing documentation describes the available modes. Translated into internal policy, it looks like this:
| Mode | When to use it | Risk if you get it wrong |
|---|---|---|
| Personal | Individual drafts and experiments | The knowledge dies with the person |
| Shared, view only | Department projects with a stable standard | Nothing meaningful; it's the recommended default |
| Shared, with editing | Two or three people who maintain the base | Someone uploads an obsolete document and nobody notices |
| Whole organization | Glossary, brand manual, usage policy | Exposing material not everyone should see |
Three rules that avoid the most common messes:
- Editing for two, reading for everyone. A project with fifteen editors ends up with two different templates and three discount policies.
- The owner is a role, not a person. Write "maintained by: head of sales" in the index. When that person changes roles, the project isn't orphaned.
- Retention gets decided at the top. On Enterprise you can set your own retention periods for chats and projects, with a 30-day minimum, versus the default behavior of keeping data indefinitely: custom retention controls. Deciding that before you build ten projects is cheaper than afterward.
Team and Enterprise also include enterprise search for unified knowledge. It doesn't replace projects: it answers "where was that document?", not "how is this task done well?".
Hygiene: what should you review in the knowledge base every month?
Half an hour a month, on a fixed day, with five checks: expired documents, prices and policies that changed, documents nobody used, questions the project couldn't answer, and contradictory instructions. An unmaintained base degrades in about three months and starts giving answers that are plausible and wrong.
- Expiration. Open the index and check the "review on" column. Anything past due gets updated or pulled out of the base that same day.
- This month's changes. Did any price, lead time, term or owner change? If it changed in reality and not in the base, the base is lying.
- Dead documents. If a document hasn't been used or cited in three months, either it's surplus or nobody knows it exists. Both causes get fixed in the index.
- Gaps spotted. Collect the three questions the project couldn't answer for lack of material. That list is your internal content plan.
- Instructions. Read them all the way through out loud. If anything contradicts itself or no longer applies, fix it right then, not "when there's time."
Copyable template — monthly hygiene record (10 lines).
Project: ___ · Date: ___ · Owner (role): ___
1. Expired documents found: ___ · Updated: ___ · Removed: ___
2. Business changes not reflected: ___
3. Documents unused for 3 months: ___
4. Unanswered questions spotted this month: ___
5. Contradictions in the instructions: ___
6. New additions to the base: ___
7. People with edit permission: ___ (are they still the right ones?)
8. Issues reported by the team: ___
9. Next review: ___
A cheap sign that hygiene is failing: the team starts pasting documents in by hand instead of trusting the base. When you see that, review the base: they're right.
Want a hand applying this?
Free 30-minute working session. Uniamos is a remote AI automation agency (Austin and Mexico City) working over video calls and WhatsApp.
Real limits and common mistakes with Projects
The limits that matter: the free plan caps you at five projects; the knowledge base isn't infinite, though on paid plans retrieval expands capacity up to ten times; and nothing inside it updates on its own. The common mistakes are about curation, not technology.
The five-project limit on the free plan appears on the pricing page — as of September 2026; confirm on their site. On paid plans, retrieval expands capacity up to ten times as you approach the context limit. That doesn't mean "upload whatever you want": the bottleneck stops being size and becomes quality.
| Common mistake | How it shows up | Fix |
|---|---|---|
| Uploading entire folders | Generic or contradictory answers | Curate down to ten or fifteen documents with a clear purpose |
| Keeping old versions "just in case" | Prices or policies mixed together | One current version per topic; the rest, out |
| Three-page instructions | It ignores part of the rules | One screen, verifiable rules |
| One project for the whole company | Nothing gets done especially well | One project per department and task |
| Expecting live data | "It doesn't know my inventory" | A connector or integration, not a document |
| Nobody maintains it | Silent degradation within three months | An owner by role and a monthly review |
| Personal data with no criteria | Compliance risk | Classify up front what may go in |
On compliance, with no intent to give legal advice: in Mexico, the Ley Federal de Protección de Datos Personales en Posesión de los Particulares (Federal Law on the Protection of Personal Data Held by Private Parties) has been in force since March 2025, with authority resting in the Secretaría Anticorrupción y Buen Gobierno (Ministry of Anti-Corruption and Good Governance); in Paraguay, Ley 7593/2025 (Personal Data Protection Law), with a 24-month compliance window. A knowledge base with personal data inside is a processing activity like any other: legal basis, declared purpose and access control. Details in the implementation guide.
When does a Project fall short and it's time to move to skills, the API or agents?
When the same task repeats hundreds of times a month, when you need to query live systems, or when the process has to run without a person starting it. As long as volume is moderate and the standard changes often, the Project remains the cheapest and easiest-to-maintain option.
There are three steps above the Project, and it's best to climb them in order.
Step 1: skills
Skills are "folders of instructions, scripts and resources" that Claude loads when they're needed. They're written in Markdown, they're available on every plan and they require code execution to be enabled; on Team and Enterprise, owners can provision them across the whole organization, and Enterprise adds scanning against malicious content. Typical case: a fixed-step procedure that's currently copied into five projects. Guide: how to create custom skills.
Step 2: connectors
If what's missing is live data — inventory, order status, customer record — uploading documents won't fix it; you need a connector to your storage, email or CRM, or your own connector via remote MCP against your systems.
Step 3: API and agents
With high volume, structured input and a stable standard, it's worth moving to API integration or an agent. That changes the cost, the testing required and the profile of whoever maintains it: see integrations and APIs and process automation.
| Monthly volume | Standard | Solution |
|---|---|---|
| Fewer than 20 repetitions | Shifting | One-off conversation with a good prompt |
| 20 to 200 | Stable | Shared Project |
| More than 200, fixed steps | Very stable | A skill on top of the Project |
| Any volume, with live data | — | Connector or MCP |
| Hundreds or thousands, structured input | Stable and measurable | API or agent |
For technical teams: in Claude Code, the CLAUDE.md file at the root of the repository plays the role of project instructions and is read at the start of every session, according to the Claude Code memory documentation. Same idea, different packaging.
Tricks they don't put in the manual
The shortcuts that separate a decorative Project from one the team uses every day.
- Name the project after the task, not the department. "Industrial sales proposals" works; "Sales" ends up as a catch-all drawer.
- Start with the good example, not the rules. Upload two approved outputs first and note in the index that they're the standard. One real example teaches more than two paragraphs of instructions.
- Write the instructions in the first person plural: "we sell…", "our customers usually…". The text reads more naturally and so does the output.
- Add a "how we talk" document. Ten right sentences and ten wrong ones, in columns. It solves the tone problem better than any adjective.
- Always ask for the plan before the deliverable. "Before drafting, give me your approach in five lines and tell me what you're missing." Thirty seconds that save you from throwing out three pages.
- Require it to cite where each fact came from. Add to the instructions: "at the end, list which documents from the base you used and which claims you couldn't verify." It turns review into a glance.
- Keep the conversations that went well inside the project. They're the best training material for anyone new who joins.
- Keep a "questions we couldn't answer" document, fed each month during hygiene: it's your improvement plan for the base.
- Put the expiration date on the first line, not in the footer. What sits at the top carries more weight, and people read it when they open the file.
- Duplicate the project before overhauling it. To change instructions deeply, copy it and test for a week. Changing the project the whole team uses on the fly is the fastest way to lose their trust.
- Review who has edit permission every quarter and ban the "test" project: everyone ends up working in it and nobody maintains it.
Copyable template — first message when entering a new Project.
You're going to help me with [task]. Before you start working:
1. Read the document 00_INDEX and tell me in three lines what material you have available.
2. Tell me which documents you'd be missing to do this task well.
3. Ask me at most three questions about this specific case.
Don't start drafting until I answer.
What to do this week with your knowledge base
Create one single project, for the task your team repeats most. Gather five to eight documents, write the index and the instructions using the templates in this article, test it yourself three times, adjust it and only then share it. One project that works convinces people more than ten half-built ones.
- Pick the task that repeats most during the week, one someone can verify in five minutes.
- Gather five to eight documents that explain how it's done well. If you have more than fifteen, some are surplus.
- Give each one the header with effective date and owner, and rename them using the area, type, topic and date convention.
- Write the index with the template: what's there, when to use each thing and what isn't there.
- Write the instructions with the seven blocks, on a single screen.
- Test it yourself three times with real cases from this week and fix whatever fails. Don't share before this.
- Share it in view-only mode with the team and put the monthly review day on the calendar.
With two or three projects up and running, the next step is training the team — eight-week training program — and measuring whether working times change, using the method in measuring adoption and return.
Frequently asked questions
How many documents should a knowledge base have?
Between five and fifteen for a project covering a specific task. Fewer than five usually means the standard still lives in someone's head; more than twenty means you're uploading material just in case. The real limit isn't size: it's contradiction. Two documents saying different things do more damage than ten that are missing.
Can I upload my whole Drive folder to the project?
You can, but it'll make the results worse: every irrelevant document competes with the relevant ones. If you need to search across all your storage, that's solved with a connector or with the enterprise search in Team and Enterprise, not by putting your entire Drive into a project.
How many projects can I create?
The free plan has a maximum of five, according to Anthropic's pricing page as of September 2026; confirm on their site. Paid plans don't publish that limit. In practice, maintenance sets it: every project needs an owner and half an hour a month, so ten with no owner are worth less than three well cared for.
Do project instructions replace the prompt in each conversation?
No: they shorten it. The instructions fix what doesn't change — who you are, who you're addressing, what tone, what to never do — and the prompt supplies what's specific to the case. If you repeat the same sentence in every conversation, that sentence belongs in the instructions; if something changes case by case, it doesn't belong there.
Can the team edit the knowledge base?
They can, but it's better if they don't: editing for two or three owners and reading for everyone else. A base with fifteen editors ends up with two templates and three discount policies coexisting, and the mistake gets caught once a wrong proposal has already gone out.
What about the personal data in the documents?
The same obligations apply as to any other processing: legal basis, declared purpose, access control and retention periods. The practical move is to anonymize before uploading, classify into three levels and leave anything sensitive out. General guidance, not legal advice: check it with your compliance lead.
How often should the knowledge base be reviewed?
Once a month, on a fixed day, for half an hour. The risk isn't missing information, it's leftover expired information: an old price list coexisting with the new one produces answers that are plausible and wrong. If you change prices more often, the review follows the pace of the change.
Can a Project handle customer service automatically?
On its own, no. A Project is internal work: someone opens a conversation and asks for something. Replying to customers without human intervention requires an integrated channel, escalation rules and testing. The usual approach is to use the project to generate drafts a person approves and, when volume justifies it, move to an agent.
What's the difference between a Project and a skill?
The Project provides persistent context and judgment for a type of work. A skill, according to Anthropic's documentation, is a folder of instructions, scripts and resources that Claude loads when needed, and it packages a reusable fixed-step procedure. The normal path is to start with the Project and extract the skill once that procedure repeats across several projects.
Is the knowledge lost if the person who built the project leaves?
Only if the project was personal and the owner was defined by name. Share it from the start on Team or Enterprise, write the owner in the index as a role and keep the change log. With that, a departure is a change of owner and not a loss of knowledge.