Configuration & Knowledge Management
No audio recap for this lesson.
Screen 1: Configuration & Knowledge Management
Module 5Introduction·4 min
There is a line between using Claude and operating Claude.
Using it means typing a good prompt today. Operating it means building an environment where the right context, instructions, and procedures are already in place, so every conversation starts from a configured baseline instead of a blank slate. Configuration is leverage: you set it up once and benefit from it on every conversation that follows.
Configuration is also the move that turns individual skill into team capability. When the Project, instructions, and knowledge are curated, two people asking the same question get the same quality of answer. When they are not, everyone re-invents context daily and the answers drift.
There is a second half to the discipline: maintenance. Configurations age. A standing instruction written for last quarter's process, a knowledge base full of superseded documents, or a Skill that has drifted out of date will quietly degrade output. A well-configured environment is built deliberately and reviewed on a cadence.
By the end of this module, you will be able to:
- 1Configure Claude Projects with instructions and knowledge sources.
- 2Manage uploaded knowledge and connectors such as Google Drive and Gmail.
- 3Create effective system-level instructions.
- 4Inform, maintain, and update configurations, knowledge sources, and instructions.
Set up once, benefit every conversation, then maintain it so it stays true. Learn to configure a Project's instructions, knowledge, and scoped Memory; manage connectors and their boundaries; write persistent instructions that hold; and run the maintenance reviews that keep a configuration from decaying.
We built this Associate course Module 5: Configuration & Knowledge Management to help you get real work done with Claude. Treat it as educational content. It doesn't constitute legal, financial, or other professional advice, so adapt what you learn to your own situation. Our products and services evolve quickly, so certain content may contain errors or be outdated; remember to verify on Anthropic's website or docs. Examples and scenarios used in the course are illustrative and often fictitious. If the course material mentions a company or product, it doesn't mean Anthropic endorses them, they endorse Anthropic, or that we're affiliated. Also note your use of Anthropic products and services is covered by our terms, policies and documentation; if anything in this course conflicts with them, they control.
---
Screen 2: Configuring Claude Projects
TeachingConfiguring Projects·12 min
A Project has several configuration slots, and the skill is putting each piece of a recurring need into the right one. Instructions govern behavior, the knowledge base holds facts, Skills carry procedures, and scoped Memory keeps continuity. Choosing the right slot for each need is what makes a Project run smoothly.
The four configuration mechanisms
Flip each card to see what belongs in that slot.
Standing instructions
How Claude should behave across every conversation in the Project: tone, format defaults, verification habits. Behavior, not facts.
Knowledge base
The documents, policies, and reference files Claude should draw on without re-uploading. Facts and reference, not behavior.
Skills
Repeatable procedures Claude should follow consistently for a task type. Procedure, not one-off instruction. Skills live at the account level under Customize, not inside any one Project, a Skill you build is reusable across any Project that needs it.
Scoped Memory
Continuity within the Project, kept separate from your other Projects so context does not bleed between workstreams.
Choosing the right mechanism
The recurring question is: instruction, knowledge, or Skill? A rule about behavior ("always cite sources") is an instruction. A fact Claude needs ("our brand palette is these hex codes") is knowledge. A multi-step procedure ("format findings into our standard report template") is a Skill, built once at the account level under Customize and reused across any Project that needs it, rather than configured inside a single Project.
Putting a procedure into the instructions, or a behavior rule into the knowledge base, is the most common configuration mistake, and it makes the Project harder to maintain.
Worked example: a client account workspace
A consultant sets up one Project per client. For Client A:
Standing instructions: "Write in a formal register. Always cite the source document for any factual claim. Flag anything you are unsure of rather than guessing. "
Knowledge base: the client's brand guide, the current statement of work, and the last three status reports.
Skill (account-level, reused here): the firm's status-report formatter, which lives under Customize at the account level and is available to any Project, so every weekly update comes out in the same structure.
Scoped Memory: the client's stakeholder names and standing preferences, which never appear in Client B's Project.
On Team or Enterprise, the Project can be shared with the engagement team under permissions, so everyone works from the same configured baseline. Project-scoped Memory is what guarantees Client A's context does not appear in a Client B conversation, the separation that makes one-Project-per-client safe.
Scoped Memory as a first-class mechanism
Memory is easy to treat as an afterthought, but in a Project, it is a configuration slot like any other. Instructions say how Claude should behave and the knowledge base says what is true. Skills carry reusable procedures at the account level, available to any Project that needs them. Scoped Memory holds what the Project has already settled: the stakeholder names, the standing preferences, the decisions from earlier conversations you do not want to restate every time.
The word that matters is "scoped". A Project's Memory is sectioned off from your other Projects, so context built up for one client or workstream never appears in another. That isolation is what makes Memory safe for sensitive or client-specific continuity. Claude remembers what it needs to without the risk of it revealing information to the incorrect audience. Deciding what belongs in Memory versus knowledge comes down to type: a stable reference fact goes in knowledge while an evolving record of Project decisions goes in Memory.
When a need spans two mechanisms
The cleanest configurations rarely map a need to a single slot. The most common pattern is a behavior rule plus the facts it acts on: "Always cite the source document for factual claims" is a standing instruction, but the documents it cites live in the knowledge base. Neither works alone: the instruction has nothing to cite without the documents, and the documents get used inconsistently without the instruction. Skills pair the same way: a status-report Skill carries the procedure, while the brand guide it formats against sits in knowledge. So when you configure a Project, ask which slot a need belongs in, and whether it needs two slots wired together.
---
Screen 3: Connectors and Uploaded Knowledge
TeachingConnectors & Uploaded Knowledge·8 min
Connectors extend Claude's reach into the data you already work in, like Google Drive and Gmail. They are powerful, and they have boundaries.
Managing them as curated sources, and knowing exactly what each one can and cannot do, is what keeps them useful instead of frustrating.
Connecting external sources
A connector lets Claude reach an external system you authorize, such as searching your Drive for a document or finding a relevant email. You manage what is accessible, and you keep that set deliberate rather than connecting everything by default.
Capability boundaries
Each connector has a defined boundary and knowing it prevents wasted time. A mail connector may let Claude search and read messages but not send them. Expecting an action a connector cannot perform produces a confusing failure, not a clear error, so learn each connector's boundaries before you build a workflow on it.
Two field-observed pitfalls
Click each to expand.
Keeping uploaded knowledge current
Uploaded knowledge needs the same care as a connected source: keep it current, relevant, and free of duplicates. A knowledge base with three versions of the same policy invites Claude to cite the wrong one. Curate it the way you would a shared drive, removing deprecated versions as you add new ones.
---
Screen 4: System-Level Instructions That Stick
TeachingSystem-Level Instructions·8 min
Teams keep asking a version of the same question: can we bake the guardrails in once instead of re-typing them every conversation? Persistent instructions are exactly that mechanism.
You write the verification behaviors, format defaults, and tone once, and every conversation in the Project inherits them.
Write the guardrails once
The highest-value instructions are the ones you would otherwise re-type constantly. Set the verification behaviors as standing instructions, for example:
"Cite the source document for every factual claim, and say 'I don't know' rather than guessing when the documents do not cover something. "
Now that discipline applies to every conversation without anyone remembering to ask for it.
Anticipate the use cases
Good standing instructions embed format, tone, and guardrail guidance ahead of need. If the Project produces client deliverables, the instructions can specify the preferred format and register up front, so the first draft lands closer to a final deliverable rather than needing the same corrections each time.
Precision, or it silently fails
Vague instructions do not announce that they failed; they just quietly do not work. "Be professional" gives Claude almost nothing to act on. "Use a formal register, define any acronym on first use, and keep paragraphs under four sentences" is precise enough to change the output.
The test of an instruction is whether two different people would read it the same way.
Worked example: before and after an instruction
Toggle to compare the same instruction, vague versus precise.
"Make the reports good and accurate. " Output quality varies conversation to conversation; nothing concrete changed.
"For every figure in a report, state its source. If a figure is not in the provided data, mark it 'unverified' rather than including it. Lead each report with a one-sentence headline. " Now the verification behavior is consistent, and the headline appears every time.
---
Screen 5: Maintaining Configurations
TeachingMaintaining Configurations·10 min
Configurations are living assets. Instructions, knowledge, Skills, and Memory all drift toward stale, and stale configuration degrades output quietly, with no error to alert you. Scheduling maintenance is how you catch decay before it reaches a deliverable.
Review cadence
Set a recurring review for each active Project: do the standing instructions still match the current process, is the knowledge base free of superseded documents, are the right Skills enabled? A monthly pass for active Projects catches most drift. The signal that you waited too long is output quality slipping for no visible reason.
Skills versioning
Skills update over time. Anthropic-built and organization-provisioned Skills update automatically; your own custom-uploaded Skills change only when you re-upload them. Watch for a misconfigured or out-of-date Skill degrading output. A Skill that silently produces a slightly off format every run is a maintenance problem, not a prompting problem.
Memory lifecycle
Treat Memory like a working file. Review it periodically, edit or delete entries that have gone stale, and export it as a backup before a major change. When a Project's Memory has accumulated enough outdated context to mislead, a full reset is the right call. The accuracy of what is stored matters more than the volume.
Configuration is also additive: when Claude has not automatically captured a fact that matters: a constraint, a preference, a piece of background, add it explicitly to standing instructions or Memory rather than re-supplying it each session.
Worked example: auditing a degraded setup
The maintenance checklist finds the causes: a standing instruction still references a metric the team renamed last quarter, the knowledge base holds two versions of the template, and a Memory entry records a stakeholder who has left.
The fix is maintenance, not a new prompt: update the instruction, remove the old template, delete the stale Memory entry. Output returns to standard without changing how anyone prompts.
---
Screen 6: Module 5 Quiz
QuizModule 5·5 min
Five scenario-style questions. Each presents a situation; select the response that best applies the module's configuration framework. Approximately five minutes.
---
Screen 7: Key Takeaways
Module 5Key Takeaways·5 min
Five things that hold across this module:
Configuration is leverage.
Set up once, benefit on every conversation. A configured environment separates operating Claude from merely using it.
Match each need to the right mechanism.
Instructions for behavior, knowledge for facts, Skills for procedures, scoped Memory for continuity.
Know each connector's boundary.
Connectors extend Claude's reach, but each has a capability edge; knowing it prevents frustration and misrouted fixes.
Write instructions precisely.
Vague standing instructions silently fail; precise, testable ones change output every conversation.
Maintain or watch quality decay.
Configurations age. Schedule reviews of instructions, knowledge, Skills versions, and Memory, or output degrades with no warning.
All product behavior descriptions are based on claude. ai features as of June 2026. Feature availability and behavior should be verified against current Anthropic documentation at publish:
- Claude Help Center: Projects, knowledge base, Skills, Memory, connectors, support. claude. com
- Connector list, capability boundaries, and org-directory routing: confirm current behavior before finalizing Lesson 3
- Skills versioning behavior and Memory export/reset: confirm current claude. ai behavior before finalizing Lesson 5
- Team/Enterprise Project sharing and org-level Memory controls: confirm tier availability
---
Screen 8: Congrats! You’ve successfully completed this module.
Module CompleteAssociate Path·2 min
You can now configure Projects, set standing instructions, and manage knowledge for sustained performance. Set it up right, and Claude becomes a reliable team member, not a one-off tool.
M1: Product & Model Selection
Choose the right entry point, model, and features for any given task.
M2: Prompting
Build structured prompts and adapt them to the task type.
M3: Output Evaluation
Validate output and know when human review is non-negotiable.
M4: Workflow Integration
Map a workflow against Delegation criteria and redesign it safely.
M5: Configuration
Configure and maintain Projects, instructions, and knowledge.
M6: Governance
Apply use-case, data, policy, and ethics judgment responsibly.
M7: Troubleshooting
Diagnose underperformance and optimize workflows when results fall short.
M8: Course Summary & Next Steps
Recap the journey, prepare for the exam, and recognize escalation boundaries to the Developer and Architect tracks.