Open-Source Governance Tools for AI Coding Agents

Category map

"AI coding agent governance" is not one category. It is separating into four layers, and tools in different layers are not substitutes for each other. Context and memory systems determine what an agent knows. Architecture discovery tools describe what the system looks like. Runtime governance decides which commands and tool calls may execute. Architectural governance decides whether a generated change respects the decisions the team already made. Most recommendation lists mix all four, which is why they produce confusing shortlists.

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 four layers

Sorting the field by what each tool governs makes the shortlist obvious, because most of the confusion comes from comparing tools that were never alternatives:

Layer	Examples	What it governs
Context and memory	OpenViking, Letta, MemClaw	What the agent knows
Architecture discovery	RepoSwarm	What the system looks like
Runtime and tool governance	Knox	Which commands and tool calls may execute
Architectural governance	Mneme	Whether a change respects architectural intent

The runtime layer is the newest of the four and the one growing fastest. It is also where the term "AI coding agent governance" is being used commercially: Endor Labs now markets under exactly that phrase, governing shell commands, file access, MCP tool calls and prompt injection from a security posture rather than an architectural one. That is a real category forming, not a phrase Mneme invented.

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
Knox	Runtime governance layer that intercepts agent tool calls before execution	Allow / review / block pipeline on every tool call; safe actions run, risky ones pause for approval, dangerous ones are blocked; immutable audit log. Works with Claude Code, Cursor, Codex and Aider	Yes — at the tool-call layer, not the architectural one
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

That last column is the finding, and it is more interesting than a straight yes or no. The four memory and documentation projects do not attempt enforcement at all. Knox does enforce, deterministically and with an audit trail, but on a different object: it governs whether a command or tool call is permitted to run, not whether the resulting code respects an architectural decision.

Knox will stop an agent running rm -rf or reading a credentials file. It will not stop an agent introducing a direct database call in a component that architecture says must go through the repository layer, because that is a legal tool call producing legal code. Both are enforcement. They are enforcing different things.

Where Mneme fits

Mneme occupies the fourth layer. 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 everything above rather than a substitute for any of it. A mature setup could reasonably run Letta or OpenViking for context, RepoSwarm for architecture documentation, Knox for runtime tool safety, and Mneme for architectural compliance. Four layers, four different questions, and no reason a team should have to pick one.

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 runtime governance (Knox) when the failure mode is an agent executing something it should not have been allowed to run at all.
Choose architectural governance (Mneme) when the failure mode is not that the agent lacked context or ran a dangerous command, but that it had the context and still produced code that violates a decision the team already made.

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.

Frequently asked questions

What is context governance for AI coding agents?

Context governance is the umbrella term for keeping AI coding agents aligned with a project's memory, rules, and architecture as they generate code. It splits into two different jobs that are often conflated: giving the agent the right information (memory, retrieval, instructions) and constraining what the agent is allowed to do with it (deterministic enforcement). Most open-source tools in this space do the first. Very few do the second.

Is AI agent memory the same as governance?

No. Memory and retrieval systems, such as a virtual filesystem of past context or a git-backed history of what an agent has learned, improve what an agent knows when it starts a task. They do not evaluate the action the agent is about to take against a rule and block it if it violates one. A tool can have excellent memory and zero enforcement, which is the case for every memory-focused project in the comparison below.

Can coding agents be forced to follow ADRs?

Only by a layer that evaluates a proposed change against the ADR's scope and constraint, and returns a verdict before the change lands. Putting an ADR in a retrieval index or an instruction file makes it available to the agent; it does not make it binding. Forcing compliance requires the constraint to be checked at the point of action, independent of whether the agent chose to consult the ADR.

Are CLAUDE.md and AGENTS.md sufficient for governance?

They are a necessary and insufficient first layer. Instruction files communicate intent cheaply and are genuinely useful for onboarding an agent to a codebase. Their effect on a specific implementation depends on the file being loaded, the relevant section reaching active context, surviving whatever context compaction the harness performs, being interpreted correctly, and the model then choosing to comply. That is a long chain with no guarantee at the end of it, which is why instruction files sit at the availability layer rather than the enforcement layer.

What open-source tools provide architectural guardrails for coding agents?

It depends which layer you mean. OpenViking, Letta's Context Repositories, RepoSwarm and MemClaw are memory, retrieval and documentation systems, and none of them enforce architectural rules. Knox does enforce, with an allow/review/block pipeline over agent tool calls and an immutable audit log, but it governs whether a command may execute rather than whether the resulting code respects an architectural decision. Mneme is built for that last layer: it evaluates a proposed change against a decision corpus and returns a deterministic verdict. The layers are complementary, so the useful question is which one your failure mode sits in.

Explore AI coding agent governance

The layers above in depth, and the evidence underneath them.

Architectural Governance	The mechanism that turns decisions into machine-evaluable constraints.
Architectural Drift Prevention	The discipline this category map sits inside, and its eight-step lifecycle.
Executable Architectural Intent	What a decision needs before it can function as a control.
Autonomous Software Engineering Governance	Governing agents that operate without a person initiating each action.
RAG vs Governance	Why retrieval and enforcement are different layers, in detail.
Memory Is Not Governance	Recall and enforcement optimise for different things.
How AI Coding Agents Use ADRs	What happens to a decision record once an agent reads it.
Architecture Cannot Be a Prompt	COMPINT: compactors retain only 17% of standing constraints.
Governance Benchmark	How the enforcement claims are measured.
Live Governance Demo	A violation attempted and blocked, end to end.