Mnemos Integration

Mnemos Integration

Harness integrates Mnemos — the memory engine that never forgets — as its semantic knowledge core. Mnemos is what gives Harness its memory: it remembers every conversation, decision, and preference, building a living model of you over time.

../mnemos/ currently contains the memory engine implementation surface:

  • KnowledgeStore seam
  • KRecord schema and codec
  • write-confirmation contract
  • in-memory and fault stores
  • index glue for FTS, tags, and refs
  • curator protocol
  • .agents adapter
  • engine core and smoke modules

kernel/ owns Kratos — the operational authority. mnemos/ owns knowledge semantics. Mnemos remembers. Kratos decides.

Global and Project Knowledge

Mnemos distinguishes global knowledge from project knowledge.

Global knowledge lives under the resolved Agent Home:

$AGENTS_HOME/mnemos/
${XDG_CONFIG_HOME:-$HOME/.config}/agents/mnemos/

This is the place for overall knowledge extracted after dream curation: cross-workspace lessons, reusable patterns, stable operator preferences, and shared tool semantics.

Create this global scope explicitly with:

mnemos memory init-global
mnemos memory init-global --home /path/to/AgentHome
mnemos memory status

Project knowledge lives under the project authority root:

PROJECT/harness/knowledge/
PROJECT/.agents/knowledge/     legacy fallback

This is the place for project-only LMX knowledge: local specs, decisions, reports, workgraph memory, source references, and session lessons. knowledge/memory.toml declares scope = "project" and promotion_policy = "explicit" so promotion into Agent Home remains deliberate.

Create or inspect this project scope with:

mnemos memory init-project
mnemos memory init-project --project PROJECT
mnemos memory status --project PROJECT
mnemos memory policy check --project PROJECT
mnemos workgraph import-plans --project PROJECT --dry-run
mnemos memory mcp-config --project PROJECT

Project aliases created by mnemos init --name NAME select the project scope first. A workspace can therefore expose a command like voxis while another exposes research-forge; both call the canonical mnemos binary, but each defaults to its own project memory.

When PROJECT/harness/ exists, init writes project identity and memory scaffold there. Otherwise it uses legacy PROJECT/.agents/. The generated harness.toml records the authority root, project memory root, and agent-home:mnemos global memory root.

mnemos doctor reports the initialized display name, local CLI alias, alias shim state, and authority root so the operator can see which project context a workspace-local command selects.

Generated alias shims pin that context by changing into the initialized project root before invoking mnemos.

Project memory does not silently become global memory. Promotion into Agent Home knowledge requires an explicit dream export or policy-approved consolidation flow.

WorkGraph and MCP Bridge

mnemos workgraph import-plans is dry-run by default in v0. It parses the authority PLANS.md, reports section/task/status counts, and writes no database state. The Markdown file remains source of truth.

mnemos memory policy check verifies that the project memory policy exists, contains record/exclusion sections, and names the required default exclusions before ingestion workflows rely on it.

mnemos memory mcp-config emits a project-scoped MCP configuration snippet for the Mnemos knowledge tools. The snippet includes knowledge.query and knowledge.index, but uses an empty env object; operators provide secrets or provider configuration through their normal runtime, never through generated snippets.

The bridge path is staged:

  1. v0 production memory uses SQLite tables and FTS5 for operational data.
  2. Janus Mnemos runs experimentally or in shadow mode.
  3. Conformance fixtures compare Kratos behavior with Janus results.
  4. Passing modules graduate toward candidate/default status.

This lets Harness generate Janus compiler gaps without turning those gaps into production outages.