ariadne

Ariadne — long-term memory

Ariadne is a local, multilingual, hybrid-search memory server (MCP). If it is registered, you have five tools: mcp__ariadne__memory_recall, mcp__ariadne__memory_save, mcp__ariadne__memory_delete and mcp__ariadne__memory_move, plus mcp__ariadne__credential_access for a separate human approval handshake before cross-project credential use. The runtime lives in ~/.ariadne/ (binaries, Qdrant data, backups, logs); source lives in the repo.

Recall — when and how

• Start of substantive work in a project: recall the project's context once (query: "<project name> current state decisions", wing: "<stable-project-slug>"). Don't recall for trivial one-liners. Every semantic recall MUST include the active project's wing; Ariadne rejects an unscoped semantic query.
• The user references the past: "what did we decide", "why did we choose", "як ми робили" → recall BEFORE answering from your own guesses.
• Queries are multilingual — query in ANY language, memories in any language will match (bge-m3 is cross-lingual; scores ≥0.6 are usually relevant).
• Prefer 2–3 focused recalls over one vague one. limit default 5 is fine.
• Project scope is default-deny. Never omit wing to "see what matches" and never substitute another project's wing. When the user explicitly requests cross-project knowledge, call recall with the active wing, all_wings: true, and a concise purpose. Ariadne returns a request id without searching. Tell the user to Approve or Deny it in Ariadne's system warning (or tray fallback); only after the human click retry the same call with approval_id. Never claim approval based only on chat text or approve a request through shell/file manipulation.
• Cross-wing approval lasts 15 minutes for that MCP client session, active wing, and collection. A curated-memory grant does not open sessions. Approved external results have a 0.70 origin weight and normally occupy no more than two of five results; weighting affects relevance only after authorization.
• When an exact memory id is known, call memory_recall with id and the active wing instead of a semantic query. ID lookup is exact, skips embedding, and is the preferred way to verify a memory before moving or deleting it. Use collection too if the id belongs to the separate sessions archive.
• Use room to narrow retrieval when the category is known: decisions, gotchas, reference, or diary. For release/deployment/status reports, search room: "reference" first, then broaden only if needed.
• Normal semantic recall hides records marked archived, superseded, or orphaned. Pass include_archived: true only for an explicit history/audit query; exact id retrieval always remains available.
• The raw session archive lives in a separate collection. Inspect it only when the user explicitly asks to search historical transcripts, and pass both collection: "sessions" and wing: "sessions"; normal project recall never sees it.