How to Organise Claude Projects for Ongoing Work

Give each client or long-running workstream one Claude Project, not each task. Name them to a fixed pattern so the list sorts itself, star the few you are in this week, and archive the rest when the work stops. Put what is true and stable in knowledge, the rules for that work in instructions, and keep what is happening — open items, owners, status — outside the chats, on a board, because no project can see another and chats inside one do not share context. Running a single project well is a different question, covered in Claude Projects best practices; this piece is about the set.

Why the set needs a structure

Projects are walled off from each other by design. Anthropic’s article on chat search and memory↗ (opens in a new tab) says each project has its own memory space and project summary, separate from other projects and from chats outside projects, and that searching past chats inside a project is limited to that project. That is good for focus and bad for anything that spans projects. A decision made in the “Acme website” project is invisible to the “Acme retainer” project unless you carry it over. So the boundaries you draw decide what Claude can connect, and they are worth drawing on purpose.

One project per client or workstream, not per task

Draw a project around a body of material that many chats will need, and that will be needed for weeks. That usually means one of three shapes:

• Per client. Everything for one customer: their brief, contract terms, style guide, contacts and decisions. Keeps one client’s documents out of another’s answers, which matters when both are in the knowledge you would otherwise share.
• Per workstream. A product area, a recurring report, a research line. Right when the material is yours rather than a client’s, and the work never really ends.
• Per engagement, inside a big client. Only when two pieces of work for the same client have different rules or documents, such as a fixed-price build and an ongoing support contract.

A single task is almost never a project. It is a chat, inside the project it belongs to. A project per task leaves you with dozens of containers holding one chat each, none with enough knowledge to be worth the set-up, and a list nobody can scan. Free accounts are capped at five projects, which forces the choice early; the help centre gives no such cap for paid plans, which is how lists sprawl.

A naming scheme that sorts itself

Anthropic’s guide to creating and managing projects↗ (opens in a new tab) notes that Claude does not have access to a project’s name and description. They are for you and your colleagues, so optimise them for scanning and search, not for the model. A fixed pattern does that:

Client · Acme · Website rebuild
Client · Acme · Support retainer
Client · Borough Council · Tender 2026
Internal · Weekly report
Internal · Hiring
Research · EU AI Act obligations

• Type first, so clients, internal work and research group together.
• The name people say out loud, not a code. “Acme”, not “ACM-003”.
• A year only when the work is bounded by one, such as a tender or an annual review.
• Use the description for the one-line purpose and the owner. Claude will not read it, but the colleague deciding whether to open the project will.

Then use the list tools the help centre describes. Star the projects you are in this week so they sit in the sidebar. On Team and Enterprise, the Projects page has three tabs, Your projects, Organization and Shared with you; if a colleague cannot find a project, it is usually on another tab.

What goes in knowledge, what goes in instructions

Across many projects the split matters more, because you will be copying pieces from one to another. A rule that keeps them consistent:

• Knowledge holds facts about this body of work: the brief, the spec, reference data, a decisions file. It differs from project to project.
• Instructions hold rules for working on it: audience, tone, which document wins in a conflict, what to do when unsure. Much of this repeats across projects.
• Material that belongs to every project, such as your house style guide, has one master copy kept outside Claude. Each project gets a dated copy, and when the master changes you update the copies in one sitting, not whenever someone notices.
• Nothing that changes daily. A status update uploaded as a file is wrong by the next morning, and Claude will quote it with confidence.

Anthropic’s page on RAG for projects↗ (opens in a new tab) adds a reason to be tidy: in large projects Claude searches the knowledge rather than loading all of it, and the help centre’s advice is clear, descriptive filenames and related material grouped in the same project. A consistent file naming pattern across projects, such as spec-current.md and decisions.md in every one, also means your instructions can point at the same file names everywhere.

Keep stray chats where they belong

Chats drift. You start a question in the wrong project, or outside any, and the answer ends up where the next person will not look. The help centre describes a dropdown next to the chat name that adds a chat to a project, moves it to another, or removes it. Where memory is on, that also decides which project’s memory the chat feeds, so a stray chat about another client is worth moving the same day, before it colours that project’s summary.

Archive on a schedule, delete rarely

When work stops, archive the project. The help centre says archived projects move to the bottom of the list, keep their knowledge, members and permissions, and their conversations stay reachable; unarchiving restores everything as it was. Two consequences for a tidy set:

• Archiving is not offboarding. Members keep their access, so remove anyone who should no longer see a client’s material from the sharing settings first.
• Deletion is deliberate. An archived project cannot be deleted until you unarchive it, which is a useful pause before removing a client’s history for good.

A monthly pass is enough: archive projects nobody opened in a month, retire knowledge files that have been replaced, and check that every active project still has an owner. Who should hold edit rights on a shared one is covered in Claude Projects for teams, and what sharing hands over in can Claude Projects be shared?

Expect the containers to change

Projects are not standing still. Anthropic’s overview of what projects are↗ (opens in a new tab) describes a new version in beta, starting in Claude Code, in which a project is one conversation that Claude splits into parallel threads, with existing projects to be upgraded as the rollout reaches chat.

Separately, the help centre’s page on projects in Claude Cowork↗ (opens in a new tab) lets you create a Cowork project by importing the files and instructions of an existing Claude project. A structure that lives in clear names, a master copy of shared material and a status list outside the chats survives those changes; one that lives in chat history does not.

Keep status outside the chats

The hardest thing to see across twenty projects is what is actually open. Each project knows its own documents; none knows what is in progress, who has it, or what was finished yesterday. That view needs one list across all of them. On fenbs, a board holds tasks in To Do, Next Up, In Progress and Completed, and each task carries a project, so you can mirror your Claude project names on the board and filter to one client or see everything at once. Claude connects over MCP with the Claude connector, and from inside any project chat can read the tasks for that project, file what the chat turned up, and comment on progress, with every change recorded under who made it. Standing rules can be kept per project as AI context, which Claude reads with fenbs_get_context before it starts.