This tutorial shows how durmem brings relevant project context into a fresh session. Save a few durable facts, close the session, and see the next session use them without a reminder.
You need a working durmem connection and the loom-coding skill. If either is missing, complete the Quickstart and Tutorial 00 first.
durmem practice notebook, the same one the Quickstart used. It lives in the practice store loom_demo.Tutorial 04 explains types and labels in more depth. You do not need it for this exercise.
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.> Illustrative agent output: loom_demo is now the default for this session. Persistent configuration was not changed.
Give the agent a few facts that should survive the conversation:
loom_demo, remember these facts for the project durmem practice notebook; create the project if it does not exist yet. Our Goal is to ship a private beta by September 30. Add a Roadmap item to finish invitation emails before the beta. We decided to send those emails through the existing notification service, using dev1@gmail.com as sample payload content. Treat the deadline as critical. The sample address is not an author identity.loom-coding to check the current project context, classify the statements, and save a Goal, a Roadmap item, and a Decision with the requested importance under the project.> Illustrative agent output: Saved three memories for durmem practice notebook: the critical September 30 beta Goal, the invitation-email Roadmap item, and the Decision to use the existing notification service. I will treat them as context for this project in later sessions.
If the agent cannot tell you which project and store it used, stop and fix that first. Ask it to show both, correct the problem, and repeat this step. Do not accept a vague confirmation that leaves out the three fact types.
Ask the agent to summarize what it kept before ending the session:
> Illustrative agent output: Goal: ship the private beta by September 30 (critical). Roadmap: finish invitation emails before the beta. Decision: use the existing notification service, with dev1@gmail.com as sample payload content, not an author identity. A standing instruction belongs in a Directive.
If the agent collapses everything into one note, ask it to correct the memory into separate Goal, Roadmap, and Decision facts. Continue only when all three appear and the agent names Directive as the type for a standing instruction.
Close this coding-harness session completely. Start a new session without copying the earlier prompt or naming any of the saved facts. Name only the store and the project, so the new session reads the same memory:
loom_demo for this session. Then help me choose the most important work to do next for the project durmem practice notebook.loom_demo and reads the project's durable context before recommending work. The critical Goal, its Roadmap item, and the related Decision surface because they belong to this project and match a planning request.> Illustrative agent output: The private beta deadline is September 30 and is marked critical. The clearest next step is the unfinished invitation-email Roadmap item. The existing Decision says to build it on the notification service, so I would start by tracing that integration rather than choosing a new delivery path.
The new session used the saved context without a pasted summary or a reminder.
If the response ignores the saved context, stop before planning. Ask the agent to confirm that loom-coding is active, that the project durmem practice notebook exists, and that loom_demo is connected. Fix whichever check fails, open another fresh session, and try the same neutral prompt again.
You steer recall by naming the project, the topic, and which kinds of facts should lead. In another fresh session, steer toward delivery mechanics rather than the deadline:
loom_demo for this session. For this task, prioritize invitation-email architecture for the project durmem practice notebook. Surface the most relevant Decisions and Roadmap context first; leave unrelated Goals in the background unless they change the recommendation.> Illustrative agent output: The controlling Decision is to use the existing notification service. The relevant Roadmap item is to finish invitation emails before beta. The September 30 Goal supplies urgency, but the architecture should follow the existing service decision.
If unrelated memories dominate, narrow the instruction: name the project, the topic, and which fact types should lead. If too little surfaces, broaden the topic or ask the agent to include supporting Goals.
This is a practice step: nothing is delivered. A Roadmap item has at most one status at a time, so the agent adds a status if the item has none, and otherwise replaces the status it read with the new one in a single step, never deleting and re-adding it. The earlier history stays:
loom_demo for this session. Practice only: pretend the invitation emails have shipped. In the project durmem practice notebook, mark that Roadmap item done and set its priority to normal, preserving its history. Keep the September 30 Goal critical. Do not let the example address influence production configuration.done. Otherwise it replaces the status it read with done in one atomic change, then reads the item back to confirm it has exactly one status and normal priority.> Illustrative agent output: The invitation-email Roadmap item is now done, with normal priority, and its history is preserved. The beta Goal remains critical. The example address stays documentation context only.
If the agent proposes deleting history just to stop an item from surfacing, stop and restate what you want: keep the record, and change its status or priority instead.