mori (森)

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:

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗