Context, Projects & Memory

A Project is a workspace that bundles two things and reuses them across every chat you open inside it. The first is project knowledge: files and text you add once - a client brief, your practice's standard specification clauses, a materials palette, a byelaw chapter, past reports whose voice you want matched. Claude can draw on all of it in any conversation in that Project, so you stop pasting the same brief into every new chat. The second is custom instructions: standing directions in your own words about how Claude should behave in this Project - "You are assisting Studio X, a residential practice in Bengaluru. Write in plain British English, metric units, no marketing language. Never invent code references or prices; flag anything uncertain with [VERIFY]." Those instructions apply to every chat automatically, so the negative constraints you learned in 1.1 become permanent instead of retyped.

Think of it as the difference between briefing a temp who arrives each morning with no memory, and an assistant who has read the project file and knows the house style. Everything you would otherwise repeat - who the client is, what stage you are at, how the studio writes, what must never be fabricated - lives in the Project once. A new chat inside it starts warm.

The organising instinct is one Project per meaningful context. A client or job Project holds that project's brief, drawings notes, correspondence style and decisions - open a chat to draft an email, compare two finishes, or summarise a meeting, and Claude already has the background. A practice Project holds studio-wide assets: your spec library, proposal templates, tone-of-voice, standard drawing notes - the material that is the same across all jobs (this is the studio knowledge base of Module 9.1). Keeping them separate stops one client's context bleeding into another's and keeps each Project's knowledge sharp and relevant.

The payoff compounds over a job. In week one a Project saves you a little pasting; by month three it is the difference between a chat that already knows the client changed the kitchen to gas and a blank assistant you have to re-educate. Everything the team has decided, written and settled sits in one place Claude can draw on, so the newest junior opening a chat in the Project gets the same briefed start as the principal. That consistency - every conversation beginning from the same shared understanding - is quietly one of the biggest wins, and it is why Module 9 treats Projects as the foundation of a whole studio system rather than a personal convenience.

A Project is only as good as what you put in it, and more is not always better. Load the things that are stable and reused: the brief, the palette, standard clauses, templates, tone samples, reference standards you rely on repeatedly. Do not dump your entire server into it - a Project stuffed with irrelevant files makes it harder for Claude to find the parts that matter, and you will spend longer telling it what to ignore than you saved. Curate it like a good reading list, not a hoard.

A useful test for each item: will I reuse this across many chats? If yes - the client brief, the spec template, the voice sample - it belongs in the Project. If it is a one-off - a single email thread you want summarised today, one PDF you need read once - just paste or attach it into a single chat instead; there is no need to pollute the permanent knowledge with throwaway material. The figure lays this out as two lanes: load the durable, paste the disposable.

And because a Project's knowledge persists, it is exactly where the confidentiality discipline from the whole course bites hardest. On consumer plans, be careful what you make permanent: anonymise client names where you can, keep personal data and anything under NDA out unless your plan's data settings and the client's agreement allow it, and remember that a business (Team or Enterprise) plan - which by default does not use your work to train models - is the right home for genuinely sensitive project data. A Project is a filing cabinet with the assistant's name on it; stock it deliberately, and only with what you are comfortable living there. Module 10.1 goes deep on this; for now, the rule is simple - if you would not email it to a stranger, check your settings before you load it.

One subtlety worth naming: a Project's knowledge is only as true as the day you loaded it. Files do not update themselves. If the client cuts the budget, swaps a finish, or moves a wall, the old brief still sits in the Project stating the opposite, and Claude will work confidently from the stale version because it has no way of knowing the world moved on. Treat the knowledge like a live document under your control - when a decision changes, change the file. A quick discipline of updating the Project at each design milestone keeps every future chat working from reality rather than from a snapshot you have quietly outgrown.

Three different things get muddled, so it is worth separating them. Paste-every-time is the baseline: a plain chat where you supply all context in the prompt. It is perfect for one-offs and needs no paid plan, but it remembers nothing once the chat ends. Projects give deliberate, scoped, persistent context: you choose exactly what goes in, it is visible and editable, and it applies to every chat in that Project and nowhere else. That control - you decide what Claude knows, and you can see and prune it - is precisely why Projects suit professional work.

Separately, Claude has been growing a memory capability - the ability to carry some things it learns about you across conversations without you re-stating them. This is convenient, but for practice work treat it as a helpful extra, not the backbone: it is less explicit and less controllable than a Project, its exact behaviour depends on your plan and settings and changes over time, and you generally want your professional context to be something you curate on purpose rather than something the tool infers. As of 2026 the honest guidance is: rely on Projects for the context that matters, keep an eye on your memory and data settings, and do not assume Claude has silently retained something important - if it matters, put it in the Project where you can see it.

Do not confuse any of this with the context window - the amount Claude can hold in a single conversation at once (on the order of hundreds of pages as of 2026). That is working memory for one chat, not lasting storage; when a chat gets very long, earlier details can effectively drop out of focus. Projects and the context window work together: the Project supplies the durable background, and each chat's window holds the live back-and-forth. Knowing which is which stops the common frustration of expecting a brand-new chat to "remember" something you only ever said in a different one.

Here is a setup that takes fifteen minutes and pays for itself in a week. Create a Project named for the job - "Villa Anand - Alibaug" - and give it custom instructions that encode who it serves and the rules that never change:

You are assisting on Villa Anand, a 4-bedroom weekend house in Alibaug
for a Mumbai-based family. Stage: design development.

House style: plain, warm, concrete language. British spelling. Metric.
No marketing words (elevate, curate, bespoke, journey).

Never invent code clauses, product names, dimensions or prices. If a
figure or standard is needed and you are unsure, write [VERIFY: ...]
so the team can confirm it. When you make an assumption, say so.

Then add project knowledge: the signed brief, your standard spec-clause library, a materials-and-finishes list, and one past report written in the voice you want matched. Now every chat inside starts briefed. To draft a client update you type "summarise the attached site-meeting notes into a client update in our voice" and Claude already knows the project, the tone and the rules - no re-briefing.

A few habits keep it healthy. Keep the knowledge current - when a decision changes, update the file, or Claude will confidently work from the stale version. Start a fresh chat per task rather than one endless thread, so each conversation stays focused while all of them share the Project's context. Review what is in there before sharing a Project with a colleague, since they inherit everything you loaded. And respect the honest limits: Projects are a paid-plan feature, upload sizes and counts vary by plan and change over time, and a very large knowledge base can dilute focus. None of this is a reason to avoid Projects - it is how you run them well. Done right, a client Project is the closest thing to an assistant who has actually read your file.