Tutorial 01: Build your first memory in five minutes

This tutorial demonstrates Loom's core value: the right project context resurfaces when it matters, even in a fresh session. You will save a few durable facts, close the session, and watch the next session use them without a reminder.

You need a working Loom connection and the loom-coding skill. If either is missing, complete Tutorial 00: Connect your coding harness to Loom first.

To keep this first win short, the exercise uses the seeded Project("loom_demo") scope already present in [loom_demo]. Tutorial 03 later builds the repository-specific palmerpenguins scope chain.

Start here: make `loom_demo` the session default

YouLoad the configured store named loom_demo and make it the default for this session only. Confirm the effective session default, and do not edit ~/.loom/stores.toml.

AgentThe agent connects to the existing loom_demo store and changes only this session's default routing.

Resultloom_demo is now the default for this session. Persistent configuration was not changed.

1. Save a useful project snapshot

Give the agent a few facts that should survive the conversation:

YouIn [loom_demo], remember these facts for the seeded Project("loom_demo"). 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.

AgentThe agent uses 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 seeded project scope.

ResultSaved three memories scoped to Project("loom_demo"): 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 identify Project("loom_demo") or the target store, stop and fix that first. Ask it to show the project scope and store it intends to use, correct the configuration, and repeat this step. Do not accept a vague confirmation that omits the three fact types.

2. Check that the memories are distinct

Ask the agent to summarize what it retained before ending the session:

YouShow the project memories you just saved, grouped by type. Also tell me what kind of fact I would use for a standing instruction that must always be followed.

AgentThe agent reads the current project memory, groups the new facts by their meaning, and explains the remaining type without creating another fact.

ResultGoal: 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 author identity. A standing instruction belongs in a Directive.

If the agent collapses everything into one note, stop and ask it to correct the memory into separate Goal, Roadmap, and Decision facts. Continue only when all three appear and the agent identifies Directive as the type for a standing instruction.

3. Recall the memories in a fresh session

Close this coding-harness session completely. Start a new Claude Code or Codex session without copying the earlier prompt or naming any of the saved facts. Explicitly connect to [loom_demo] and name only the seeded project scope so the new session reads the same tutorial memory:

YouConnect to [loom_demo] and use it for this session. Then help me choose the most important work to do next for Project("loom_demo").

AgentThe agent loads [loom_demo], confirms the connection, and reads the project's relevant durable context before recommending work. The critical Goal, its Roadmap item, and the related Decision surface because they match the project scope and planning request.

ResultThe 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 implement it through the notification service, so I would start by tracing that integration rather than choosing a new delivery path.

That is the first win: the new session did not need a pasted summary or a reminder to search for the deadline. The context appeared when the work called for it.

If the response ignores the saved context, stop before planning. Ask the agent to confirm that loom-coding is active, that Project("loom_demo") exists, and that the expected memory store is available. Correct whichever check fails, open another fresh session, and try the same neutral planning prompt again.

4. Aim what surfaces

You control recall by giving memories meaningful importance and scope, and by telling the agent what topic should lead the current task. In another fresh session, steer toward delivery mechanics rather than the deadline:

YouFor this task, prioritize invitation-email architecture for Project("loom_demo"). Surface the most relevant Decisions and Roadmap context first; leave unrelated Goals in the background unless they change the recommendation.

AgentThe agent prioritizes project-scoped memory about invitation emails. It leads with the Decision and Roadmap item, while using the beta Goal only as supporting context.

ResultThe 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 recommendation should follow the existing service decision.

If unrelated memories dominate, make the instruction narrower: name the project scope, the topic, and which fact types should lead. If too little surfaces, broaden the topic or ask the agent to include supporting Goals as well as Decisions and Roadmap items.

5. Change the controls when priorities change

Importance and scope are not permanent guesses. Tell the agent when a fact should become more prominent, narrower, or no longer guide current work:

YouKeep the September 30 Goal critical and scoped to Project("loom_demo"). Lower the invitation-email Roadmap item to normal priority after it ships, and do not let the example address influence production configuration.

AgentThe agent updates how the project context should be prioritized while preserving the historical Goal, Roadmap item, and Decision.

ResultThe beta Goal remains critical for Project("loom_demo"). After invitation emails ship, their Roadmap item will no longer lead normal planning. The example address remains documentation context only and will not be treated as production configuration.

If the agent proposes deleting history just to reduce surfacing, stop and restate the desired control: preserve the record, but change its current importance, scope, or status.

6. Takeaways

Loom carries typed project context across sessions; it is not just a conversation note.
Goals, Roadmap items, Decisions, and Directives serve different purposes.
A fresh session can use relevant memory without a pasted summary.
Importance and project scope help the right facts surface.
A task prompt can prioritize a topic and the fact types that should lead.
Continue to Tutorial 02: Connect to multiple stores to learn how memory stores are targeted safely. If the connection checks above failed, return to Tutorial 00: Connect your coding harness to Loom first.