Every person in your life gets a page in Meta's Muse, and none of them agreed to it
Meta's Muse runs an hourly job that writes a page about every person in the user's life; here is what the agent's own files say those pages hold, what its "forget" control does not remove, and the choices facing any team shipping memory into an assistant.
An hourly job inside Meta's Muse writes a page about every person in the user's life. The pages live at
~/memory/people/, one file per person, holding the facts, the history and the nature of the relationship, ordered by closeness. Strangers and public figures get nothing. The people who do get a page are the ones the user actually talks to.That sentence is not a leak and not a rumour. It is a line in the agent's own internal documentation, published this week by researchers who rebuilt Muse's runtime from a copy of its virtual machine and checked every quotation on their page against the file and line range it cites 1.
Meta's answer to WIRED is that an assistant needs context about the people you interact with in order to be useful, and that Muse takes that context from public information and from what the user chooses to share 2. Both halves of that are true. Neither speaks to the people written about, who are not Muse users, accepted no terms, and have no account to open.
What follows is what the store holds, how it gets built, what a user's controls remove and what they do not — and which of these decisions land on any team shipping memory into an assistant this quarter.
Loading content card…
That video, posted the morning after the WIRED piece, is a plain-language walkthrough of what Muse maps about the people around a user.
What the memory system actually does
Muse's memory is files. A curated sheet at
~/MEMORY.md holds facts, preferences and commitments. Dated notes under ~/memory/ keep the day-to-day detail. Material derived from them sits under memory/bank/, sorted into world, experience and opinions, with every line pointing back to the source it came from. The same virtual machine carried roughly sixty-eight skill directories and about twenty internal manuals 3.An hourly consolidation job is what turns conversation into that store. It checks newly extracted claims against the original messages, records a quote with message IDs, a kind and a salience score, promotes durable details into the curated sheet and leaves the rest in the daily log. A newer claim can retire an older one through a
supersedes_claim_id field 3.Postgres makes the result searchable.
memory.entries holds chunks and line references, memory.embeddings holds 384-dimensional vectors of them, and memory.claims tracks evidence, confidence and status. The agent reads with memory_search and inspects the evidence behind a hit with memory_explain 3. A nightly "dream" reviews recent conversations and writes standing guidance for later sessions. Adaptation happens through files and instructions; the model's weights never move.
The architecture deserves a second look, because it is not exotic. It is the shape most shipped memory features take once they leave the demo: a curated summary over an append-only log over a searchable index, with a background job deciding what gets promoted. Which means the question this piece is about — what happens when a memory is about somebody who is not the user — is not a Meta-specific problem. It is the default outcome of that shape.
The page that is not about you
The job that writes those pages runs hourly, and the internal documentation describes it in one line: "Relationships (hourly): maintains a page per person and group in the user's life (
~/memory/people/, ~/memory/groups/) with the facts, history, and nature of each relationship, ordered by closeness" 1.The worker prompt behind it is an editing brief. It tells the model that previous steps have handed it "the full ordered roster" of people with a one-line summary each, and asks it to decide "who in the user's life… has no page yet, or a page that no longer matches who they are, and write them; then do the same for the circles they belong to" — the college crew, the team at work, the family thread, the climbing partners 1.
WIRED, working from instructions extracted through the ordinary chat interface, lists the page sections: Facts, History, The relationship, In common, Open threads and Strengthening. The last suggests ways a relationship could be improved, including "a reason to call, a date worth remembering, something they said to circle back on" 2. The review's reading of the same files adds two template fields: how the person prefers to be communicated with, and the open promises the user made to them in messages 1.
There is a bar, and it is worth knowing before the story hardens into something simpler than it is. Strangers, public figures and people who appear only in search results get no page, and WIRED reports an instruction that invented details are worse than an empty page 2. Nothing conditions the job on the subject's agreement, because there is nothing to condition: the subject of the file is not a party to it 1.
The sharpest detail is a contradiction inside the product's own files. The user's profile document opens its context section with the instruction: "You're getting to know a person, not building a dossier" 1. The goal-creation skill for relationships goes further and tells the agent not to infer sensitive traits about other people, and to ask before saving a sensitive inferred detail. The hourly job that actually writes the pages carries no such rule 1.
How the files left the machine is part of the story. An independent researcher asked the agent to archive what it could see and send the archive to his own cloud storage; over a long conversation, the request growing each time, the agent did — around 2.7 GB compressed and 6.8 GB unpacked, including internal documentation, integration code and memory files. He reported it through Meta's bug bounty programme and was told the report was Not Applicable 3. Developers had found the same behaviour days earlier; Meta described it as intended rather than a breach, since one user's machine is isolated from another's 1. Meta's own account of the design — a dedicated virtual machine per user, memories that can be wiped, connected services that can be disconnected, confirmation before consequential actions — is reported by WIRED 2.
What the people on those pages can get
Nothing, directly. There is no notice to them, no page they can open, no copy they can request, and no deletion route that begins with them. Every control that exists belongs to the account holder.
For the account holder the controls are real but narrower than the word "forget" suggests. The reviewers' reading of the forget skill is that asking Muse to forget something edits the memory notes and keeps the chat transcript, and that the skill instructs the agent not to present "the continued visibility or retention of the chat itself as a cleanup limit" 1. The privacy documentation says the same from the other side — forgetting "edits memory notes but keeps chat transcripts unless you separately delete the conversation" — and the same document notes elsewhere that the main chat cannot be deleted at all 1. The skill does require the agent to name other retained copies, such as logs, backups and outside services, by everyday category. The visible conversation is the exception 1.
Then there is the boundary of the machine itself. The forget flow's own inventory of where copies live lists the centrally published user-memory embedding, fleet-learning and feed publication outboxes, centrally published lessons, and community cards derived from the user's material — alongside telemetry, write-ahead logs, snapshots and backups that, in the inventory's own words, a subagent inside the virtual machine may not be able to erase 1.
Put those two facts beside the relationship pages and the asymmetry is the finding. A page about a third party is created by an hourly job nobody asked for, and unwinding it runs into a transcript that is kept and a set of copies outside the machine the user was given. The Centre for Democracy and Technology's Miranda Bogen frames the direction of travel in the WIRED piece: these tools "are actively soliciting users to plug their whole lives in — their emails, calendars, financial institutions, everything" 2. Meta's help documentation covers how to edit what Muse remembers about you and how to import memory from another assistant; it does not cover a page that is about somebody else 4.
What the research already assumes
The design question here has a literature, and it is further along than the shipped products suggest.
A scoping review published in September screened 58 studies on what happens when an assistant organised around one user starts to involve other people. It maps five operational pathways by which others get drawn in, direct and indirect; five recurring risk domains; and five areas of implemented or proposed responses. Its conclusion is not that assistants should stop being personal. It is that governance has to attend to "changing cross-person roles and relationships in practice", and that designs should "preserve person-specific boundaries throughout interaction" 5.
The most concrete proposal is EP-Mem, posted on 28 September, which reframes privacy in an agent's memory as user-owned boundary control across social roles. Each contact gets a level from L0 to L4, where a higher number means less trust and a narrower disclosable scope; within a level, boundaries can split by domain, so parents and a manager sit at the same trust level but different domains. On the information side, categories map to those levels, with whitelist and blacklist rules evaluated per memory unit, and a privacy engine attached to the memory pipeline at construction, storage and retrieval. The authors report 94.0% event-level privacy classification accuracy, disclosure-permission accuracy rising from 22% to 68%, and a leakage measure falling from 0.738 to 0.180 6.
A second paper from August attacks the storage side: keep the sanitised version of an interaction apart from the exact private values, store them in isolated structures, and retrieve the values only when the task needs them and the user has consented 7. A survey of privacy in LLM agents makes the same split one level up, treating memory as one of several channels through which private data escapes rather than the only one 8.
The gap between those papers and a shipped assistant is not research. It is that the boundary belongs to the person who installed the agent, and the people described in its memory have no side of the transaction to stand on.
Where your product sits
- You already ship memory, or you are about to. Compare your store against Muse's: a curated summary, an append-only log, derived records, a search index. Then ask the question this story forces — which of those records are about someone who is not the account holder, and who can see them 3.
- Your assistant reads mail, calendar, messages or photos. Those are the inputs the relationship job draws on: messages, photos and memory, in the review's account 1. Any feature that summarises an inbox is one design decision away from writing a file about the people in it.
- You ship consumer memory controls. Test what your delete deletes. The pattern to avoid is a control that removes the note, keeps the transcript, and never mentions the transcript — which is what the reviewers say the forget skill does, while other retained copies are reported by category 1.
- You build an assistant for a company rather than a person. Multi-user memory raises the same problem with an org chart on top: a record about a colleague can be created by whoever talks about them. The scoping review's five pathways are the checklist 5.
- You are buying an agent platform. Ask for the file-level inventory of where a memory lives after deletion, not the retention summary. The forget flow's own inventory is the useful precedent, because it lists outboxes, published embeddings, telemetry and backups, and admits a subagent may not reach them 1.
A 90-day watching brief
- Inventory your memory store by subject, not by table. For one week, list every record your agent writes that names a person who is not the user, and note which ones that person would object to 3.
- Write down the rule for people who never signed up. The shipped contradiction is the useful model: the personal file says "not building a dossier", the goal skill forbids inferring sensitive traits about others, and the job that writes the pages has neither instruction 1. Put the rule where the job runs, not on a policy page.
- Run your delete path end to end, on a real account, and write down what survives. Distinguish the record, the transcript it came from, and the copies outside your machine 1.
- Decide whether contacts get a boundary object. EP-Mem's ladder-plus-category policy is the cheapest structure to reason with, and its benchmark is public 6.
- Separate what you store from what you may reveal. Isolated storage for exact values, with retrieval gated on task need and consent, is the August paper's core move and it costs less utility than deleting the values outright 7.
- Watch for the first complaint rather than the first bug. State privacy law gives a data subject rights against whoever holds their data, and the person on a relationship page holds none of the account 5.
The decisions, with the clock on them
| Decision | What the sources provide | The constraint that decides it | Act when |
|---|---|---|---|
| Whether your assistant may write records about non-users | A shipped product that does, and a review that documents the job 1 | Nothing prevents it technically; the exposure is to people with no relationship to you 2 | Before the next memory feature ships |
| What "delete" means in your product | A documented gap between the memory note, the transcript and the copies outside the machine 1 | A delete path can only reach what your agent can reach 1 | At your next privacy review |
| Whether contacts get their own boundary | A published trust ladder and category scheme, with measured results 6 | Retrieval quality against disclosure accuracy 5 | When you next touch memory retrieval |
| Whether exact values are stored or withheld | A design that keeps sanitised content and exact values apart, retrieved on consent 7 | Task accuracy against the cost of a consent prompt nobody wants to answer | At your next architecture review |
| What you ask a vendor's agent for | An inventory of outboxes, published embeddings, telemetry and backups, with the admission that a subagent may not reach them 1 | You cannot verify a claim you have no artefact for | In your next renewal or security questionnaire |
The relationship pages, the hourly cadence, the exclusions, the page fields, the forget behaviour, the artifact inventory and the "not building a dossier" line all come from one citation-checked review of Muse's own virtual-machine files, written by researchers at futuresociety.ch; those findings are the reviewers' reading of Meta's internal documentation, not a statement by Meta. The extraction route and the archive sizes come from the researcher who made the copy, who published his own account and says Meta closed his report as Not Applicable. Meta's position, the page-section list and the expert quotes come from WIRED. Meta's own posts and help pages are the source for the launch, the dedicated virtual machine and the memory controls. The research figures come from four preprints posted between May and September 2026, none peer-reviewed here, and they measure prototypes on benchmarks rather than shipped products. No independent audit of Muse's memory store has been published.
References
- 1Muse, in its own files
futuresociety.ch
- 2
- 3
- 4
- 5
- 6
- 7
- 8
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.