Claude Projects: How They Work, Their Limits, and What They Cannot Remember (2026)

TL;DR

Claude Projects are self-contained workspaces inside Claude with their own chat histories and knowledge bases. You upload documents, code, or text as project knowledge, set custom instructions, and every conversation in the project starts from that baseline. Projects are available on every plan, including free accounts, which can create up to five; paid plans add enhanced project knowledge with RAG, which expands capacity by up to 10x when uploads approach the context limit, and Team and Enterprise plans add sharing with view and edit permissions. What Projects do not do is remember for your organization: they hold what one person put in one container, and they do not reconcile what was decided across projects, tools, or teammates.

Frequently Asked Questions

What Projects Do Well

Projects solve the repetition problem for individual work. Instead of re-uploading the same brief and re-explaining the same constraints in every chat, you set the baseline once. Custom instructions shape tone and role, project knowledge carries the reference material, and chat history stays organized by workstream rather than scattered across a flat conversation list.

For a contained task with a fixed set of reference documents, this is genuinely useful, and the free tier makes it the default way most people should use Claude for recurring work.

Where the Ceiling Is

A project is a container, not a memory. Three limits follow from that design.

It holds documents, not resolved facts. Project knowledge is source material Claude reads at answer time. If two uploaded documents disagree, or a decision in week one was overturned in week six, the project has no mechanism to resolve which is current. The model re-derives an answer from the pile on every question.

It is scoped to one person's container. Team plans can share a project, but the organization's context does not live in any project. What sales promised a customer sits in a CRM and email. What engineering decided sits in Slack and a design doc. A project sees none of it unless someone manually uploads it, and manual uploads go stale the day after.

Retrieval mode inherits retrieval's weaknesses. The 10x RAG expansion on paid plans is the right call for capacity, but it means large projects answer from retrieved chunks, with the same guess-how-the-fragments-fit-together step that limits every retrieval system. For a deeper treatment of that tradeoff, see how context memory differs from retrieval.

Projects, Claude Memory, and Organizational Memory

Claude's own memory features and Projects both improve continuity for an individual user, and both stop at the same boundary: they are personal. The comparison that matters for a team is not Projects versus memory; it is per-user containers versus a shared, governed memory the whole organization and its agents draw from.

That second thing is what Sentra provides: a company brain that captures decisions, commitments, and facts across meetings, Slack, email, and docs, resolves them at write time with full source lineage, and serves the same correct context to every person and every AI tool, Claude included, through MCP. Claude Projects then do what they are best at, organizing an individual's active work, while the organization's ground truth lives in a layer built for it.

The Bottom Line

Use Projects for personal, contained work; they are free, fast to set up, and remove real friction. Just be precise about what they are not: an organizational memory. If your team keeps re-answering the same questions, restating decisions that were already made, or feeding agents context by hand, the fix is not more projects. It is a shared memory layer underneath all of them.