Session, user & organizational memory

Last reviewed: 2026-11 · Volatility: fast

TL;DR

"The product remembers me" is three different features with one name. Mixing them up is where most memory mistakes start.

• Session memory lasts for one conversation. It is gone when the session ends. It is the lowest-risk shape, and users expect it.
• User memory lasts across visits, for one person. It is a real data store. It needs consent, and a way for the user to see and change it.
• Organizational memory is shared across a team or company. Think of a style guide or standard procedures. Who counts as "inside" the organization is a security decision.

Each shape needs its own storage, its own review, and its own answer to "who sees this, and for how long?"

🎯 For the product leader

Why it matters — The stakes differ a lot. A session that forgets is a small annoyance. A private preference that leaks into shared, organizational memory is a privacy incident.

What it changes in your decisions — Every memory feature is scoped to one of the three shapes at design time. The line between shapes is a security boundary, not an implementation detail.

Ask yourself — "Which of the three shapes is this feature? Did we enforce that boundary, or only assume it?"

Risk if ignored — A feature built as user memory becomes visible across the whole organization. No one treated the boundary as something to enforce.

The mental model: a note, a file, and a shared handbook

• Session memory is a sticky note. It helps for one task, then you throw it away.
• User memory is a personal file. It lasts, it is about one person, and that person expects some control over it.
• Organizational memory is a shared handbook. Everyone on the team reads it. Someone must keep it accurate. The key question is who counts as "the team".

Session memory: low risk, still worth naming

Inside one conversation, carrying earlier turns forward is a basic expectation. An assistant that forgets your name three messages later feels broken.

The risk is low because nothing outlives the session. Still, name it in the spec. It has a real cost: the context must be managed as the conversation grows. It also has a real edge case. In a long session, early details get summarised or dropped. Decide which details must survive that step. The mechanics are in Context engineering.

User memory: a real store with real duties

Once information outlives the session, you have built a data store about a real person. It inherits the duties of any personal data store.

• The user knows it exists.
• The user can see what is stored.
• The user can correct it.
• The user can delete it.

A feature that delights users with "it knows me" but hides what "knows me" means builds trust debt. The debt comes due the first time the memory is wrong.

Organizational memory: the boundary is the feature

Shared knowledge is valuable. Examples are a style guide, a support playbook, or "how we handled this last time". The whole risk sits in one question: exactly who can read and write it?

If you get the boundary wrong, one team's, tenant's or customer's information appears in another's view. That is the failure covered in When memory goes wrong. The defence is the same multi-tenant isolation you would apply to any shared system.

What a shipped product does

Anthropic's Claude help page shows how one vendor drew these lines (checked 2026-11). Each project has its own memory. A project chat uses that memory plus account memory from non-project chats, but not memory from other projects. On Team and Enterprise plans, the owner decides whether memory is available, and each member starts with it off. Owners cannot view or edit members' memories. Sensitive topics such as health are off by default and need each user to opt in. Incognito chats never write to memory.

Copy the pattern, not the settings. The user owns personal memory. The admin owns only the on-off switch. Check whether an admin should ever read a member's memory in your product. If yes, say so in the spec and tell the member.

Worked example: three notes, three shapes

This example is invented, to show the method.

A sales assistant has three things it might remember. The team places each one.

Now the tempting mistake. The assistant notices that Priya's summaries score well and proposes to fold her style into the shared handbook "to help everyone". That moves a fact from user to organization. It is a shape change, so it needs its own review and Priya's consent. It must not happen as a side effect of a tuning change.

Why name the shape first

Most serious memory failures start when a feature drifts from one shape to another, and no one decided it should. A session note gets saved by accident. A personal preference gets merged into shared knowledge. Name the shape at design time. Treat any move between shapes as a decision with its own review. This is the cheapest safeguard you have.

Failure modes

• Unnamed shape. The feature acts however the implementation happens to make it act.
• Session memory that outlives the session. Temporary data is saved by accident because nothing cleared it.
• User memory with no visibility. A personal store the user cannot see, correct or delete. They find it when it says something wrong.
• Organizational memory with an unenforced boundary. Shared data reaches more people or tenants than intended.

Under the hood

The boundary must be enforced in the store, not in the prompt. Scope every read and write by the caller's identity, and filter before anything reaches the model.

def read_memories(store, caller, query):
    # The scope comes from the authenticated caller, never from model output.
    allowed = [
        m for m in store.search(query)
        if (m.scope == "user" and m.subject_id == caller.user_id)
        or (m.scope == "org" and m.subject_id == caller.org_id)
    ]
    return allowed   # only these are placed in the model's context

Three rules keep this honest.

• Take the identity from the session, not from the model. A model can be tricked into asking for another user's id.
• Filter before ranking or summarising. A summary of data the caller may not see is still a leak.
• Log every read across a shape boundary. You cannot audit what you did not record.

The Claude memory tool works this way by design. Its /memories path is only a prefix. In the docs' words, your handler maps it "onto real storage, such as a per-user directory or keys in a database." Choosing that mapping is the boundary decision.

Practitioner checklist

• Is every memory feature labelled session, user or organizational?
• For user memory: can the person see, correct and delete it?
• For organizational memory: does the system enforce who is inside the boundary?
• Do we review it as a real decision when data seems to move from one shape to another?
• Do scope checks use the caller's authenticated identity, not text the model wrote?

Related lessons

• Memory as a product decision — the four-part question each shape must answer.
• Writing and maintaining memory — how items enter and leave each shape.
• Multi-tenant isolation — the boundary discipline organizational memory depends on.
• When memory goes wrong — what happens when a boundary fails.
• Context & memory — the same three shapes in the agent hierarchy.

Sources

• Anthropic, Memory tool (Claude API docs): /memories is a prefix your handler maps to real storage, such as a per-user directory or database keys. Checked 2026-11.
• Anthropic, How does Claude's memory work? (help centre): per-project memory, Team and Enterprise defaults, admin limits, incognito. Opened 2026-11.
• The sales-assistant scenario is invented and illustrative.