Loom keeps your agents on track.
Loom memory grows with your work. A periodic health check keeps it easy to retrieve without treating history as clutter. This tutorial turns the maintenance ideas from Tutorial 11 into a repeatable, user-facing routine you can run in Claude Code or Codex.
The safe loop is simple: audit, decide, repair, verify. Start read-only, approve only the changes you understand, preserve history, and repeat the original read after every repair.
Start with the store you actually use
Store names vary by account, so do not guess from a folder name or from whichever store happens to be active. Ask the agent to identify your coding-memory store from the configured descriptions and confirm it before reading anything.
AgentThe agent reads the configured store descriptions, selects the store whose purpose matches coding memory, connects it for this session, and leaves the saved configuration unchanged.
ResultI loaded [coding] for this session because its description identifies it as your coding-memory store. I did not change persistent configuration.
The examples below use [coding]. Replace that name with the store your agent confirmed.
1. Establish a read-only health baseline
A health audit should answer bounded questions instead of dumping the whole store. Ask the agent to inspect the category hierarchy, sample suspicious groups, and report evidence before suggesting a repair.
AgentThe agent inventories the store's categories, then narrows into only the areas that look inconsistent. It distinguishes a genuinely duplicated kind from two categories that merely have similar names, and it treats age as context rather than proof that a record is stale.
ResultThe audit found one likely duplicate-category pair, two facts that appear to describe different current states, three records without project scope, one record attributed to an unexpected author, and one completed Roadmap item without delivery evidence. No changes were made.
Save this report until the repair is verified. It is your before-state.
2. Review category consolidation semantically
Similar names are only candidates. Two categories should be consolidated only when they represent the same reusable kind and their differences can be expressed as values rather than separate category names.
AgentThe agent samples the current records under each candidate, tests whether one broader category can represent all of them, and prepares a mapping that preserves content, relationships, and record identity where possible.
ResultBuildFailure and TestFailure can safely become one reusable Failure(kind) category because build, test, and deployment failures share the same record shape. Roadblocker should remain separate because it represents blocked work rather than a failed execution. I have not changed the store.
Approve only the mappings that make sense in your domain:
AgentThe agent performs the bounded consolidation, stops on any identity collision, and repeats the same inventory that exposed the duplicates.
ResultThe verified records now use Failure(kind) with their original identities and relationships preserved. The two replaced categories no longer appear as active category choices, and Roadblocker is unchanged.
3. Resolve stale and conflicting facts without erasing history
Two statements can both remain stored while only one represents the current state. Ask the agent to establish whether the newer statement directly negates, disputes, or simply replaces the older one. Different projects, dates, or people may mean there is no conflict at all.
AgentThe agent compares the bounded history and scope for each pair. It links the newer winner to the older record with the least aggressive relationship that accurately describes the change, rather than deleting either record.
ResultThe July decision supersedes the May design choice for this project, so it is now the only current answer. The older choice remains available in history. The other pair belongs to two different repositories, so I corrected its scope instead of inventing a contradiction.
Verify both views:
AgentThe agent repeats the original current-state reads and then inspects the bounded history for the same subjects.
ResultEach current-state read now returns one winner. The replaced May choice is absent from the current answer but remains visible in the historical trail with the reason it changed.
4. Check project scope and author hygiene
Scope keeps one project's facts from leaking into another. Author attribution tells a shared store who asserted a fact. Missing or incorrect values should be repaired from evidence, never guessed.
AgentThe agent compares each record with the repository's declared Loom scope and the expected Git author. It proposes narrow relationship corrections, reports ambiguity, and does not create a new project spelling to make the audit pass.
ResultTwo records can be safely attached to the existing repository and project scope. One record needs your decision because two workspaces are plausible. The masked expected author is dev1@gmail.com; no credentials or connection keys were read or displayed.
After you resolve any ambiguity, approve and verify the bounded repair:
AgentThe agent changes only the approved relationships, repeats the audit queries, and keeps the ambiguous record in the follow-up list.
ResultThe corrected records now appear only in the intended project and under the confirmed author. The ambiguous workspace assignment remains unchanged and is listed for follow-up.
5. Finish a Roadmap with a delivery receipt
A completed plan should leave two durable pieces of evidence: the original Roadmap marked done and a separate Deliverable receipt that names what shipped.
AgentThe agent verifies the repository evidence, advances the existing plan to done, records a separate delivery receipt, and connects the receipt to the plan it fulfills.
ResultThe existing Roadmap is now done. A separate Deliverable records branch main, the verified commit, changed files, passing tests, and the delivery date. The original plan identity and history were preserved.
Confirm both retrieval paths:
AgentThe agent checks the open-work view and separately retrieves the completed plan's receipt.
ResultThe completed item no longer appears among open Roadmap work. Its Deliverable receipt is independently retrievable with the requested evidence.
6. Retire stale work without deleting its ledger
Completed and cancelled Kanban tasks already leave active views. Old task events are the audit trail, not garbage. A task should be cancelled only by its owner, and a worker may release only its own run.
AgentThe agent checks current task and run state, dependencies, ownership, recent progress, and expiry information. It separates records that already left active views from work that needs an authorized owner decision.
ResultTwo completed tasks and one cancelled task are already absent from active views and need no cleanup. One task is awaiting its owner. One task owned by this conversation is stale and can be cancelled with your approval. No ledger records were deleted.
AgentThe owner conversation records the cancellation, rechecks active tasks, and verifies the immutable history separately.
ResultThe authorized stale task is cancelled and no longer appears as active. Its publish, claim, progress, and cancellation events remain available as history. The awaiting-owner task is unchanged.
7. Run the verification pass
Finish with the same dimensions you audited. A successful repair is not "the command returned without error"; it is a before-and-after result showing that the current view is cleaner and the historical view remains complete.
AgentThe agent repeats each bounded read, compares it with the saved baseline, and reports both the repaired current view and intentionally preserved history.
ResultVerification passed for the approved repairs: one duplicate-category pair was consolidated, two current-state conflicts were resolved, three scope/author relationships were corrected, one Roadmap was completed with a Deliverable receipt, and one owner-authorized stale task left active views. Historical records remain auditable. One ambiguous workspace assignment and one awaiting-owner task were intentionally left unchanged.
8. Make it a routine
Run a read-only audit after a large import, after changing your project hierarchy, when retrieval starts returning near-duplicates, or before a major release. Repair only what the evidence supports.
The reusable prompt is:
AgentThe agent follows the audit, decide, repair, verify loop and requests a decision wherever meaning or authority is ambiguous.
ResultI will begin read-only, propose only evidence-backed repairs, preserve history, and verify each approved change against the original audit.
9. Takeaways
- Confirm the intended store before auditing it.
- Audit first and keep the before-state until verification is complete.
- Consolidate categories by shared meaning, not similar spelling.
- Keep one current fact while preserving older facts as history.
- Repair scope and author attribution from repository evidence; never guess.
- Complete a Roadmap with a separate, evidence-rich Deliverable receipt.
- Remove stale work from active views through the proper owner action, not by deleting its ledger.
- Repeat the same reads after every repair and report what you intentionally left unchanged.