Home / Keeping the thread from day to day
The project, a container for context
A project groups files, instructions and sessions in a single place that persists from one time to the next, a task handled outside any project stays an isolated session that keeps nothing after it closes.
A project brings together three things in a single permanent place: reference files, an instruction written once, and the whole set of sessions opened inside it. An ordinary conversation, opened outside any project, keeps none of these three things beyond its own window: closing it amounts to emptying it.
What a project brings together
In the chat as in Cowork, a project attaches folders or files that Claude consults before answering, and a permanent instruction that avoids repeating the same rule for every task, the expected tone, the role held by Claude, a constraint to respect. A session opened within a project starts already configured: it knows the attached files and the written instruction, without them being reattached every time. Both follow the same principle, grouping what persists in the same place, but they are not shared the same way. As recorded on 2 September 2026, a chat project is shared, but only on the Team and Enterprise plans: it is either open to the whole organisation, or reserved for invited people, who then receive either a right to view or a right to edit. A Cowork project, by contrast, stays stored on the machine that created it and is not shared, even on these same plans. This is the opposite of what one assumes at first: the tool that acts the most is the one that is shared the least.
A permanent instruction fits in a few sentences, written once in the project settings:
Vous assistez le pôle comptabilité.
Répondez toujours en français.
Ne modifiez jamais un fichier sans le dupliquer d'abord.A session outside a project starts from zero
A one off task, a single question asked without attaching a project, does not need this permanence: it is dealt with, closed, and nothing of it remains for next time. The difficulty arises when this same task comes back every week and keeps being handled outside a project: every session then starts from zero, the same files are reattached and the same instructions retyped. The signal that should trigger a move to a project is simple: a task that comes back a second time, on the same subject, with the same files, belongs to a project rather than to an isolated session.
Creating a project named after its department
Name the project after the department or subject it covers, not after a single task, Accounting rather than March invoice. Then attach the useful files and the permanent instruction, and open inside it a first Cowork session on a reasonably sized folder to check that this session already sees what has just been attached.
The four steps of creating a project
A person creates a project named Compta on Monday, attaches a pricing grid file and a permanent instruction to it, then opens inside it a session to rephrase this file. On Tuesday, from the home page, she opens an ordinary conversation and asks it to pick up the pricing grid.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: It establishes that Tuesday's conversation was opened outside the project, and therefore without what attachment to the project brings to a session.
What this does not establish: It does not establish what Claude answers on Tuesday, nor whether the person can attach this conversation to the project afterwards.
The three most common miscalibrations
- Too broad This situation shows that any project created in Claude automatically becomes accessible from any conversation, including outside a project.
- Too narrow This situation shows nothing in particular, since a pricing grid remains a simple document to rephrase in any context.
- Beside the point It establishes that the pricing grid attached to the project held up to date rates at the time of the request.
- A project durably brings together files, an instruction written once and the sessions opened inside it, a session outside a project keeps nothing after it closes.
- A task that comes back a second time on the same subject, with the same files, belongs to a project rather than to a new isolated session each time.
- A Cowork project stays local to the computer that created it, a project opened in the chat is shared within an organisation, both group what persists on the same principle.
- Naming a project after the department or subject it covers, rather than after a single task, avoids recreating a new one at the next similar request.
Create a project named after your department, attach a reference file and a permanent instruction to it, then open inside it a first session on a reasonably sized folder, and check that it does indeed see what you have just attached.
These points depend on an interface or a rule that may have changed since this was written. Check them on your own screen before relying on them.
- The sharing of a project, exactly what it allows and to whom, depends on the plan your organisation has subscribed to. The addresses at the end of the lesson give the documented state, your administrator gives yours.
Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.
- Anthropic, managing the visibility and sharing of a project in the chat consultée le 2026-09-02
- Anthropic, organising your tasks with projects in Claude Cowork, local storage and no sharing consultée le 2026-09-02