Governing Multi-Step AI Development Workflows with Mneme HQ
Give every agent in your pipeline (planner, coder, reviewer, deployer) a shared record of your architectural decisions. One decision store. A check at every stage you gate.
Each agent in your pipeline starts with zero project memory.
Multi-agent development workflows, where a planner scopes tasks, a coder implements them, and a reviewer validates the output, are increasingly common. But each agent operates independently. The planner doesn't know what the coder knows. The reviewer doesn't know what was decided three sprints ago. Without a shared memory layer, architectural drift compounds at every stage of the pipeline.
The result: the planner proposes approaches that violate architecture rules, the coder implements them, and the reviewer, lacking the decision context, approves code that breaks conventions the whole team agreed on months ago.
Planner
Scopes tasks and picks approaches with no memory of past decisions
Coder
Implements the plan and breaks architecture rules it can't see
Reviewer
Evaluates output and approves violations it has no context to catch
Deployer
Ships, and architectural drift reaches production
Query: build a search feature in the handlers
All decisions (ranked by score):
[ADR-004] score=3.50 matched=decision, scope, rationale
[ADR-007] score=3.00 matched=decision, scope
Injected (top 3):
[Mneme decisions applied]
DECISION [ADR-004]: Handlers reach the database through the repository layer
Why: Handlers call repositories, which own transactions.
Scope: handlers
DECISION [ADR-007]: Search reads the search_index view, not raw tables
Why: Raw table scans bypass the search index.
Scope: search
→ The planner starts from both decisions. Guidance only: the check on the coder's files is what blocks.
Orchestration layers coordinate agents; out of the box, they don't check output against your project's recorded decisions.
| Approach | Limitation | With Mneme HQ |
|---|---|---|
| Agent system prompts | Static; can't cover full decision history; each agent has its own context | Shared decision store queried by any agent at any stage |
| Shared context window | Grows too large; stale; not structured for retrieval | Keyword retrieval: the decisions whose scope and text match the task, the same result on every run |
| Reviewer agent | Evaluates code without the decision record, so it can miss violations of decisions it was never shown | Reviewer gets the JSON verdict, which names the decision and the matched rule |
| CI checks | Post-pipeline; violations already implemented; expensive to fix | A check between stages catches the coder's violations first; CI stays as the final check |
A shared architectural decision and control layer for every agent in the pipeline.
Build a shared decision store
Write your decisions as architecture decision records (ADRs) in docs/adr and import them into .mneme/project_memory.json, one file every stage reads.
Gate each pipeline stage
Write each file the coder produces to disk and run mneme check on it before the next agent starts. In strict mode, the default, a WARN exits 1 and a FAIL exits 2, and your orchestrator stops on either. The typed rule that can fail a check and respect paths is an exact text ban (FORBID_LITERAL), which Mneme checks mechanically, so a prose plan fails or warns only if it contains a forbidden literal, an anti-pattern or a constraint term; the check does its real work on code.
Give each stage its decisions
Pass each agent the decisions that match its task: mneme test_query for a task description, or decision.applicable_to on the local Model Context Protocol (MCP) server for the files it will touch. Mneme has no stage or tag filter; scope words and path selectors decide what matches.
Keep the verdicts for audit
Add --json and store the output. Each verdict names the decision, the rule type, the matched text and the path selector. Mneme does not write a log itself, so your orchestrator keeps the verdicts for each run and records which stage produced them.
Wiring Mneme HQ into a multi-agent pipeline.
import json, subprocess MEMORY = ".mneme/project_memory.json" def mneme(*args): return subprocess.run(["mneme", *args, "--memory", MEMORY], capture_output=True, text=True) # Before invoking the planner: pass it the decisions that match the task context = mneme("test_query", "--query", task).stdout plan = planner_agent.run(task, context=context) def check(path, draft): return mneme("check", "--input", draft, "--target-path", path, "--query", f"edit to {path}", "--json") # Before invoking the reviewer: check every file the coder wrote files = coder_agent.run(plan) # {repo path: draft file on disk} for path, draft in files.items(): result = check(path, draft) if result.returncode != 0: # strict: 1 = WARN, 2 = FAIL or INCOMPLETE verdict = json.loads(result.stdout) draft = coder_agent.fix(path, violations=verdict.get("violations", [])) files[path] = draft if check(path, draft).returncode != 0: # re-check the fix raise SystemExit(f"{path} still fails; reviewer not invoked") reviewer_agent.run(files)
$ mneme check --memory .mneme/project_memory.json \ --input out/search.py --target-path app/handlers/search.py \ --query "edit to app/handlers/search.py" FAIL [ADR-004] FORBID_LITERAL "from app.db.client import" -- trigger: from app.db.client import Handlers reach the database through the repository layer path: app/handlers/search.py via app/handlers/** PATH APPLIED [ADR-004] app/handlers/search.py via app/handlers/** -- an include selector matched Result: FAIL $ echo $? 2 # The orchestrator sees exit code 2, skips the reviewer and returns the file to the coder.
The PATH APPLIED line shows why the rule fired. ADR-004 carries an include selector, app/handlers/**: a path pattern that limits the rule to files under app/handlers/. The same import in app/repositories/ would pass. If Mneme cannot finish an evaluation, it reports INCOMPLETE instead of a verdict and exits 2, so the sketch treats it as a failure.
What this setup gives you.
Common questions.
Does Mneme HQ work as a Python library or only as a CLI?
mneme check from your orchestrator as a subprocess, as the shipped Claude Agent SDK adapter does. The installed mneme package also has a Python API for decision storage, retrieval and context construction, which the Claude Agent SDK and LangChain adapters build on.Can different agents query different subsets of decisions?
mneme check has no filter flag. A query returns the decisions whose scope and text match it, and decision.applicable_to on the MCP server returns the decisions for given file paths. Typed rules apply across the whole corpus, limited only by their own path selectors, so a planner and a coder checked against the same file path get the same verdict.How does this position Mneme HQ relative to single-agent copilots?
What agent frameworks does this work with?
mneme check between stages. Shipped adapters exist for the Claude Agent SDK and for LangChain agent middleware on LangGraph. The middleware checks write_file and edit_file only, and graphs that run tools through their own custom nodes bypass it. AutoGen and other frameworks have no adapter: call the CLI between stages and keep the CI check as the backstop.