Mnemosyne

Mnemosyne — SAGE Memory Custodian

Overview

Mnemosyne is the repeatable memory-curation workflow for any project using WrongStack SAGE memory. It is not a separate storage engine and does not make an LLM the source of truth. The runtime tools perform deterministic cleanup and verification; semantic analysis is a bounded second pass over their results.

WrongStack discovers this bundled skill at boot. Every prompt mode receives its name and trigger. Eager mode may inject this body directly; progressive mode loads it through the skill tool. The detailed execution prompt is bundled as instructions/agent-prompt.md and should be loaded before a deep review.

Runtime Contract

Use only surfaces that are actually registered in the current session:

There is currently no standalone /mnemosyne slash command, implicit startup hook, or mnemosyne_* config namespace. Do not claim that one exists. Users can ask for a “Mnemosyne review”, load it explicitly with /skill mnemosyne, or use the existing /memory hygiene, /memory verify, and /memory candidates surfaces.

Workflow

1. Deterministic hygiene

Start every cycle with:

memory_hygiene({ verify: true })

Capture the returned counts. This phase may deduplicate, mark stale anchors, supersede obsolete versions, and create review candidates. It must not delete or archive memories. Treat non-zero deleted or archived counters as a bug.

Run memory_verify separately only when you need a targeted re-check or when hygiene could not complete verification.

2. Bounded semantic review

Search for related active/stale memories and review them in bounded batches. For the detailed review workflow, load:

skill({ name: "mnemosyne", resource: "instructions/agent-prompt.md" })

Evaluate:

1. Contradictions between memories.
2. Duplicate or mergeable facts missed by exact matching.
3. Vague, transient, or low-value entries.
4. Incorrect kind, scope, importance, or confidence.
5. Drift between anchored code and the memory claim.

Do not infer that a missing search result means a memory does not exist. Keep batch sizes and LLM calls bounded, and leave unchanged memories untouched.

3. Apply safe corrections

Direct updates are allowed only for non-terminal corrections:

• Fix inaccurate text when current project evidence is clear.
• Correct kind, scope, importance, or confidence.
• Mark a contradicted or invalid entry stale.
• Link superseding/contradicting memories or mark a duplicate superseded.

For deletion or archival recommendations, file a proposal:

memory_candidates({
  action: "propose",
  text: "Concise review finding",
  memory_id: "mem_target",
  reason: "Why this memory needs user review",
  suggested_action: "delete" | "archive" | "investigate"
})

Never trigger memory_delete, never set status: "deleted", and never set status: "archived" as part of an autonomous Mnemosyne cycle. The user owns the later memory_candidates({ action: "resolve", ... }) decision.

4. Report

Return a concise report containing:

• Trigger (on_demand or cron).
• Examined, deduplicated, verified, staled, and superseded counts.
• Semantic findings and safe corrections applied.
• Review proposals filed, grouped by suggested action.
• Errors or skipped checks.

Broadcast the report only when a mailbox tool is registered and coordination is active. Never invent a successful broadcast or scheduled cycle.

Optional Recurrence

Recurring curation is explicitly opt-in and session-scoped. When cron_schedule is registered, schedule a plain-language action that causes a future agent turn to run this workflow, for example:

cron_schedule({
  name: "mnemosyne-review",
  intervalMs: 21600000,
  action: "Run the bundled mnemosyne workflow: deterministic hygiene first, then bounded semantic review, propose-only for delete/archive."
})

Do not describe this as a persistent daemon: cron jobs belong to the live runtime and must be inspected or cancelled through the cron tools. If those tools are absent, run on demand instead.