Where Mneme fits in a Warp workflow
Warp's strength is execution: an engineer issues intent, Warp orchestrates the agents, processes, and tool invocations that fulfill it. Agent Mode pushes that further — autonomous loops that read, plan, edit, and verify across many shells in parallel.
That orchestration is upstream of the file-write boundary. Mneme HQ enforces at the file-write boundary. The two compose: Warp coordinates how work happens; Mneme constrains what work is allowed to land in the codebase.
This is not a native Warp integration. Mneme does not have a Warp-specific hook. It governs the agents Warp runs — Claude Code via its PreToolUse hook, CI runs via mneme check, and any tool that writes to disk via the repo-level decision corpus.
What gets enforced regardless of how Warp executes
- ADRs and architectural decisions. Recorded in
.mneme/project_memory.json, enforced at every edit attempt — whether the edit originates from Warp Agent Mode, an interactive Claude Code session inside a Warp pane, or a CLI tool a Warp workflow spawned. - Forbidden dependencies and approved patterns. Catalogued as anti-patterns and constraints; surfaced as feedback when an agent attempts a violating edit.
- Path and boundary rules. Module-level constraints (e.g. "no direct database access from controllers") that hold regardless of which session produced the diff.
- The CI gate.
mneme checkruns against every PR diff in GitHub Actions or GitLab CI — the final line of defense after generation, independent of which terminal launched the work.
The seam: Warp orchestrates, Mneme governs
Warp Agent Mode coordinates parallel agents in dedicated panes. Each agent eventually writes to disk through a tool call. Mneme operates at that boundary:
- If the agent is Claude Code, the Mneme PreToolUse hook intercepts every
Edit,Write, andMultiEditbefore disk — violations exit 2 with the decision id, and Claude Code adjusts. - If the agent is Cursor running inside or alongside a Warp pane, the Mneme-generated
.cursor/rules/mneme.mdcfile is what the session reads as context. - If the agent is any other tool that writes to the repo, the CI gate catches the diff at PR time.
None of these paths require Warp itself to know about Mneme. The governance layer sits below the orchestration layer.
Setup
pip install mneme
mneme init
# Wire Claude Code hook (if using Claude Code in Warp panes)
mneme hooks install
# Wire CI gate
mneme check --mode warn # try locally first
From there, every agent Warp runs inherits the same enforcement — no per-agent configuration, no Warp-side install.
If you use Warp Agent Mode with Claude Code
This is the most common combination today. Warp coordinates multiple Agent Mode panes, each running Claude Code against a slice of work. Mneme's PreToolUse hook applies in every pane simultaneously:
- Each Claude Code session reads the same
project_memory.json - Each
EditorWritetool call is intercepted before disk - Violations surface in the agent's own feedback loop — not as a post-hoc PR comment
- Parallel sessions cannot diverge architecturally because they all defer to the same corpus
Why this matters as agents scale horizontally. When Warp runs four Claude Code agents in parallel, the failure mode without governance is four mutually-inconsistent diffs that all "pass" because each agent only sees its own slice. Mneme makes the architectural corpus the shared invariant they all read against.
FAQ
Is this a native Warp integration?
mneme check, and any tool that writes to disk via repo-level enforcement. Warp orchestrates execution; Mneme governs the architectural intent underneath.Does Mneme slow down Warp Agent Mode?
What about Warp workflows that don't use Claude Code?
mneme check runs in GitHub Actions or GitLab CI against every PR diff regardless of which agent or tool produced it. For interactive enforcement with non-Claude agents, the Cursor Rules export or repo-level conventions are the available surfaces today.