Stop re-explaining yourself

When you send a message, Claude already knows three kinds of things about you. Most people configure none of them, then wonder why every chat starts from zero.

The layering rule: put things at the narrowest layer they're true at. "British English" is true everywhere: preferences. "Acme's tone is formal": that's the Acme project. Break the rule and you get the classic failure, a global instruction bleeding into contexts it doesn't belong to.

A Project is a workspace with its own chat history, its own knowledge base, and its own standing instructions. Every chat inside it starts already knowing both.

• Knowledge base: upload documents, text and code once; every chat in the project can draw on them.
• Project instructions: a standing brief applied to every chat inside: role, tone, rules, background.
• Its own history: all the chats for that piece of work in one place instead of scattered through your sidebar.
• Sharing: on Team and Enterprise plans, a project can be shared, so the whole team works from the same brief and files.

Ten minutes, four steps, done once. The difference between a project that transforms your work and one you abandon is almost entirely step 3.

1. One context, one project. "Acme Corp", not "Work". A project earns its keep when everything inside shares the same background; mix contexts and the sharing becomes noise.
2. Upload the canon, not the archive. The brief, the key specs, the style guide, the current plan: documents you'd hand a new team member on day one. Not every email ever sent (section 05 explains why that backfires).
3. Write the instructions as if briefing that new team member. Section 04 has the working pattern.
4. Test it with a question you know the answer to. "What are we trying to achieve for Acme this quarter?" If the answer's wrong, fix the knowledge base now, not mid-deadline.

Weak project instructions describe ("this project is about marketing"). Strong ones change behaviour: what Claude assumes, refuses, and produces without being asked.

You're supporting our work for Acme Corp (B2B logistics
software, ~200 staff, UK).

Context: we're their retained marketing agency. Main
contact is Dana (CMO, direct, hates fluff). Current
focus: Q3 product launch.

Always:
- British English. Acme's tone: plain, confident, no
  exclamation marks.
- Check the knowledge base before answering; if the
  answer isn't there, say so rather than inventing
  Acme facts.
- When drafting anything Dana will see, keep it under
  a page and lead with the recommendation.

Never:
- Reference competitors by name in draft copy.
- Promise dates or pricing; flag them as 'to confirm'.

Notice the shape: context, always, never. The "never" list is what most people skip, and it's the half that prevents embarrassment. Keep the whole thing under a screen; instructions are rules, not a novel.

Understanding one mechanism explains every knowledge-base behaviour: with lots of material, Claude retrieves the parts that look relevant to your question, rather than re-reading everything every time.

On paid plans this retrieval switches on automatically as a project grows, expanding how much a project can hold to roughly ten times what fits in a conversation. The trade: retrieval is contextual, not a verbatim index. It finds material related to what you asked, which is not the same as finding the exact clause on page 41 every time.

What this means in practice

• Name files descriptively. "Acme Q3 launch plan v4, June" retrieves better than "final_FINAL(2)".
• One topic per document beats one mega-document. Retrieval grabs chunks; make the chunks coherent.
• Curate, don't hoard. Ten canonical documents outperform a hundred stale ones, because retrieval can surface an old version as confidently as the new one. When a document is superseded, replace it.
• For verbatim needs, point at the spot. "Quote the liability clause from the master agreement, exactly" or re-attach the specific file in the chat.

Memory is Claude quietly building a working picture of you across conversations: your role, your projects, how you like things done. Left alone it's helpful; steered, it's excellent.

• Two kinds of remembering. The picture Claude assembles itself, and the things you explicitly tell it to hold: "always remember I invoice on the 25th". The explicit kind is the one to use deliberately.
• You can read it. Memory is viewable and editable in settings. What Claude "knows about you" is a page you can open, correct and prune, not a black box.
• It stays out of private chats. Nothing from them is retained, and they don't feed the picture.
• Correct it out loud. "I've changed roles, I'm no longer at the agency, update your memory" works. So does "forget what I told you about X".

Three different tools answer "where did that go?", and people constantly reach for the wrong one.

The habit that ties it together: when a chat produces something durable, promote it. A decision, an agreed plan, a final draft: into the knowledge base. Chats are where things happen; the knowledge base is where things live.

Steal the one closest to your life and adapt it.

The client hub

Knowledge: the contract's key terms, current brief, style guide, org chart of who's who, latest status doc. Instructions: the context-always-never pattern from section 04. Used for: every email, deliverable and awkward situation involving that client. The payoff arrives the third time you don't re-explain the backstory.

The recurring deliverable

Knowledge: the template, the last three finished editions, the data-source notes, a "lessons learned" file you append to each cycle. Instructions: "We produce the monthly investor update. Match the attached editions' structure and tone exactly. Flag any section where this month's input data is missing rather than writing around it." Used for: turning a two-day dread into an afternoon of review.

The thinking partner

Knowledge: your strategy doc, goals for the year, notes on major decisions taken and why. Instructions: "You're my sounding board on the business. Challenge my reasoning before agreeing. Reference past decisions in the knowledge base when I'm about to contradict one." Used for: the conversations you'd otherwise have with the ceiling at 11pm.

The complete list of ways this system bites, so it doesn't.

• Chats don't see each other (worth repeating). Durable outcomes must be promoted to the knowledge base by hand.
• Retrieval isn't verbatim lookup. Don't promise yourself exact-clause recall from a huge base; point at the document when precision matters.
• Stale documents are landmines. Replace, don't accumulate. The knowledge base has no sense of "current" beyond what you curate.
• Instructions drift out of date too. "Current focus: Q3 launch" is wrong by Q4. Skim instructions whenever the work shifts phase.
• Free plans cap the number of projects (five, currently), so spend them on your highest-repetition contexts.
• Don't put secrets in shared projects. Shared project, shared knowledge base: everyone in it can draw on everything there.

The compact version, for the fridge door.

1. Narrowest layer wins. Everywhere-true facts in preferences, you-facts in memory, work-facts in the project.
2. One context, one project. The moment a project needs the word "and" in its name, split it.
3. Canon, not archive. Day-one documents in; superseded documents out.
4. Context, always, never. The instruction pattern that changes behaviour instead of describing vibes.
5. "Say so if it's not in the knowledge base." One line, most of the value.
6. Promote durable outcomes. Decisions live in the knowledge base, not in chat #47.
7. Test with a known answer after setup, and after big updates.
8. Audit memory quarterly. Stale beats absent for irritation, every time.