Loom keeps your agents on track.
Loom becomes more useful as your agents save decisions, plans, reminders, and results. Occasional maintenance keeps that memory organized without erasing its history. This tutorial shows the safe, conceptual workflow. The installed loom-maintenance skill contains the exact agent-facing mechanics; invoke it by name in your coding harness.
Start here: make loom_demo the session default
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. Audit store health
Ask for an audit before authorizing changes. Your agent should confirm which store holds the relevant memory, look for duplicate categories and contradictory facts, and distinguish active work from completed history.
AgentThe agent identifies the intended coding-memory store from its description, inspects only the relevant current records and history, and groups findings by the repair that would be needed. It does not treat age alone as evidence that something should be removed.
ResultAudit output varies with your store. Here are only findings I can cite by exact fact id and concrete type; no changes were made. If no duplicates, contradictions, noisy reminders, stale work, or incomplete plans are present, the corresponding section is empty.
Continue only with findings the agent can cite by exact fact id/type. The categories and counts in a real audit are not predetermined tutorial fixtures.
2. Apply a bounded repair
Review the proposed changes. A good repair consolidates only categories that truly represent the same kind, keeps the current fact and its history consistent, and leaves completed work as evidence while removing it from active views.
AgentThe agent applies the approved repairs in dependency order, recreates destination relationships when a store move is necessary, and verifies each repaired view against the audit inventory. It leaves ambiguous category candidates and awaiting-owner work unchanged.
ResultI applied only the cited, verified repairs from the audit and checked their current and historical views. Ambiguous findings were left unchanged. If the audit found no safe repair, I made no changes.
3. Complete plans with evidence
A plan should not merely vanish when the work finishes. Ask the agent to mark it complete and attach a separate receipt that points to the shipped artifact.
AgentThe agent resolves the exact Tutorial 08 Roadmap identity and verifies real repository evidence before advancing it. Only then does it record a separate delivery receipt and check both open-work and durable-history views; otherwise it reports why closure was skipped.
ResultThis result is conditional. With verified evidence, the exact Roadmap is complete, absent from open work, and linked to a delivery receipt containing the real branch, commit, and files. Without that evidence, it remains open and no receipt is invented.
4. Move memory deliberately
Store names are local handles, and there is no safe reason to guess one. Let the agent compare store descriptions, copy a bounded set in dependency order, verify it in the destination, and retire the source only after approval.
AgentThe agent compares the configured store descriptions, inventories the selected reminders and their relationships, and explains what must be recreated in the destination. It does not use an old server-migration runbook or expose connection material.
ResultIf a configured store description clearly fits personal reminders better, I can propose a bounded copy-and-verify plan that preserves their author, scope, subject, priority, and relationships. If no configured store clearly fits, I will not move them; create a dedicated store on Loom Cloud or leave them in place until you choose a destination. Nothing has moved or been retired.
5. Tune what resurfaces
If useful context appears too often or not often enough in one project, tune that project's surfacing sensitivity instead of changing the shared defaults for every project. Lower sensitivity cutoffs allow more borderline matches; higher cutoffs keep the surfaced set more selective.
AgentThe agent adjusts only this project's mount, validates the requested values against the mounted plan, and compares the two prompts. If the setting is malformed or stale, proactive guidance remains non-blocking and the agent reports the rejected setting instead of disrupting the session.
ResultPlanning context is now more selective in this project. The relevant planning request still surfaces the expected guidance, the off-topic request stays quiet, and projects that share the same underlying plan are unchanged.
6. Takeaways
- Audit first; do not treat old as wrong or completed history as clutter.
- Consolidate only categories that mean the same kind.
- Preserve older facts as history when a newer fact becomes current.
- Keep completed tasks out of active views without deleting their ledger.
- Finish a plan with a separate delivery receipt.
- Tune surfacing at one project mount before changing shared defaults.
- Use
loom-maintenance for exact maintenance mechanics and verification. - Continue to Tutorial 12: Audit and maintain your Loom store for a repeatable health-check routine.