Context governance for AI coding agents splits into two different jobs: retrieval and enforcement. Retrieval determines what an agent knows before it acts. Enforcement determines what it is allowed to do. The open-source projects most commonly recommended for repo-native "governance," OpenViking, Letta's Context Repositories, RepoSwarm, and MemClaw, are strong at the first job and do not attempt the second. That is not a criticism; it is a scope boundary worth being explicit about before choosing a tool.
Context governance is not one thing
The phrase gets used to cover a wide range of mechanisms: a filesystem an agent can browse, a git-tracked memory that survives across sessions, generated architecture documentation, a workspace that isolates one project's context from another's, a rules file, a retrieval index, and a layer that blocks a prohibited file edit before it happens. These are not interchangeable, and treating them as one category is why "AI coding agent governance" searches surface tools that solve completely different problems.
A useful way to sort them is by what they actually guarantee:
| Layer | Question it answers | Guarantee |
|---|---|---|
| Memory / retrieval | What does the agent already know? | Probabilistic — the right context may or may not surface |
| Instructions (CLAUDE.md, AGENTS.md) | What should the agent be told? | Probabilistic — depends on the model reading and complying |
| Architecture documentation | What does this system look like? | Descriptive — informs, does not constrain |
| Deterministic enforcement | Is this specific action allowed? | Guaranteed — same input, same verdict, every time |
Every tool below is genuinely useful at the layer it targets. None of them cross into the fourth row, and knowing that in advance saves an evaluation cycle.
The open-source landscape
Four projects come up repeatedly when engineers search for open-source, repo-native alternatives to a generic vector database for agent context. Verified against each project's own repository rather than inferred from a search summary:
| Project | What it actually does | Mechanism | Enforcement? |
|---|---|---|---|
| OpenViking | Self-evolving context database unifying agent memory, retrieval, and skills | Virtual filesystem under a viking:// protocol; three-tier (L0/L1/L2) hierarchical loading; agent browses context with ls/tree/find instead of a vector query |
No — retrieval and organization only |
| Letta Context Repositories | Git-backed memory for coding agents, versioned like code | Agent context stored as local files under git; progressive disclosure by reorganizing the file hierarchy; multi-agent collaboration through standard git operations | No — permission modes exist for tool-call approval, not architectural rule checking |
| RepoSwarm | Multi-repo architecture discovery and documentation generation | Analyzes a repo portfolio and generates standardized .arch.md files per repository as agent context and onboarding material |
No — produces documentation, not a checkable constraint |
| MemClaw | Persistent, project-isolated memory with a review dashboard | One workspace per project to prevent context bleed between projects; MCP-native; web dashboard to inspect what an agent remembers | No — storage and visibility, not a policy layer |
Read literally, that last column is the whole finding. Every project solves a real problem, and none of them solve the one this page is titled after. That is not a gap in the research; it is the shape of the current open-source landscape.
Where Mneme fits
Mneme occupies the row the table above leaves empty. It keeps architectural decisions in a durable corpus outside the agent's conversation, selects the ones applicable to a specific change, and evaluates a proposed edit against them deterministically before it lands, guide, warn, or block, with the same input producing the same verdict on every run.
That makes it complementary to the four projects above rather than a substitute for any of them. A team could reasonably run OpenViking or Letta for context and memory, RepoSwarm for architecture documentation, and Mneme for the enforcement layer none of the others attempt. They answer different questions.
The distinction that matters: retrieval determines what an agent knows. Enforcement determines what it is allowed to do. A tool can excel at the first and still let a violation through, because knowing a rule and being prevented from breaking it are different system properties.
How to choose
- Choose a memory or retrieval system (OpenViking, Letta) when the problem is an agent forgetting prior context between sessions, or needing to browse a large project's history efficiently.
- Choose architecture documentation (RepoSwarm) when the problem is onboarding agents, or humans, to an unfamiliar or sprawling multi-repo codebase.
- Choose isolated project memory (MemClaw) when multiple projects share an agent and context bleed between them is the failure mode.
- Choose deterministic enforcement (Mneme) when the failure mode is not that the agent lacked context, but that it had the context and violated the decision anyway.
That last case is more common than it sounds. Research on context compaction has found standing constraints retained at low rates even while the surrounding task survives intact, which means a rule can be available at the start of a session and gone by the time it matters. Availability is not the same property as enforcement, and no amount of better retrieval closes that gap on its own.
What "architectural governance" specifically requires
Executable architectural intent is the slice of project knowledge that has been promoted from documentation into a form something can evaluate: a decision, the paths or constructs it governs, and the constraint that follows. None of the four memory-focused projects above produce that artifact, because producing it was never their goal. It is worth stating plainly rather than implying by omission, since the gap is exactly what makes the category interesting.