Meetless ยท Preliminary technical report

Does governed memory make a coding agent know what the team already decided?

Preliminary ยท internal N = 5 / arm ยท 2 tasks ยท 20 runs deterministic grading sandbox-isolated 2026-07-11
Abstract

We test one claim: a coding agent with governed memory can act on a team decision that exists only in the shared knowledge base, where a memory-less agent cannot. On a knowledge task whose answer lives solely in the governed store, mla passed 5/5 and vanilla passed 0/5 โ€” vanilla searched the filesystem, guessed, and gave up, spending more tokens and time to remain wrong. On a pure-coding control needing no team knowledge, both passed 5/5, and mla cost +2.1k tokens (+58%) and +17 s for no benefit โ€” the overhead we publish rather than hide.

The headline is not the numbers; it is the isolation. A benchmark is only as honest as the walls around the memory-less arm. We document seven ways our own harness leaked the answer to "vanilla," how each was sealed, and how you can verify the seal. We are also explicit about what this does not show: the opponent here is a memory-less floor, not a steelman. We owed a real one โ€” a competent CLAUDE.md snapshot โ€” and have since built and published it: it loses 0/5 once a decision is superseded. An ungoverned RAG index over the same corpus is the remaining opponent.

1Hypothesis & scope


The governed-memory thesis is a nine-step loop (observe โ†’ gate โ†’ promote โ†’ share โ†’ detect conflicts โ†’ inject โ†’ monitor โ†’ enforce โ†’ update). This report isolates and tests one link: inject only relevant, approved decisions into a task.

  • H1 (retrieval): when a needed fact lives only in the governed store, mla retrieves it and completes the task; vanilla cannot and fails.
  • H0 (overhead): when a task needs no team knowledge, governed memory adds cost without changing the outcome. We measure that cost.

Everything else in the loop โ€” trust gating, live conflict detection, deterministic enforcement, temporal validity โ€” is out of scope for this run and is not claimed here.

2Setup


Arms

ArmDefinition
vanillaClaude Code, headless, no memory layer. Sandboxed so mla's installation and the local store are unreachable โ€” i.e. a machine where mla was never installed (see ยง4).
mlaClaude Code + the mla plugin (governed-memory MCP server + capture hooks), bound to a seeded workspace. Unsandboxed โ€” it legitimately requires its own installation; that is the treatment.

Environment (pinned)

Modelclaude-opus-4-8
Claude Code2.1.197
mla0.2.14
Invocationclaude -p --output-format stream-json --permission-mode bypassPermissions
Repository stateidentical detached git worktree at a fixed base commit, per trial
Design2 tasks ร— 2 arms ร— 5 trials = 20 runs; fresh worktree per trial
Fairness โ€” what is held equal

Every arm gets the same repository state, task prompt, model, model configuration, permission mode, tool availability, and time budget. The only intended difference is the memory mechanism. The vanilla sandbox (ยง4) removes access to mla's binary/credentials and the local store โ€” things a genuinely mla-free machine would not have โ€” and does not restrict repository reads, file writes, or the model API. It is a deprivation that matches the control condition, not a handicap.

3Tasks & grading


Task A โ€” governed-facts (knowledge)

The agent is asked to report three organizational facts about an internal pilot โ€” a codename, an exit criterion, and a report owner. These exist only in the seeded governed knowledge base: not in the repository code, git history, environment, on-disk notes, or any reachable service except through mla. mla can retrieve them via the governed-memory MCP tool; vanilla has no path to them and should answer UNKNOWN.

We ship a generator, not facts

The facts are invented at run time, never authored: a random codename, a random exit percentage, and a random owner name, seeded into a throwaway workspace through the same public API routes a customer uses (add โ†’ accept), then verified retrievable by polling the store before any agent starts. They live in exactly two places โ€” the store's database and the launcher's process memory โ€” and touch no file, commit, or environment variable the agent can read.

This closes the objection that isolation alone cannot: the answer is younger than the run. It cannot be in any model's training data, cannot have leaked into this repository, and differs on every execution โ€” so a published result can never contaminate a future one. It also means your numbers will differ from ours; what should reproduce is the separation, not the literal values.

Task B โ€” pure-util-slug (control)

Write a slug() string utility to an exact specification with worked examples. Fully self-contained; requires no team knowledge. This isolates governed memory's overhead when it provides no benefit.

Deterministic oracle โ€” no LLM judge, no answer on disk

Grading runs after the agent process exits. Task A's oracle checks the agent's answer.txt against expected values injected as environment variables at launch โ€” no literal answer is ever written to a file the agent could read. Task B's oracle imports the produced module and asserts it against the spec's worked examples. Both are pure, deterministic checks; efficiency metrics are computed only over runs that passed, so a fast-but-wrong run is a failure, never an "efficiency win."

4Threat model & isolation โ€” the part that matters


A knowledge benchmark is trivially gamed if the memory-less arm can reach the answer another way. Under bypassPermissions, the agent is filesystem- and loopback-omniscient, so obscurity is not enough. We enforce a hard invariant.

Isolation invariant

The answer to a governed-knowledge task exists in exactly two places, neither reachable by the vanilla arm: the governed-store database, and the launcher's process memory. It exists in no file, git object, environment variable, or network endpoint the agent can reach.

Getting there took seven iterations. Each was found by forensics on a suspicious pass, then sealed. We publish them because the failures are the credibility.

#How "vanilla" reached the answerSeal
1Task's own oracle/spec files sat in the worktreestrip the benchmark dir from the worktree
2Ran git show <sha>:oracle against shared historysever .git โ€” the worktree becomes a plain dir
3Grepped the facts from a sibling notes vault on diskkeep facts in the DB only; never on disk
4The oracle script itself contained the literal answerinject expected values via env; no literals on disk
5Dumped env and read the expected valuesdelete them from the child env; re-inject only into the grader
6Inherited a global memory MCP server + mla on $PATHstrip both from the vanilla config and PATH
7Found the binary by absolute path, read its config, and queried the live store over localhostsandbox: deny file-read of the install + deny all loopback egress

The vanilla sandbox profile (macOS sandbox-exec, sanitized)

(version 1)
(allow default)
; deny reading mla's install (binary + credentials + store URL)
(deny file-read* (subpath "$MLA_HOME"))          ; ~/.meetless
; deny reading the project tree: store env-keys, notes, and the bench oracle
(deny file-read* (subpath "$WORKSPACE_TREE"))
; deny ALL loopback egress: intel, control, Postgres, Weaviate
(deny network-outbound (remote ip "localhost:*"))

The external model API stays reachable; the worktree and the grader's own config dir live outside the denied subtrees, so the task itself is unaffected. Verified: under this profile the agent can read the worktree and reach the model, but every attempt to read the mla install or open any local port returns EPERM/refused.

Honest limit of this seal

This is a stopgap for benchmarking inside the mla repository against a live local store โ€” two conditions that make leakage possible in the first place. The durable design (next phase) is a neutral task substrate that contains no mla client code, plus a store reachable only through mla's auth boundary, so the memory-less arms have nothing to learn from and nothing to connect to โ€” making most of the sandbox unnecessary.

5Metrics & statistics


Per run we record: task success (deterministic oracle), filesystem searches (grep/glob/find + grep-equivalent shell), work tokens (input+output, excluding cache), wall-clock time, turns, and governed-rule violations (independent post-hoc checker, same on both arms). We report medians with a nonparametric effect size (Cliff's ฮด).

Statistical honesty at N = 5

This is a pilot. p-values are normal-approximation and directional only; we lead with pass-rate and effect size, not significance. We make no claim of statistical superiority at this N. A published version needs larger N, paired per-task bootstrap deltas, and cost-per-successful-run alongside cost-per-run.

6Results


Task A โ€” governed-facts (knowledge)

metricmlavanilla
passed5/5 โœ“0/5 โœ—
retrieval healthgroundednone
searches (median)0 (every trial)9 (6โ€“15)
work tokens (median)5.4k21.2k (โ‰ค24k)
context tokens (median)163k1.12M (6.9ร—)
agent time (median)31 s4.7 min (โ‰ค7.2)

Vanilla's figures are the cost of failing: it spent more and produced the wrong answer. With no passing vanilla runs, the comparison reduces to the only fact that matters here โ€” one arm can answer the question at all, and the other cannot.

Task B โ€” pure-util-slug (control)

metricmlavanilla
passed5/5 โœ“5/5 โœ“
searches (median)00
work tokens (median)5.8k3.7k
agent time (median)31 s14 s
overhead+2.1k tokens (+58%) ยท +17 s ยท Cliff's ฮด = 1.00

Perfect separation on tokens: every mla run cost more than every vanilla run. This is the price of the always-on grounding floor on a task that needs none of it โ€” reported, not hidden.

7Threats to validity โ€” read before citing


  1. The opponent is a floor, not a steelman. Naked vanilla has no memory, so it obviously cannot know a governed decision. This shows memory helps โ€” not that governed memory beats the alternatives a real team uses. We have since paid down half of that debt: the freshness benchmark pits mla against a competent CLAUDE.md snapshot โ€” accurate the day it was written โ€” and the snapshot loses 0/5 once the decision is superseded, reporting the stale value or never answering. The remaining opponent, an ungoverned RAG index over the same corpus with governance as the sole variable, is still owed.
  2. Small N, one model, one machine. N = 5 per arm, a single model build, a single host. Directional evidence only.
  3. Asymmetric isolation. Vanilla is sandboxed; mla is not. We argue (ยง2) this matches the control condition rather than handicapping vanilla, but it is a real asymmetry a reader should weigh.
  4. Two tasks. One knowledge task, one control. Broader task coverage is needed before generalizing.
  5. In-repo, live-store setup. Benchmarking inside the mla repo against a live local store is what made isolation hard; the sandbox is a stopgap, not the portable design.

8What we do not claim


  • That governed memory makes agents faster in general โ€” on the control it is slower and costlier.
  • That mla beats other memory or rule systems โ€” not tested here; only tested against no memory.
  • Any statistical superiority claim at this sample size.
  • Any capability beyond retrieval-of-approved-facts โ€” conflict detection, enforcement, and temporal validity are separate and not exercised in this run.

9Reproduce


The harness reads task prompts, oracles, and metrics from the repository; results are aggregate-only (raw transcripts, which embed the answer, stay out of published artifacts and are secret-scanned).

cd tools/bench-mla
node run.mjs --trials 5     # tasks ร— arms ร— trials โ†’ runs/
node analyze.mjs            # runs/ โ†’ results/summary.json
node report.mjs            # โ†’ results/report.md + .html

Reproducibility target is the protocol, not the exact numbers: hosted-model and Claude Code version drift make bit-identical reproduction unrealistic. Run the same protocol; expect statistically comparable results.

Meetless ยท governed memory for coding agents  ยท  preliminary / internal  ยท  2026-07-11
base commit e20643b9  ยท  claude 2.1.197  ยท  mla 0.2.14  ยท  model claude-opus-4-8  ยท  N=5/arm, 2 tasks, 20 runs