Earlier tutorials built memory for projects and code. This tutorial turns Loom into a durable personal assistant that remembers your life context across sessions: preferences, constraints, plans, corrections, and the things you want surfaced at the right moment. The theme throughout is privacy-conscious: you decide what is remembered, who can read it, and you can always retract or correct it.
Continue from Tutorial 12, with [loom_demo] as your working store. [loom_demo] is writable for your account and already has starter data, so it is a safe place to practice personal memory before you use a personal store.
Note on sample identity: This tutorial uses the placeholder dev1@gmail.com everywhere a real email or credential would appear. Never use a real email, address, or account credential in memory you do not intend to be remembered.
loom_demo the session defaultloom_demo and make it the default for this session only. Confirm the effective session default, and do not edit ~/.loom/stores.toml.loom_demo store and changes only this session's default routing.loom_demo is now the default for this session. Persistent configuration was not changed.Loom's personal-assistant behavior is driven by the PersonalDomain capture and retrieval discipline — the compose rule that tells the agent what to save, how precisely to record it, and when to reconcile an older fact. This is the same rule an assistant uses to remember life/work state from ordinary conversation. You do not need to know its internals; you just need to give the agent clear instructions and let it follow the discipline.
The core of personal memory is a fact that stays true across sessions. Preferences are high-value: they shape advice without you re-explaining every time.
[loom_demo], remember a durable preference: I prefer no unsolicited push notifications, and I want meeting times kept in the afternoon when possible. Use the placeholder email dev1@gmail.com for anything identity-related.PersonalDomain capture discipline, retrieves any prior facts that could conflict, and saves the stated preferences as current facts scoped to the placeholder identity. It checks that a later Preference-shaped request can retrieve them.[loom_demo]: "prefers no unsolicited push notifications" and "prefers afternoon meeting times when possible". Each is a current fact retrievable in a future session.This is the durable half of personal memory: a fact you stated once, remembered so it can influence a later session. Loom does not independently notify you or act on your behalf; relevant memory may surface as context at session start (priming) or when a request touches its subject (intent surfacing), and the agent judges whether to use it.
Preferences shape what you'd like; constraints shape what you can or cannot do, and plans capture an intended sequence. They are distinct kinds of memory, and the agent records them separately so a later question can address each.
A later question like "can we schedule a call for 8pm?" will surface the constraint; "remind me what I decided about the trip flights" will retrieve the plan — each answered from the fact that matches its kind.
A personal assistant is most useful when context shows up at the moment it can change a decision, not only when you explicitly ask. Loom's proactive surfaces — priming at session start and intent surfacing when a request touches a subject with standing context — are the same ones you used in Tutorial 06.
The memory surfaced because the request touched a subject with standing context. You did not have to re-state the constraint; the agent judged whether it applied and flagged the conflict rather than silently scheduling into it.
Memory that cannot change becomes wrong memory. Loom records a correction as a superseding fact that references the old one, and removes a bad entry by soft-retracting it. This keeps history while making the current answer correct.
Supersedes() edge to the old constraint — a non-adversarial update: your situation changed, so the old fact stays as valid history rather than being marked false. For the dental idea, it treats the false start as a data error and forgets it (a soft-retract: the fact disappears from reads but stays in the store for history).The distinction matters: a change in your situation is a supersession (Supersedes()) — the old fact stays as valid history — whereas an explicit refutation (a fact that is now false, or was never true) uses Negates(), a soft conflict uses Dispute(), and a data-entry mistake (wrong value, accidental duplicate) is a forget. forget is a soft-retract: it removes the fact from reads while keeping it in the store for history. If you ever want a fact permanently deleted rather than hidden, that is a separate destructive action (loom_hard_delete), intended only for driver-level rollback, not normal updates. The agent applies the right one so your memory stays truthful without erasing your history.
Privacy-conscious memory is memory you can inspect and control. You decide what is remembered, who can read it, and you can always audit or remove it.
[loom_demo]; a separate store does not read them automatically, though anyone who holds access to [loom_demo] can.Two points keep personal memory private by default — with one honest caveat:
> Practice caveat: This tutorial deliberately saves personal facts into [loom_demo], which earlier tutorials also use for project material — it is a shared practice store, not a private one. In real use, keep personal facts in a store only you (and anyone you choose to share it with) can access, which is what makes store isolation actually protective.
Bring it together. In a fresh session, ask the agent to work from memory it has never seen in this conversation.
If a personal fact does not surface when you expect it:
Supersedes()d the one you expect (or Negates()/Dispute()d it if it was explicitly refuted). Query the current state to see what is actually live.forget removes the fact from reads.Loom as a personal assistant is the same memory system you already know, pointed at your life: save preferences, constraints, and plans as durable facts; let right-time retrieval surface them when a decision is being made; correct with Supersedes() when your situation changes, Negates()/Dispute() when a fact is explicitly refuted, and forget only genuine data errors; and rely on store isolation + your own control for privacy. You decide what is remembered, and you can always audit, supersede, or remove it.