dbtlr/mimir

description: Mimir work-state storage, installation, interfaces, and development entry points.
---
mimir
Mimir is a local-first source of truth for agent-driven work. It keeps projects,
tasks, dependencies, decisions, and work products in one queryable system so an
agent can act on current state and an operator can see what needs attention.
Work state lives in one local SQLite file by default, or in a shared
PostgreSQL database for agents on several machines. Mimir derives queues, status rollups, blockers, and stale work when queried;
there is no second cache of project status to keep in sync.
Why Mimir
- **One work model.** The CLI, MCP server, HTTP API, and operator console use the
same domain logic.
- **Agent-ready context.** Repository binding and mimir overview give an agent
the current direction, active work, ready queue, dependencies, and recent
sessions.
- **Operator control.** The console spans projects, tasks, Artifacts, Seeds, and
record health. It supports daily authoring and lifecycle actions.
- **Store ownership.** Choose a local SQLite file or a shared PostgreSQL
database. Both keep work state in one SQL store with transactional writes, and
mimir store export backs up either.
- **Derived state.** Rank, dependencies, lifecycle, and holds determine what is
ready, awaiting, blocked, stale, or complete.
What it handles
| Need | Mimir capability |
| --- | --- |
| Plan and run work | Project → initiative → phase → task hierarchy, ranked queues, dependencies, lifecycle, and holds |
| Preserve outcomes | Frozen, tagged Artifacts linked to the work that produced them |
| Keep temporary context | Resumable Scratchpads with a Journal and Agenda that freeze into Artifacts |
| Groom new work | Seeds for ideas, bugs, features, and cross-project requests |
| Resume agent sessions | Direction, execution handles, annotations, and session-summary Artifacts |
| Operate the store | Record diagnostics, backup by export, service management, and self-update |
Five-minute start
Install the standalone binary:
For an existing installation without a receipt, use the
legacy upgrade procedure.
Choose the store before setup:
- **SQLite (default):** Nothing to install. Mimir creates store.sqlite in its
data directory on first use. Run mimir setup to optionally install the
local service.
- **PostgreSQL:** Skip mimir setup. Follow the
Postgres store guide to set [store] backend
to "postgres" and url in the installation's bound config.toml, then run
mimir store upgrade. Run mimir serve directly or under your supervisor.
Optional mimir service install installs the serve unit (launchd on macOS,
systemd on Linux).
To move a Norn vault from an earlier release into SQLite or PostgreSQL, see
Moving from a Norn vault.
Then create a project and bind a repository to it:
From the bound repository, an agent can orient and begin the highest-ranked
ready task without repeating the project key:
Run mimir serve and open the URL printed at startup to use the operator