Shared memory
Team-scoped facts with a legible ownership trail.
Personal memory is hard. Team memory is harder. Who taught the model this fact. Who can change it. Who can't see it. Who inherits it when someone leaves. The moment memory gets shared, you are no longer designing a memory feature; you are designing a small piece of access-control policy, wearing a sidebar.
The good pattern treats every shared fact as a ledger entry with three visible properties: an author, a scope, and a retraction verb. Everything else is decoration.
"A team fact is a mini-policy."
Owner, scope, retraction.
Every fact in shared memory carries an owner — the person who taught it to the model — and a scope: me, team, or org. The scope determines who reads the fact when prompting. Each fact has a retract verb, which is immediate for its owner and moderated for everyone else.
The interface reads like a ledger, not a spreadsheet. Rows, not columns. The three actions (transfer, change scope, retract) are equally weighted. There is no "edit everything" mode.
My revenue docs live under /rev in the shared drive.
scope · Team (6 readers)owner · D · designerThe company abbreviation for the North America region is NAM, not NA.
scope · Org (214 readers)owner · L · legalI prefer responses under 80 words in standups.
scope · Me (1 reader (you))owner · YouThe Q3 kickoff is the second week of July, not the first.
scope · Team (6 readers)owner · E · engineering
Every shared fact has an author, a reader set, and a retraction button.
The scope is the consent surface.
When a designer teaches the model where the revenue docs live, that fact is useful to the team. It is not useful to every employee at the company, and in some org structures it would be a small leak to surface it org-wide. Scope is the tool that prevents that leak.
Reader count is the visible proxy for scope. "6 readers" reads differently from "214 readers." The interface that shows the count in place does most of the policy teaching for you.
The shared memory I'd ship.
- Scope is a choice at teach-time. When the model proposes to remember a fact, the chip that confirms should include a scope picker. Default to "me." Do not default to "team."
- Transfer, don't rewrite. If a user wants to take over a fact someone else taught, they should claim ownership, not overwrite. The history of who taught the model matters when facts go wrong.
- Retract on leave. When a user leaves the workspace, their contributions enter a soft-retract window. By default, after 7 days, their team-scope facts are pruned. Otherwise, you end up with ghosts in the ledger.
Cross-org leakage.
The worst failure of this pattern is silent: a fact with org-wide scope that was clearly meant to be team-scope only. The teacher doesn't realize it's being read by 200 other people. The readers don't realize they're being primed on context they don't need.
Show the reader count at teach-time. Color it brass when it crosses a threshold. Make "org scope" feel like an explicit decision, not a default.
What this pattern gets wrong when it gets wrong.
- Stale memory
- A persistent fact about the user that's out of date and silently poisoning answers.
- Leaky context
- Content from another source, session, or user surfacing in a place it shouldn't.
- Role drift
- The model or the user shifts role mid-session without the interface updating tone, scope, or permissions to match.
Three shipping variants worth copying.
- A per-fact owner badge with a 'transfer' affordance
- An explicit scope selector (me, team, org) with a preview of who can read
- A 'retracted on leave' rule that prunes a leaver's contributions after 7 days