The Claude apps and projects: persistent context that remembers

They are not three products. A Project you create on web is instantly available on desktop and mobile. The differences are about *reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition →*: desktop can run local connectors and the filesystem; mobile cannot.

One term to define and move on: a Connector is a plug that lets Claude read from or act on an external system (Google Drive, GitHub, a database) using MCP, the Model Context Protocol. We will treat connectors lightly here and go deep on them in a later lesson. Today's focus is the persistent-context layer that sits *above* any connector.

What a Project actually is

A Project is a workspace that bundles three things and applies them to every chat created inside it:

1. Project knowledge: files and text you upload once (PDFs, docs, spreadsheets, pasted reference text).

2. Custom instructions: a standing system-level brief that shapes tone, format, and behavior.

3. The chats themselves: every conversation you start in the Project, kept together.

The mental model: a normal chat is a blank room. A Project is a room where the briefing is already on the wall before you walk in. You are not re-establishing context each time; you are continuing from a shared baseline.

This is different from pasting your handbook into a single conversation. Paste-and-go context dies when the chat ends. Project knowledge persists across every chat, indefinitely, for everyone with access to the Project (on Team and Enterprise plans, Projects can be shared).

The official reference lives at Anthropic's Projects help docs.

The concrete build: handbook plus style guide

Here is the scenario from the hook, done properly.

You have two assets:

• company-handbook.pdf: 200 pages of policies, benefits, escalation paths, security rules.
• style-guide.md: one page on voice (warm, direct, no jargon, British spelling, never promise refunds without manager sign-off).

Step 1: Create the Project. In the web app, open Projects and create one called "Support Desk Assistant."

Step 2: Add the handbook to Project knowledge. Upload company-handbook.pdf into the knowledge panel. Claude indexes it. Now every chat in this Project can reference page 147's escalation policy without you pasting anything.

Step 3: Write custom instructions. This is where most people undercook it. Be specific:

Step 4: Test it. Start a new chat in the Project and ask: "A customer wants a refund after 40 days. What do I tell them?"

Claude answers in British spelling, in the warm-but-direct voice, declines to promise the refund, points to section 6.2, and cites the source. You pasted nothing. The next chat, and the chat your colleague starts tomorrow, behave identically.

That repeatability is the point. A Project turns "Claude that happens to know this today" into "Claude that reliably behaves this way every time."

Project knowledge vs. the context windowcontext windowThe context window is the maximum amount of text (measured in tokens) a language model can process at once, including both the input prompt and the generated output.View full definition →

A fair question: if you drop 200 pages in, does that eat your context windowcontext windowThe context window is the maximum amount of text (measured in tokens) a language model can process at once, including both the input prompt and the generated output.View full definition → on every message?

Not the way pasting would. When Project knowledge is large, Claude retrieves the relevant chunks rather than stuffing the entire document into every prompt (the same retrieval idea you met at the concept level earlier in the course). When it is small, it can sit fully in context. Either way, you are not manually managing it.

Practical implication: keep Project knowledge *curated*. A tight handbook plus a clean style guide beats dumping forty loosely related PDFs. Retrieval quality drops when the knowledge base is noisy. Treat the knowledge panel like a reference shelf, not an attic.

Styles: voice without rewriting instructions every time

There is overlap worth clarifying. Styles let you save a reusable writing voice (formal, concise, your brand tone) and apply it to any chat with one click, *across* Projects. You can even teach a Style from sample writing.

So when do you use which?

• Put behavior and rules that are specific to one body of knowledge in the Project's custom instructions (the refund rule above).
• Put reusable voice you want everywhere into a Style.

In the handbook example, "British spelling, warm, direct" is arguably a Style you reuse across many Projects, while "quote section 6.2 for refunds" belongs in this Project's instructions. Splitting them keeps each Project lean and your voice consistent company-wide.

Where artifacts and skills fit

Two more pieces complete the picture inside the apps.

Artifacts are the standalone outputs Claude generates in a side panel: a document, a working web app, a chart, an interactive tool. Inside your Support Desk Project, you could ask Claude to build an Artifact: a small triage checklist app that encodes the handbook's escalation logic. It renders live, you can iterate on it in the same chat, and it inherits the Project's grounding.

Skills are packaged, reusable capabilities, folders of instructions plus optional scripts and resources that Claude loads when a task needs them. Where a Style shapes voice and Project knowledge supplies facts, a Skill teaches Claude a *procedure*: how to format a quarterly report exactly your way, or how to run a specific document-processing flow. Skills work across the apps, the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, and Claude Code. See the Agent Skills docs for the structure.

The layering is the mental model worth keeping:

• Project knowledge = what Claude knows.
• Custom instructions = how Claude behaves *here*.
• Styles = how Claude sounds *everywhere*.
• Skills = procedures Claude can execute.
• Connectors / MCP = systems Claude can reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition →.

Connectors and GitHub: when a Project needs live data

Static knowledge is enough for a handbook that changes quarterly. But some Projects need *current* data, and that is where Connectors come in.

On Claude Desktop, you can add Connectors (via MCP) so a chat can read from Google Drive, query a system, or pull from a repository in real time. There is a growing connector directory in the apps, plus the ability to build your own.

The GitHub integration is the standout for technical teams. Connect a repository and Claude can read your codebase as live context, not a stale snapshot. In a Project scoped to one repo, you can ask "where do we validate the refund window?" and Claude reasons over the actual code. This is the bridge to Claude Code, the terminal-based agent that operates directly on your repo, which gets its own deep lesson later in this path.

The distinction to hold onto: Project knowledge is a snapshot you uploaded. A Connector is a live line to a source. Use knowledge for stable references (the handbook). Use connectors for things that change under you (open tickets, the current branch, this week's spreadsheet).

When to reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → instead

Everything above is the app experience: human in the loop, clicking through chats. When you want this *programmatic*, you drop to the Anthropic Messages API, where Project-style persistent context becomes a system prompt plus documents you attach per request.

import anthropic

client = anthropic.Anthropic()

with open("style-guide.md") as f:
    style_guide = f.read()

message = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=(
        "You are Acme Ltd's support assistant. Follow this style guide "
        f"exactly:\n\n{style_guide}\n\n"
        "Never promise refunds; quote handbook section 6.2 instead."
    ),
    messages=[{
        "role": "user",
        "content": "Customer wants a refund after 40 days. What do I say?",
    }],
)

print(message.content[0].text)

That system block is the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → equivalent of a Project's custom instructions, and attaching documents per request mirrors Project knowledge. The app makes this point-and-click and persistent; the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → makes it scriptable and embeddable. For agentic workflows, the Claude Agent SDK wraps this same model with tools and loops. Start at the API docs.

Rule of thumb: use Projects when humans are doing the work in a shared, evolving space. Use the API / Agent SDK when software is doing the work at scale.

A few non-obvious habits

• One Project per job, not per topic. "Support Desk Assistant" and "Q3 Marketing Copy" should be separate Projects with separate instructions. Mixed Projects produce muddy behavior.
• Version your knowledge. When the handbook updates, replace the file rather than uploading a second copy. Two versions in the knowledge panel guarantees contradictions.
• Write instructions as rules, not vibes. "Never promise a refund; quote section 6.2" is enforceable. "Be helpful about refunds" is not.
• Pin the source-citation rule. Asking Claude to end answers with the section it used turns a confident assistant into an auditable one.

Key Takeaways

• A Project bundles persistent knowledge, custom instructions, and chats so Claude starts every conversation already briefed. Stop re-pasting context.
• Layer your tools by job: knowledge (facts), custom instructions (behavior here), Styles (voice everywhere), Skills (procedures), Connectors/MCP (live reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition →).
• Use Project knowledge for stable references and Connectors (like the GitHub integration) for data that changes under you.
• Write custom instructions as enforceable rules with a source-citation requirement, and keep the knowledge panel curated, not crammed.
• When the work moves from humans clicking to software at scale, the same pattern lives in the Messages API (system prompt plus attached docs) and the Agent SDK.