Mneme HQ gives a multi-step AI development workflow one shared decision store. A planner agent can receive the decisions that match its task before it scopes the work. Your orchestrator runs mneme check on what a coder agent wrote before a reviewer agent sees it, and the continuous integration (CI) check runs again on the pull request. Decisions with a typed rule get a deterministic verdict; the rest reach agents as guidance. Memory tools recall context. Mneme governs implementation.
Reference Architecture · Simulated Scenario

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.

SHARED DECISION LAYER Stage 1 Planner Agent Stage 2 Coder Agent Stage 3 Reviewer Agent Deployer Agent Mneme HQ Decision Store .mneme/project_memory.json shared across all stages keyword retrieval per query strict exit code gates stage JSON verdict per check context mneme check verdict CI
The Problem

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.

Stage 1

Planner

Scopes tasks and picks approaches with no memory of past decisions

Stage 2

Coder

Implements the plan and breaks architecture rules it can't see

Stage 3

Reviewer

Evaluates output and approves violations it has no context to catch

Stage 4

Deployer

Ships, and architectural drift reaches production

Without Mneme HQ, the planner proposes:
Task: "Build a search feature"
Plan: Query the database directly from the API handler using raw SQL for performance. Skip the repository layer to reduce latency...
With Mneme HQ, decisions reach the planner first:
mneme test_query --memory .mneme/project_memory.json --query "build a search feature in the handlers"
(simulated output)
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.
Why Existing Tools Fall Short

Orchestration layers coordinate agents; out of the box, they don't check output against your project's recorded decisions.

ApproachLimitationWith Mneme HQ
Agent system promptsStatic; can't cover full decision history; each agent has its own contextShared decision store queried by any agent at any stage
Shared context windowGrows too large; stale; not structured for retrievalKeyword retrieval: the decisions whose scope and text match the task, the same result on every run
Reviewer agentEvaluates code without the decision record, so it can miss violations of decisions it was never shownReviewer gets the JSON verdict, which names the decision and the matched rule
CI checksPost-pipeline; violations already implemented; expensive to fixA check between stages catches the coder's violations first; CI stays as the final check
How Mneme HQ Solves It

A shared architectural decision and control layer for every agent in the pipeline.

1

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.

2

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.

3

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.

4

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.

Technical Implementation

Wiring Mneme HQ into a multi-agent pipeline.

Pipeline orchestrator: Python sketch calling the mneme command-line interface (CLI)
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)
Terminal: checking the coder's handler before review (simulated output)
$ 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.

Simulated Outcome

What this setup gives you.

3 points
where your decisions enter the pipeline: as context for the planner, as a check on the coder's files, and in CI
~0
typed-rule violations reaching the reviewer in the simulated run, because the check stops each one in the coder's files; decisions without a typed rule are guidance and can still be missed
1
shared decision store for all agents, with no per-agent prompt duplication
These figures come from a simulated reference scenario, not live customer data.
FAQ

Common questions.

Does Mneme HQ work as a Python library or only as a CLI?
Checks run through the command-line interface (CLI): call 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?
Not by tag or by stage: 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?
A hook, a point where a coding agent lets outside code inspect an action before it runs, checks one agent's writes. Claude Code, Codex CLI and Kiro CLI 3.0 check supported writes before they reach disk, and only Claude Code and Codex CLI check shell writes, at the end of the turn. In a pipeline, Mneme gives every stage the same decision store, and the checks you add between stages and in CI cover the agents that have no hook.
What agent frameworks does this work with?
Any orchestrator that can run a shell command can call 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.