Memory Versioning for Agents: Every Fact, Every Version, Auditable

Your coding agent learned something important last Tuesday: that the deploy pipeline reverts `DATABASE_URL` on every redeploy, so infra cutovers must source it from a sticky secret. This Tuesday, it confidently ran the cutover from the old runbook and broke production for twenty minutes.

The knowledge existed. The problem is that most agent memory systems are a pile of sticky notes — facts go in, facts come out, and nothing tracks *when a fact became true*, *when it stopped being true*, or *who changed it*.

Sticky notes vs. a ledger

A memory store that only holds current text can answer "what do we know?" It cannot answer the questions that matter in operations:

- **What did the agent believe at the time it made that decision?** (Point-in-time recall.)

- **When did this fact change, and what replaced it?** (Version history.)

- **Which memories were written by which session, task, or human?** (Provenance.)

- **If two facts conflict, which one was true on the date in question?** (Bitemporal validity.)

A ledger-shaped memory — where every update creates a new version, supersedes the old one, and records validity windows — answers all four mechanically.

Bitemporal in practice

"Bitemporal" sounds academic. It's two timestamps:

- **valid_from** — when the fact became true in the real world.

- **recorded_at** — when the system learned it.

That pair lets you run the query that saves postmortems: *as of 2026-05-09, what did we believe about the deploy pipeline?* If the sticky-secret rule was recorded on 2026-05-10, the postmortem writes itself — the agent acted on the best available knowledge, the knowledge was incomplete, and the fix is a process change (record runbook updates *before* cutovers), not a model change.

Without bitemporal recall, that same postmortem ends in a shrug: "the agent hallucinated." It didn't. It remembered correctly — from an outdated version.

Why updates must be versions, not edits

When a fact changes, the temptation is to edit it in place. Don't. Supersede it:

1. The old version is marked `superseded`, with a pointer to its replacement.

2. The new version carries a `change_reason` — why the world changed.

3. Both stay queryable forever.

This turns your memory store into the same kind of system you already trust for code: append-only history, diffs between versions, blame per line. Your agents get `git log` for their own knowledge. And because nothing is ever destroyed, an agent can always walk back: *what did I know, when did I learn it, and what changed since?*

Composite recall: similarity isn't enough

Versioning handles *truth over time*. Retrieval handles *what's relevant now*. Naive vector search returns whatever is semantically closest — including the archived runbook from March. Production recall needs a composite score:

- **Semantic similarity** — is it about the task at hand?

- **Recency** — fresher versions outrank stale ones.

- **Importance** — the incident postmortem outranks the lunch menu, even when both mention "database."

Blend the three, filter out superseded versions by default, and an agent starting a deploy task gets the sticky-secret rule in its top results — not the fossil it replaced.

The audit angle

Enterprises evaluating agent platforms eventually ask: *"Your agent did X. What information was it acting on?"* With versioned memory, that's a query, not an investigation. The answer links the session, the exact memory versions in context, their provenance, and their validity windows.

We benchmarked this against our own production store — thousands of real memories, labeled recall probes, the misses published alongside the hits. The short version: sub-10ms store-and-verify round trips, top-5 precision good enough to trust, and — more valuable than any number — two real bugs caught *because* the benchmark versioned everything.

The takeaway

Sessions end. Context windows reset. Models get swapped. The only thing an agent platform truly owns is what it remembers — and memory without versions is a rumor mill. Treat knowledge as a ledger: every fact versioned, every change reasoned, every belief queryable as of any date.

Your future postmortems will thank you.

---

*Part of the FlukeBase supervised-autonomy series. Next: designing an MCP tool surface that agents don't fumble.*