Tutorial 13: Use durmem for personal context

This is an optional personal-memory exercise, separate from the project-memory tutorials. It uses only fictional details so you can see how preferences and constraints may inform a later answer without putting anyone's private information into a shared coding example.

If you arrived from Tutorial 12, this is a separate optional branch, not a prerequisite for maintenance.

Before you start

Choose a store intended for personal context, configured with PersonalDomain and with access

limited to people you trust. The shared [loom_demo] used for coding practice is not a private personal store. If you do not have an appropriate store, stop here; do not switch the demo store's domain or put personal facts in it.

Select that store for this session without changing persistent configuration. A domain guides

how durmem captures and reads memory; it does not control who can access the store.

Use the fictional identity Alex Example below. This is a label for this exercise, not an

authenticated identity. Do not substitute a real email, address, health detail, or other sensitive information.

For store basics, see the overview and privacy guide. Review who has access to the selected store before using real personal information in any separate, approved activity.

1. Save one fictional preference

YouIn the personal-practice store selected for this session, remember this fictional preference for Alex Example: afternoon meetings are preferred when possible. Keep it separate from any project facts, and confirm which store and identity label you used.

AgentThe agent uses the store's PersonalDomain guidance and reads the selected store for a conflicting current preference before saving. It does not infer or authenticate a person's identity from the label.

Illustrative outputThe response identifies the fictional preference and the selected practice context. It is not proof that an actual record was saved unless the agent confirms that operation.

2. Ask in a fresh session

In a later session, select the same personal-practice store and ask a neutral question about Alex Example. The answer should be grounded in a current record from that store; if none is found, the agent should say so rather than pretend to remember.

YouFor Alex Example, what meeting time preference is recorded? Answer from current memory only and identify the record you used.

Memory may be supplied as context when a request is relevant, but surfacing depends on the selected store and the agent's active guidance. A label in one session does not make facts follow a person across accounts or stores.

3. Correct the fictional example

If you want to practice a change, first retrieve the exact preference. Then ask the agent to update only that fictional record to “morning meetings are preferred when possible,” preserve the earlier statement as history, and repeat the same read to verify the current preference. If the exact record is absent or ambiguous, make no change. A changed circumstance replaces an earlier state; an entry mistake is different and should not be treated as a normal update.

4. Keep the privacy boundary clear

Store isolation prevents automatic reads from another store; it is not an access-control

promise. Anyone with access to the selected store may be able to read its contents.

PersonalDomain affects capture and retrieval guidance, not credentials, sharing, encryption, or account permissions.
durmem may surface relevant context to an agent. It does not send notifications, book appointments, or run a schedule by itself.
Use real personal details only after confirming the store, access, and applicable policy.

Otherwise keep practicing with fictional data.

Takeaway

Personal memory can help an agent answer from selected, current context. Keep the store and fictional identity explicit, verify what is actually recorded, and do not confuse memory surfacing with authentication or autonomous action.