Skip to content

08. User Profile Stores — Memory with identity and permissions

~15 min read. Personalization becomes dangerous unless profile memory is explicit, scoped, and governed.

Built on the ELI5 in 00-eli5.md. The address-book — the durable profile store — holds who the user is, what they prefer, and what they are allowed to access.

1) What belongs in a profile store

See the picture first. 

address-book
├── preferences: concise bullets, Python examples
├── identity: user id, role, team
├── org context: company, product area, timezone
├── permissions: repos allowed, tools allowed
└── safety flags: do-not-store categories
A profile store is not just preference memory. It is the layer that gives memory a person and a scope.

Without it, personalization becomes shallow. Worse, authorization becomes unsafe. The address-book tells the agent:

  • who is asking
  • which organization they belong to

  • what defaults help them

  • what boundaries the agent must not cross Simple, no? A good profile store mixes convenience and control.

The convenience part is tone and format. The control part is permissions and policy. Never forget the control part.

2) Why profile memory is different from generic semantic memory

Semantic memory stores durable facts. Profile stores are a governed subset of those facts. They have stricter schema.

They have clearer ownership. They often need user-visible editing. Look at the difference.

semantic fact                     profile entry
"likes Python"         ──→       preferred_code_language = Python
"works in finance"     ──→       industry = fintech
"can access prod"      ──→       permission.prod_access = false/true
This structure matters. A vague fact may be enough for search. A profile entry must drive product behaviour safely.

That means typed fields. That means defaults. That means validation.

The address-book should feel boring. Boring is good here. Boring means reliable.

3) Schema and scope rules

Profile fields should have scope. Common scopes are: - user

  • team
  • organization

  • workspace

  • session override A user may prefer short replies. A team may require legal disclaimers.

An organization may ban certain tools. A session may temporarily request deep explanations. If you store all of that in one flat record,

conflicts become messy. 

request arrives
      │
      ├── session override
      ├── user profile
      ├── team defaults
      └── org policy
           │
           ▼
      resolved effective profile
This resolution order is important. Otherwise the agent may use a casual preference

that violates an org policy. Now what is the problem? Many teams implement personalization first,

and governance later. That order creates risk. Permissions should live beside preferences,

not as an afterthought.

4) Worked example: one user, three scopes

Suppose Meera works in a fintech company. User profile says:

  • prefers concise bullets

  • likes Python examples Team profile says:

  • use customer-safe wording in drafts

  • no screenshots in reports Org policy says:

  • no production database access

  • do not store personal financial identifiers Today Meera says,

"Give me a long explanation and include raw account ids." A good system resolves this as: - session override: long explanation for this turn

  • keep Python examples if relevant
  • keep customer-safe wording for drafts
  • reject raw account ids due to org policy

See. The address-book does personalization. It also enforces boundaries.

That is why profile stores are not optional fluff.

5) Operational rules

Profile stores should be easy to inspect. They should be easy to edit.

They should be easy to delete. Each field should record source and last update time. Sensitive fields need stricter retention.

The cleanup-bell should know profile categories too. Do not let inferred profile facts silently harden forever. Ask for confirmation when the impact is high.

Cache effective profiles for latency. But keep raw source records for audit. Look.

A messy address-book causes two failures. The agent feels generic. Or the agent oversteps.

Both are product failures.

Where this lives in the wild

  • ChatGPT Memory — OpenAI surfaces and manages durable user preferences that influence future interactions across sessions.

  • Microsoft Copilot for M365 — employee needs org-aware profile context such as role, tenant boundaries, and allowed data sources.

  • Salesforce Einstein Copilot — seller uses account, role, and org profile data to personalize recommendations without breaking permission boundaries.

  • Shopify Sidekick — merchant benefits from store profile context such as business type, catalog setup, and preferred reporting style.
  • GitHub Copilot enterprise chat — developer needs repo access rules and organization context so assistance respects workspace permissions.

Pause and recall

  1. Why are permissions part of the address-book, not a separate afterthought?
  2. What is the difference between a semantic fact and a governed profile entry?
  3. In the worked example, which scope overrode concise replies and which scope blocked raw account ids?

4. Why should profile entries store source and update time?

Interview Q&A

Q: Why treat user profiles as structured stores instead of free-form memory blobs? A: Product behaviour depends on deterministic fields such as permissions, role, and preferences. Free-form blobs are hard to validate and risky to enforce.

Common wrong answer to avoid: "Because databases prefer structured data" — the real reason is safe behavioural control, not storage convenience.

Q: Why should org policy outrank user preference during profile resolution? A: Preferences personalize output. Policies define allowed behaviour. Safety and compliance must dominate convenience.

Common wrong answer to avoid: "Because companies are more important than users" — it is about policy precedence, not social status.

Q: Why include session overrides when you already have a stable profile? A: Not every request matches the durable default. Session overrides allow temporary variation without corrupting long-term profile facts.

Common wrong answer to avoid: "Because users change their minds often" — the point is scoped override, not profile instability.

Q: Why let users inspect and edit profile memory? A: Profile memory directly affects output and trust. Transparency helps correctness, consent, and deletion workflows.

Apply now (5 min)

Exercise: Design a profile schema for one AI product. Include four preference fields and three permission fields. Then add one team-level rule and one org-level rule. Sketch from memory: Draw the scope resolution stack from session override to user profile to team defaults to org policy. Circle which layer has final authority.

Bridge. Good. We now have many memory stores. But when should the librarian fetch from each one, and how should it rank them? → 09-memory-retrieval-patterns.md