Production AI agent memory is a write-gate plus an audit cron, not a vector database choice.

RAG retrieves from a fixed corpus you indexed once. Production agent memory retrieves from a per-user, per-session, ever-growing store the agent itself wrote into. The implication is that every long-term memory write is a tiny model output your agent committed without a human in the loop. Without a write-gate, the memory layer becomes the highest-bandwidth way to inject ungrounded statements into the system. The fix is to treat memory writes the way you treat code: gated, reviewed, audited. memory/policy.yaml is the gate, memory/recall_cases.yaml is the test, scripts/audit-memory.sh is the CI.

A user says something tentative or wrong on day 1. Without a write-gate, the framework happily stores it as a fact. On day 22 a downstream question retrieves the high-confidence row and the agent confidently asserts a thing that was never true. The framework guides skip it because it is not a framework problem; Mem0, Zep, Letta, and Redis can all reproduce it equally. The fix lives one layer above: a policy file that says 'a user statement is not enough; tool_result or verified_document is required'. Once the gate is in place, recall-002-poisoning-trap is a frozen case and the Friday cron grades it weekly.

The frameworks are runners. The harness is the wiring that pins them. Mem0 stores and retrieves; the write-gate decides what is allowed to be stored. Zep tracks sessions; the audit cron grades whether the agent retrieves the right thing weeks later. Letta has memory blocks; the policy file decides which blocks belong to which user. The framework choice is reversible (we have moved clients between Mem0 and pgvector in a single PR). The harness is the part that survives the swap. It is also the part that survives the engineer leaving the engagement.

30 is the smallest set we have seen reliably surface real recall regressions while keeping the cron cheap enough to run every Friday. Below 18 cases, run-to-run variance dominates. At 100 cases the cron costs roughly four times as much, runs four times longer, and the engineer stops looking at the result. Two percent contradiction rate is the empirical floor: under two percent, two humans on the same case set will themselves disagree by that much. Above two percent, you are seeing a real regression. Both numbers are defaults from the same five named production agents we run; you should re-pick them at week 2 with your product lead.

Almost never for long-term memory. For working memory (Redis, TTL 30 minutes), yes; the agent has to maintain conversational coherence. For long-term memory (pgvector, TTL 90 days), no. If a fact is worth remembering for 90 days it is worth confirming with a tool call, a doc cite, or an explicit user confirmation turn. The exception is preferences ('I prefer dark mode') where the user is the authoritative source and there is nothing to ground against. Those go in a typed preferences namespace with a smaller surface area, not in the open memory store.

Those are runners and stores. The harness is the wiring that pins them. Mem0 ships built-in extraction prompts; the harness writes the prompt SHA into memory/policy.yaml and gates merges if the SHA on disk does not match the pin. Zep ships session and graph memory; the harness adds the recall benchmark, the weekly cron, and the contradiction threshold. Letta ships memory blocks; the harness owns which blocks belong to which user and who can write to them. LangChain has ConversationBufferMemory and friends; the harness is what makes any of them safe to ship to a real customer. Redis is a fast store; the harness is what decides whether a row should land in it. None of the frameworks answer the question 'has the recall layer drifted in the last six weeks?'. memory/recall_history.jsonl does.

Title: memory-drift detected on YYYY-MM-DD (N axis(es)). Body lists the contradiction rate per axis, links the per-case report with the agent's actual responses and the human-agreed targets, and shows the diff between this week's score and last week's. The PR has two paths. Path A is tighten the gate: bump min_grounding_confidence, add to forbidden_substrings, or add a new must_be_grounded_in source. Path B is accept the drift: extend memory/recall_cases.yaml with the cases the team chose to behave differently, bump case_set_id, attach a fresh audit-memory.sh run. Either path is one PR. The drifted axis stops gating merges until the PR lands; other axes keep grading.

memory/policy.yaml.write_gate.forbidden_substrings catches the obvious cases (ssn, credit_card, raw bearer tokens) at write time. The harder cases (a name, an address) are namespace-scoped: when a user invokes deletion, scripts/forget-user.sh drops every row in agent_id=*/user_id=<the user> and tombstones their entries in memory/cold/. The audit axis forget_compliance has cases that probe the next session and assert the row did not survive. The runbook has a page for 'a user requested deletion'. None of this is a SaaS feature; it is bash, yq, and python in your repo.

Yes. The write-gate cares about grounding_kind and grounding_confidence; tool-using agents tend to write more grounded rows than chat agents, so the recall scorecard tends to be greener out of the gate. Code agents add a deterministic axis (compiles, lints clean) that lets the gate accept code-related memory writes more aggressively. Vision agents add image-hash checks. Voice agents add transcript-checks. The memory/policy.yaml shape is identical across modalities; the must_be_grounded_in list grows, and the recall_cases axes pick up modality-specific cases (cross-session voice continuity, scene_consistency for video).

Seven files in the client repo on main: memory/policy.yaml, memory/recall_cases.yaml, memory/runbook.md, memory/write_gate.py, scripts/audit-memory.sh, scripts/decay-memory.sh, .github/workflows/memory-audit.yml. Plus memory/recall_history.jsonl which is generated by the cron and committed back to the repo. The harness is model-vendor neutral: the embedding model is pinned by SHA in YAML, the store is named (pgvector / Mem0 / Zep / Redis), no SaaS license is required, and there is no platform-attached runtime. The named senior engineer who shipped it leaves a runbook in memory/runbook.md that walks the on-call engineer through reading recall_history.jsonl when a customer escalates. We leave; the harness stays.