Mori (森) — a governed shared-memory layer for AI coding agents.
Mori gives an agent provenance-scoped memory: the decisions and patterns a human chose to
keep, surfaced to every session — and only where they apply. It's the institutional memory
your agents pull from, self-hosted and agent-neutral, so the knowledge outlives whichever
model you're using this year.
What it doesn't do — and I tested this at length — is control what an agent does. No memory
layer can. Across a multi-model, multi-harness stress test (5,000+ runs, a dozen models),
the most capable coding model broke the build every time; the same model did the right
thing, then the wrong thing, on identical input; and an agent handed a tool that flagged its
own change as build-breaking read the warning and shipped the break anyway. Capability
doesn't fix this, and neither does better retrieval. What holds is enforcement at a boundary
the agent can't reach — and that's a separate piece of work.
📄 The research behind this — the Promotion-Boundary Governance Framework: what can and
can't actually be enforced on an AI coding agent, every null, every retraction.
Read the whitepaper →
Why use mori?
You're right to be sceptical of "memory systems" — most are a vector DB with a retrieval
prompt bolted on. So I ran the experiments, published the nulls, and lead with the result
that held up.
The failure mode mori fixes is cross-contamination. Curation decides what to keep;
provenance decides where it's valid — and across a team's many repos that's the line
between a shared brain and a liability. A memory that's true in one repo, surfaced while you
work another, makes the agent confidently reach for an API that doesn't exist here —
retrieval interference. I reproduced it and the fix: with out-of-scope memory in the brief,
agents chased phantom APIs in 20/20 runs; with provenance-safe scoping (MORI_BRIEF_SCOPE,
on by default), 0/20 — across two independent frontier-class models (Fisher p ≈ 0). The
memory was deliberately seeded from a prior repo, so it's a stress test of what canon-drift
does over months, not a natural-incidence rate — but the mechanism is clean and
model-independent. Ungated memory isn't shared memory — it's cross-contamination.
The other failure mode is obedience — and it's where mori is going, not where it is today.
Provenance fixes what an agent knows; it doesn't fix what an agent does. In a pre-registered
cross-repo benchmark, I gave frontier agents a tool to see downstream impact and a
plain-language warning that a change would break a build — and they broke it anyway, 15/15,
across four models and three harnesses. Information without enforcement is fatal — you cannot
govern an enterprise in token-space. That result is the thesis behind mori's next layer:
governed playbooks — a deterministic, pre-compute gate that checks a repo's lockfiles
against human-approved patterns and refuses an unsafe migration before it runs, independent
of prompt wording or model obedience. (Scope: pre-registered npm-dependency migrations; the
gate is built and benchmarked, not yet a shipped product surface — I lead with what I
proved, not what I hope. The full argument is the whitepaper.)
Multi-Instance Visibility
If you run AI coding agents across multiple machines, profiles, or in a team — one focused on the API layer, another on the frontend, a third on infrastructure — you already know the problem: each instance is brilliant in isolation, but none of them know what the others decided.
Instance B doesn't know that Instance A just changed the auth contract. Instance C
doesn't know that Instance B's deployment assumptions shifted. They find out the
hard way, mid-task, when something breaks.
Mori gives every instance the same shared picture. Every coding agent instance sends
its session events to the shared Mori server; the dream pipeline distils those events from
all instances into a unified memory store, and /brief surfaces them at the start of
any session. Be clear about what that buys, though: a shared picture is visibility, not
coherence you can bank on. Surfacing what Instance A decided does not make Instance B act
on it — a coding agent can read another instance's change and proceed against it anyway (I
measured exactly that, 15/15). So this is real value for a cooperative team — everyone
opens a session knowing what the others changed — but it is awareness, not enforcement.
Making one instance actually honour another's decision is the enforcement problem, and where
it can be solved at all it's solved at the promotion boundary on the committed artifact —
not by what any session was shown.
Quickstart
1. Deploy your server
Every Mori instance is yours — deployed into your own account, never shared.
Pick a path:
Cloud — deploy into your own account:
This is the beginning of the README. Read the rest at the original. Read the full README ↗
