Two Engines: Mnemos & Kratos

Harness Architecture

Harness is a personal AI assistant powered by two engines: Mnemos (the memory engine that never forgets) and Kratos (the decision engine that keeps you sovereign). Together they orchestrate your private and business life — one assistant, all of you.

The v0 split is:

CLI / TUI / Web UI / extensions
        |
        v
Kratos — the Decision & Authority Engine
        |
        +-- SQLite operational state
        +-- local workspaces and worktrees
        +-- brokered extension runtimes
        +-- supervised Janus semantic modules

Kratos owns authority. It decides policy, approvals, secrets, process spawning, filesystem access, network egress, worktree mutation, audit records, and event emission. Mnemos remembers — Kratos acts.

The Janus Mnemos engine in ../mnemos/ owns the knowledge substrate and the future semantic ascent path. It does not own v0 authority.

Identity and Local Aliases

mnemos is the canonical installed CLI. A project can also be initialized with its own operator-facing name:

mnemos init --project PROJECT --name "Voxis Forge"

Initialization writes private project identity under the project authority surface and creates a local shim such as:

PROJECT/.mnemos/bin/voxis-forge -> mnemos

It also creates the project memory scaffold under the selected authority root:

PROJECT/harness/knowledge/lmx       preferred when harness/ exists
PROJECT/harness/knowledge/ledger
PROJECT/harness/knowledge/exports
PROJECT/harness/knowledge/memory.toml

PROJECT/.agents/knowledge/lmx       legacy fallback
PROJECT/.agents/knowledge/ledger
PROJECT/.agents/knowledge/exports
PROJECT/.agents/knowledge/memory.toml

The alias is not a separate product binary. It selects the initialized project context so different workspaces can expose distinct names and distinct project-only memory. The generated shim changes into the initialized project root before dispatching to mnemos, so the alias keeps its project context even when invoked from another directory.

Memory Scopes

Mnemos has two memory scopes:

Agent Home Mnemos
  $AGENTS_HOME/mnemos/
  ${XDG_CONFIG_HOME:-$HOME/.config}/agents/mnemos/
  global dream-curated knowledge

Project Mnemos
  PROJECT/harness/knowledge/
  PROJECT/.agents/knowledge/     legacy fallback
  project-only LMX knowledge

The global Agent Home store is for overall knowledge extracted after dream curation: stable lessons, reusable patterns, operator preferences, and cross-workspace facts. Project stores are for local specs, decisions, reports, source references, and LMX knowledge that should not leak into another workspace by default.

Global Mnemos state is initialized explicitly:

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

Project init does not create or mutate global memory.

Promotion from project memory to global memory is explicit and policy-gated. There is no silent project-to-global export.

Distribution Surfaces

HARNESS/
  mnemos/    Janus Mnemos application layer (the memory engine)
  kernel/     Kratos authority implementation

Private project doctrine remains outside both distribution repos.

Reference Substrates

External harness projects are reference material unless a later audit promotes them. claude-code-harness-marketplace is mirrored as metadata under the private authority root and never installed by generic HARNESS init:

mnemos substrate snapshot-marketplace --project PROJECT
mnemos substrate snapshot-marketplace --project PROJECT --source marketplace.json
mnemos substrate status --project PROJECT

Claude plugin install commands may appear only in the generated Claude adapter. They are host-adapter affordances, not HARNESS core behavior.

harness-mem is reference/import only. Mnemos remains the memory substrate. When harness-mem is missing, mnemos substrate status and mnemos doctor report degraded optional reference availability, not a project failure.

The root Plans.md file is only a compatibility shim for tools that cannot yet read the authority plan path. Regenerate it with:

mnemos substrate sync-plans-shim --project PROJECT

v0 Nucleus

  • mnemos doctor reports topology and repo firewall state.
  • mnemos doctor reports initialized project identity: display name, local CLI alias, alias shim state, and authority root.
  • mnemos doctor reports global Agent Home Mnemos state and project memory scope state.
  • SQLite stores events and audit records.
  • mnemos run create -- COMMAND enforces command policy, then records non-interactive command runs.
  • mnemos workspace add/list records local Git workspace authority roots.
  • mnemos worktree create/list/destroy manages local Git worktrees under .worktrees/.
  • mnemos worktree review NAME_OR_ID --task TASK_ID marks a worktree review_ready only after task evidence passes.
  • mnemos policy check -- COMMAND evaluates v0 command policy and creates approvals for ask.
  • mnemos approvals list/approve/deny manages durable approval rows.
  • mnemos task create/list/evidence records task intent and policy-gated evidence runs.
  • Event and audit records are hash chained from the first slice.
  • Kratos initializes state and appends a daemon startup event.

Current Worktree Boundary

Workspace/worktree v0 is deliberately narrow: it registers a Git repository, creates a named worktree under .worktrees/, removes it through git worktree remove, records durable lifecycle rows, and emits lifecycle events.

Diff review, merge, and push remain future authority slices.