5.1 Configuring Projects, Uploads, and Connectors

Picture a support lead who, every single morning, opens a new chat and pastes in the same three things: the brand voice guide, the current refund policy, and a boilerplate instruction to "reply like a billing specialist, under 120 words." That's not a Claude problem, it's a configuration problem — and the fix has a name: a Project. A Project is a persistent workspace that bundles two things every conversation inside it can draw on automatically, without anyone re-typing or re-pasting a word.

The two things a Project bundles are Instructions — standing guidance for how Claude should behave in this workspace: its role, its tone, the format it should answer in, and the rules it should follow — and Project knowledge — uploaded documents and reference material Claude can ground its answers in. Configure both once, and every future chat in that Project inherits them for free. There is no re-explaining the brief on Monday and again on Tuesday; the workspace remembers.

Projects are the natural home for recurring, knowledge-heavy work: a client account you support across many conversations, a product line you write about on a regular cadence, a report you regenerate every quarter. The signal to reach for a Project isn't "this is important" — it's "this same context is going to show up again." A one-off question that will never recur is still perfectly fine as a plain chat; the Project's entire value proposition is persistence across many future conversations, not any inherent superiority for a single exchange.

This is also where a common exam distractor lives: when a scenario describes a repeated-context problem, the tempting wrong answer is often "use a more capable model" — as if a smarter model would somehow remember the brand guide on its own. It won't. Model choice has nothing to do with whether context persists between chats; that's a configuration decision, not a capability decision, and a Project is the configuration fix.

• •Recurring, knowledge-heavy work (a client account, a product line, a repeated report) → configure a Project.
• •A genuine one-off question with no expected recurrence → a plain chat is fine, no Project needed.
• •Repeated pasting of the same brief into new chats is the tell-tale symptom that a Project is missing.

A natural worry when uploading a lot of material to a Project is "won't this overflow the context window?" It doesn't work that way. When project knowledge is large — more documents than could ever fit into a single conversation at once — Claude retrieves the relevant portions of that knowledge rather than reading every uploaded file in full on every single turn. Retrieval is the mechanism that lets a Project hold far more reference material than any one context window, while still answering a specific question by pulling in just the parts that actually matter to it.

The practical implication for a business user configuring a Project: you don't need to fear "running out of room" by uploading a reasonable knowledge base, because Claude isn't loading all of it for every response. What you do need to manage is a completely different problem — what's in scope in the first place. Retrieval solves scale; it does not solve curation, and those are two separate concerns that a good Project owner has to handle separately.

Project knowledge should be curated, not treated as a dumping ground. Irrelevant or outdated files sitting in a Project don't just sit there harmlessly — they can dilute answer quality, because Claude may retrieve and ground an answer in a file that no longer reflects the current, correct version of the material. Retrieval is very good at finding content that looks relevant to a query; it has no way of knowing that a document is stale unless a person removes or replaces it.

This is the same discipline as tidying a shared drive: adding a file is easy and feels like progress, but a Project that only ever accumulates material — never prunes it — slowly turns into a pile where the newest, correct version and last year's superseded draft sit side by side with equal claim on Claude's attention. Curation means being as deliberate about removal and replacement as you are about upload.

Once a Project exists, there are exactly two ways to actually get knowledge into it. An upload is a file added directly — a PDF policy document, a spreadsheet, a slide deck — becoming Project or conversation knowledge as a static snapshot: the file as it existed at the moment someone attached it. A connector is an integration to an external source, such as Google Drive or Gmail, that lets Claude work with content where it already lives, rather than requiring someone to export a copy and attach it by hand.

That freshness distinction matters more than it first appears: an uploaded file needs someone to notice it went stale and replace it, while a connector inherently reflects whatever is currently in the connected source. Neither path is strictly "better" — an upload is right when you want a fixed, versioned snapshot; a connector is right when the source changes often and you want Claude to always see the current version.

A Project has a third mechanism beyond instructions and knowledge: Memory. Instructions set standing behavior and project knowledge supplies documents to ground answers in — Memory does neither. It quietly carries forward the small, settled facts a workspace has already learned about itself: a stakeholder's name, a formatting preference, a decision made three weeks ago that nobody wants to re-explain today. None of that belongs in an uploaded document, and none of it is a behavioral rule; it's continuity, and continuity is exactly what a brand-new chat doesn't have by default.

Memory is scoped to the Project, and that isolation is the whole point. Picture an equity analyst covering two direct competitors, Retailer A and Retailer B. Each company's confidential modeling assumptions must never leak into work done on the other — that's not a nice-to-have, it's the job. Running both inside one shared Project is the wrong setup even if it feels more convenient, because a figure or assumption Memory quietly picked up while working on Retailer A can resurface in a Retailer B session weeks later, with no warning that it happened. The fix is a separate Project per company, each carrying its own scoped Memory, so the isolation is structural rather than something the analyst has to remember to maintain by hand.

Here's how a professional actually notices Memory has gone stale, since nothing in the interface announces it. Picture an operations lead running a vendor-escalation Project. Early on, Memory picked up that packaging-vendor escalations go to Renee. Two months later Renee changes teams, a new contact takes over, and the lead dutifully updates the Project's standing instructions to name the new contact. Weeks after that, in a totally unrelated question, Claude still names Renee as the escalation contact. Nothing about the answer looked broken — it was fluent, specific, and confidently wrong. That's the tell worth training yourself to notice: a hedging or vague answer usually means Claude lacks information, but a precise, settled-sounding fact that no longer matches reality is Memory's signature. When you catch yourself thinking "that changed a while ago, why is it still saying this," the place to check is Memory itself, not the instructions and not the uploaded files.

• •A rule that must always apply no matter what happened before ("never promise refunds," "always reply under 120 words") belongs in instructions, not Memory — an enforcement rule stored as a Memory entry is one unreviewed moment away from silently stopping.
• •Real reference material with actual content to ground answers in (a policy document, a price list, a contract) belongs in project knowledge as an upload, not as a Memory note that summarizes it — a summarized policy has no version history and no obvious moment to replace it when the real policy changes.
• •A one-off, sensitive detail that isn't going to recur shouldn't be stored anywhere — it only adds one more entry that eventually needs reviewing, with retention risk and no ongoing benefit.

Memory also isn't permanent once written — a stale entry is actively misleading, the same way an outdated instruction is. Review stored memories periodically (at least monthly for active users) and keep the set focused on what genuinely recurs, exactly the same discipline curation demands of project knowledge.

Which connectors and related features are actually available is tied to the plan or pricing tier — it is not a universal capability every account has by default. A business user configuring knowledge sources needs to check what their tier actually supports rather than assuming every integration is simply there waiting to be turned on. An exam item that implies a connector is universally available on every plan is testing exactly this misconception.

There's also a governance overlap worth flagging here even though it's covered more fully in Domain 6: because uploaded and connected content may include sensitive data, only add data that policy permits. Adding a file or turning on a connector is a data-handling decision, not merely a convenience decision — it should be checked against organizational policy before that content becomes part of a Project's grounding material. Good knowledge management, in full, means adding the sources that matter, keeping them organized, and removing or updating stale material — an ongoing habit, not a one-time upload event.

• •Assuming all connectors are available on every plan — availability is tier-dependent, always check first.
• •Uploading or connecting regulated or sensitive data without checking policy first — a governance failure, not just a technical oversight.
• •Treating curation as a one-time cleanup rather than an ongoing habit — sources appropriate when added can become stale, or become inappropriate to keep after a policy change.