Claude Memory and Personalisation: How Claude Learns Your Preferences

The Reality of Claude Memory and Personalisation

There's a common misunderstanding about how Claude handles memory. Many users expect Claude to automatically remember everything from previous conversations — the way a human colleague would recall previous discussions. It doesn't work that way by default, and understanding why is important for designing effective enterprise deployments.

Claude is stateless by design. Each conversation starts without any automatic knowledge of previous conversations. This is a deliberate architectural decision — it provides privacy guarantees, predictability, and consistency that are important for enterprise use cases. Your IT and security teams can be certain that conversation data from one user doesn't leak into another user's context without explicit configuration.

That said, Claude does have several well-designed mechanisms for persistent memory and personalisation — they just require explicit setup rather than happening automatically. Understanding these mechanisms, and knowing which one to use for which situation, is one of the key skills for getting sustained value from a Claude enterprise implementation.

The Three Types of Claude Memory

Auto-Memory in Claude Cowork

Claude Cowork includes an auto-memory system that does what users expect from AI memory by default — it records facts, preferences, and context from conversations and makes them available in future sessions. The system is transparent: you can see what Claude has remembered, edit memory entries, and delete specific memories. It's not a black box.

Auto-memory in Cowork works through a memory directory in your workspace. As you work with Claude, it identifies facts worth remembering — your role, preferences, ongoing projects, key contacts, recurring tasks — and writes them as structured entries in memory files. In future sessions, Claude reads this memory file before starting, giving it context that makes every interaction more effective from the first message.

The types of memories Cowork's system records include: user-level facts (your role, responsibilities, communication preferences), project-level context (current priorities, key decisions, stakeholder names), feedback memories (what approaches worked well, what to avoid), and reference memories (where to find information, which systems to use for which tasks). This mirrors how a human assistant builds up working knowledge over time.

Managing Auto-Memory

You can review and manage your Cowork memory from the settings panel. Memory entries are categorised by type and listed with the context that generated them. Delete entries that are outdated or incorrect. Edit entries to correct facts. This transparency is deliberate — enterprise users need to be confident in what Claude knows and where that knowledge came from.

For enterprise deployments, admin controls determine whether auto-memory is enabled for individual users, whether memory is scoped to individual Projects or accessible across Projects, and whether IT has visibility into memory content for compliance purposes. These settings should be configured during initial deployment, not discovered later.

Memory in Claude Code: CLAUDE.md and Memory Files

Claude Code uses a file-based memory system centred on the CLAUDE.md file. This file, placed in your project's root directory, is read by Claude at the start of every session. It's the mechanism through which teams encode their conventions, architectural decisions, coding standards, and accumulated project knowledge into Claude's working context.

# Project Memory — PaymentService API

## Architecture Context
- Service handles payment processing for 3 currencies: USD, EUR, GBP
- Uses Stripe for card payments, Plaid for ACH
- Auth handled by shared auth-service, not implemented here
- Test environment uses Stripe test mode — never use live keys in dev

## Team Conventions
- All async functions use the async/await pattern (no raw Promises)
- Error handling: throw typed errors, catch at the controller layer
- Database: Postgres via Prisma ORM — always use transactions for multi-table writes

## Known Issues
- Webhook retry logic is not idempotent — see ticket PAY-2847
- Rate limiting middleware needs updating before Q2 launch — PAY-2901

Beyond CLAUDE.md, Claude Code supports additional memory files for specific contexts: per-developer preferences, per-task notes, accumulated debugging knowledge. These files are managed by Claude itself as it works — writing what it learns, reading what it needs — through the Skills and hooks system.

Personalisation Strategies for Enterprise Teams

Effective Claude personalisation at the enterprise level is a combination of four layered inputs: organisational context (what Claude knows about the company), team context (what Claude knows about the team's role and workflow), individual context (what Claude knows about the specific user), and task context (what Claude needs for the current task). A well-designed implementation provides all four layers.

Organisational-Level Memory

Every Project should start with organisational context: company name, industry, key products, terminology, and the regulatory environment. This goes in Project Instructions. It doesn't change often, but without it, Claude's outputs lack specificity. A financial services firm that doesn't tell Claude it's subject to FCA regulation gets generic outputs. One that does gets outputs calibrated to its compliance environment.

Team-Level Memory

Team-level context goes in shared Project Instructions for team Projects, or in Skills that the whole team uses. It includes: team-specific terminology, workflow patterns, output format standards, tools and systems in use, and recurring context like "we're in Q2 planning until April 30th" that affects how Claude prioritises and frames outputs.

Individual-Level Memory

Individual preferences live in Cowork auto-memory or in personal Project Instructions for individual workspaces. Communication style preferences (concise vs detailed), working style patterns (the user always wants a summary before detail), expertise level in different domains, and recurring personal context (current role, key responsibilities, regular meetings). This layer is where Claude shifts from useful-for-everyone to genuinely-personalised.

Memory Governance for Enterprise

Memory governance is the set of policies that determine what Claude should and shouldn't remember, where memory is stored, who can access it, how long it's retained, and how it's audited. This is not an afterthought — it should be designed before deployment, especially for regulated industries.

Key governance questions include: Should Claude's memory of client conversations be accessible to other team members, or scoped to individuals? What types of information should never be stored in Claude's memory (PII, privileged legal communications, personally sensitive information)? How long should memory entries be retained before expiry? Who can delete or modify memory entries, and is that deletion audited?

For organisations subject to data retention regulations — financial services with MiFID II requirements, healthcare with HIPAA, organisations subject to GDPR — memory governance must be designed in concert with your compliance function. Our Claude security and governance service includes memory governance policy templates for regulated industries.

What's Coming: Claude Memory in 2026

Anthropic has confirmed ongoing investment in memory capabilities throughout 2026. The two most significant upcoming developments are extended auto-memory (longer retention, more sophisticated categorisation, and smarter retrieval of relevant memories in context) and cross-Project memory (the ability to define certain memories as global and accessible across all Projects, rather than scoped to individual workspaces).

Enterprises planning large-scale deployments should design their memory architecture to be modular — separating organisational context from team context from individual context — so that each layer can be managed and updated independently as the memory system matures. The Claude enterprise implementation frameworks we use account for memory architecture evolution so clients aren't locked into a design that becomes obsolete as the product develops.

Related Articles