What Projects Are For (And Not For)

"So where does my personal context actually live?"

In the last article, I walked through four layers of context — preferences, memory, voice profile, context documents — that teach Claude who you are. The article before that, The Session Protocol, was about how to run a single session well: orient, do bounded work, close the loop.

Both pieces left the same question hanging.

Where does this stuff actually live?

You've spent an afternoon writing a voice profile. You've drafted a context document about your work. You've started closing your sessions properly and you're producing real artefacts — strategy documents, decisions, drafts you don't want to lose. None of it does you any good if it sits in twelve different chat threads you'll never open again.

You need a container. Claude has one. It's called Projects.

This article is about what projects are good at, what they're not, and the discipline of using them well. Because here's the thing nobody tells you when you're getting started: projects are great. They're also where most people's Claude practice quietly starts to break.

The grounding question

Before we get into how projects work, I want to put a question on the table that should reframe how you think about all of this.

If Claude retained nothing between sessions, what would you change about how you work?

It's a thought experiment, but not a very far-fetched one. Claude does retain some things between sessions — memory accumulates facts, projects carry instructions, your account knows your preferences. But it retains less than you think, and what it does retain isn't fully under your control. Memory drifts. The model picks up things you mentioned in passing and forgets things you wanted it to keep. Project instructions sit there until you update them. None of it is the equivalent of someone who actually remembers your last conversation.

Worth being honest about what Claude is good at, though. When you ask it directly — "what do you know about my role?" or "summarise where we landed on the pricing question last week" — it's pretty good. Recall on request, working with what's in front of it. What it's not good at is orienting itself at the start of a session, automatically, from incomplete context. Give it the picture, and it works with the picture. Expect it to construct the picture itself, and you'll be disappointed.

So the question still stands. If you assume Claude has near-zero persistent memory of your situation — and you assume that every session is a cold start — what changes?

The answer is that you stop expecting Claude to know things and start curating what you give it. You stop hoping memory caught the important bit and start putting the important bit somewhere you control. You stop treating context as something Claude has and start treating it as something you give.

That's the discipline this article is about.

What projects actually are

The mechanics first, briefly. A project in Claude is a container with two layers: custom instructions (what you write into the project's instructions field) and project files (documents you attach for reference). Every conversation you start inside the project inherits both automatically.

This solves an obvious problem: without projects, every piece of context you've ever given Claude lives in the same pool. The workout plan you designed last Tuesday and the strategic positioning document you refined on Wednesday. Claude's memory tries to correlate them, and the result is sometimes useful but mostly noise. Projects let you isolate context. Different worlds, different containers.

I currently run separate projects for content creation, business strategy, and health and wellbeing. Each one has its own instructions, its own reference files, its own focus. Inside each project, conversations build on each other. Across projects, they don't.

The instructions and the files do different jobs. Instructions tell Claude how to operate in this domain. Files give Claude material to reason over. We'll get to what each layer should actually contain — but the distinction matters from the start, because most people mix them up.

That's the first-order benefit of projects. The harder question is what actually goes inside each layer — and that's where most people lose the plot.

What good project instructions actually contain

Here's something I didn't expect when I started building these out: the most useful parts of my project instructions aren't the background information.

They're the decision rules.

My health project has a rule: when time is tight, my physiotherapist's rehab block takes priority and my trainer's programme gets trimmed — not the other way around. That rule exists because early on, Claude stacked both programmes at full length and the session ran over an hour. I corrected it, and the correction became a standing instruction.

My business project has pre-loaded record IDs for my CRM and knowledge base, so Claude can query a client's deal status without any setup conversation. That came from too many sessions that wasted the first five minutes searching for the right records.

The pattern is the same in every case: real-world friction produces a specific rule that gets encoded into the project. The instructions aren't a static brief you write once and forget. They're accumulated decisions from sessions that didn't go perfectly.

That's what makes them useful.

There's a deeper version of this worth naming. The most useful project instructions aren't information about your world — they're a routing table for how to operate in it. They tell Claude where to find things, which system to query for which question, which record IDs to use, which rules apply when. The first decays. The second compounds. This is the same orient step the Session Protocol article talked about, just pre-computed and made automatic. Instead of orienting Claude at the top of every session, the project orients Claude for you the moment a new conversation starts.

What good project files actually look like

If instructions are the routing table, files are the reference shelf the routing points to. Most people fill that shelf with whatever feels relevant — old transcripts, half-finished drafts, PDFs from a meeting last month, a deck someone sent over. Claude tries to make sense of all of it, and the project gets noisier with every upload.

The shape that's worked best for me is a triplet: three small files, each doing a distinct job, and nothing else.

I run this triplet on a current client engagement, and the difference between projects with a clean version of this and projects with twenty miscellaneous files is night and day — every conversation starts from the same baseline because every conversation reads the same three files.

It's worth naming the curation rule explicitly. Most projects don't need more than a handful of files. If you have more than five or six, ask yourself which ones are doing real work and which ones are just there. The answer is usually that two or three are load-bearing and the rest is noise. Cut the noise. The project gets sharper, every session gets faster, and the load-bearing files actually get read.

Some of these files mirror something that lives in your knowledge layer — a Notion page, a Google Doc, a wiki entry that you treat as the canonical version. When that's true, date-stamp the file. "Last synced: 6 April 2026" at the top. It's a small move that reminds you the file is a snapshot, not a source of truth, and it tells you when to re-sync. I do this on my own routing and operating-manual files. They drift. Naming the drift makes it easier to fix.

Where projects start to break

So far, so good. You've got a project. You've written instructions that include some decision rules. You're feeling clever.

Now it starts to break.

The pattern is so consistent I can describe it before you've experienced it. The project starts working well. You begin trusting it. You start adding things — a transcript from a meeting, a document a client sent over, an old strategy doc you might reference later, a draft of something you're working on. The project file count creeps up. The instructions grow. New rules get added but old ones don't get pruned. Conversations inside the project start to feel slower, vaguer, less sharp than they used to be.

You can't quite tell what's wrong. Claude is doing the same thing it always did. The project has more in it than ever — surely that should be helping?

It isn't helping. It's the opposite. A few things are happening at once.

These aren't theoretical. They're predictable failure modes that show up in almost every project that's been used seriously for more than a couple of months. And they're all variations of the same underlying problem: the project has been treated as a knowledge management system rather than a context container.

That distinction matters more than it sounds.

The discipline: constants in, dynamics out

Here's the move that fixes most of this.

Some things in your work don't change very often. Your role. Your business model. How you make decisions. Your voice. The people you work with most. These are constants — slow-moving, deliberate, stable. They're useful to Claude on day one and still useful six months later.

Other things change constantly. Your current priorities. Today's blockers. The deal you closed yesterday. The decision you made this morning. These are dynamic — fast-moving, reactive, alive.

Project instructions are good for constants. They're terrible for dynamics.

This is the lesson I learned the slow way. I used to keep my current pipeline summary in my business project instructions — confidence levels, deal stages, where each opportunity sat. It worked for about a week. Then it didn't, because the pipeline moved faster than I was updating the instructions, and Claude was working from a snapshot of last Tuesday confidently presented as today's reality.

Now my project instructions tell Claude where to look for current pipeline state — query Attio, check Gmail — rather than trying to hold the state itself. The instructions don't decay because they're not trying to be the source of truth. They're trying to be the index that points to it.

The same logic applies to anything fast-moving. Don't try to hold this week's content calendar in your project instructions. Don't try to capture today's strategic priorities. Don't pin your current arc into a static document. Anything that's going to move faster than you'll update it shouldn't be in your project instructions at all.

What goes in: stable identity, slow-moving structure, decision rules, routing information.

What stays out: live state, current priorities, anything that's true today but won't be true next month.

This raises the obvious question: if all the fast-moving stuff doesn't belong in your project, where does it live?

Where the rest of it goes

You need a system outside Claude that Claude can read into.

For me, it's Notion. I have what I call my Lituus Brain — a structured workspace that holds my current arc, my client engagement context, my decisions log, my session notes, my strategic priorities. It's where the dynamic content lives, and it's where the outputs of my sessions go when they need to compound across future sessions. My project instructions know how to navigate it — page IDs, conventions, where to look for what. Notion is connected to Claude via a Connector, so Claude reads from it and writes to it directly without me having to copy anything across. Every meaningful session ends with a few minutes of updates to Notion: what changed, what was decided, what's next.

The principle is bigger than the tool. You don't have to use Notion. You could use Obsidian, Coda, a structured set of Google Docs, a personal wiki, whatever fits how you think. The point is that you need somewhere. Somewhere that's structured rather than just searchable. Somewhere your sessions can deposit knowledge into and your future sessions can read knowledge out of. Somewhere that compounds.

Without it, projects become the only place your context lives, and they crack under the load. With it, projects can stay clean — focused on identity, instructions, routing — while the actual operational reality of your work lives in a system that's built to handle it.

This is something I'm continuing to develop, and there's a separate set of pieces coming on it. If you want the longer thinking on what this kind of system looks like and why it matters, I've written about it in The Organisational Brain — start there. Read that piece, then ask Claude to help you map out a starting structure for your own. It's good at that — give it the article, tell it about your work, and let it propose a shape you can react to.

This is the move that changes how AI feels to work with. Not a project that knows everything. A project that knows where to look for what it doesn't have.

Closing

If you take one thing from this article, take this:

Treat your project as something to keep clean, not something to fill.

Projects don't get worse because Claude got worse. They get worse because they accumulate without curation. Constants in. Dynamics out. Decisions encoded as rules. Live state kept somewhere else and pointed to.

The grounding question still applies. If Claude retained nothing between sessions, what would you change about how you work? That's how to set up a project — assuming nothing carries forward except what you've explicitly placed inside the container. Everything else needs a different home.

The next piece picks up the thread from there. Once your project stays clean and your knowledge layer compounds, the next move is building the actions that work against the setup — the repeatable patterns that let you operate inside your own system without rewriting them every time. Skills.

Next in Working with Claude (2026)