Memory Versioning for Scheduled AI Agents: A Rollback Playbook

Every mature data store has a rollback story. Relational databases have point-in-time recovery. Code has version control. Configuration has change history. Agent memory, the store your scheduled agents mutate every single run, usually has none of these. It is a single mutable bucket: the agent reads it at the start of a run, overwrites parts of it at the end, and nobody can say what it contained last Tuesday.

If you operate scheduled AI agents, this gap is worth closing before it costs you a week of bad output. This playbook covers what breaks without versioning, the three layers that make it work, and a rollback runbook for the next time a run poisons the store.

The three failures versioning prevents

The silent bad write. A support-triage agent runs every 15 minutes. One morning it misreads a thread, concludes that billing questions route to the sales queue, and saves that as a standing rule. No human sees the write. For the next six hours, every billing ticket goes to the wrong queue. Without a version history, you discover the rule only when the sales team complains, and you cannot tell when it was created or what triggered it.

The overwrite with no undo. A lead-scoring agent updates its qualification criteria each Friday from the week's closed deals. One Friday the input data is malformed, and the agent writes garbage over the good criteria. The previous criteria are gone. There is no "before" to restore.

The resurrected stale fact. Two agents share one memory. Agent A updates the shipping cutoff to the new policy. Agent B, running an older prompt, still believes the old cutoff and writes it back. Last write wins, so the stale fact is current again. Without history, the memory looks like it "randomly" reverted. With history, you see exactly which run resurrected it.

All three share a root cause: memory that can be changed but not inspected over time.

The versioned memory stack: three layers

You do not need a new database to version agent memory. You need three layers, each cheap.

Layer 1: the conversation archive. Every run of a scheduled agent is a conversation with a start, a middle, and an end. Archive the full transcript of each run with a timestamp. This is your forensic record. When output goes wrong, the archive answers the two questions a fact store cannot: when did the bad entry first appear, and what did the agent see that made it believe it? A memory layer that stores full conversation history, not just extracted facts, gives you this layer for free.

Layer 2: the timestamped fact store. The facts themselves should carry metadata: when each entry was written, which run wrote it, and what it replaced. "Shipping cutoff: 2 PM, written by triage-agent run 2026-09-28-0600, replaced: 4 PM" is a versioned fact. "Shipping cutoff: 2 PM" is a rumor. If your store does not keep the replaced values, keep a lightweight changelog alongside it: one append-only line per write, with run ID, timestamp, and the old and new values.

Layer 3: periodic snapshots. Once a day, or before each run for high-frequency agents, capture the full memory state and freeze it. Snapshots are your restore points: a dated copy of the memory files, a database snapshot table, or an export to object storage. Keep per-run snapshots for two weeks and weekly ones for three months; nearly every memory incident surfaces within days, so a short hot window covers the real risk.

The rollback runbook

When output looks wrong, work the runbook in order. Do not skip to "restore from snapshot": restoring blindly loses the good writes that happened after the bad one.

1. Freeze the suspect. Note the exact fact or rule that looks wrong and the run where you noticed it. Resist the urge to fix it in place yet; an in-place fix destroys the evidence.

2. Trace it in the archive. Search the conversation archive for the first appearance of the bad entry and read the turns around it. You are looking for the cause: stale source data, a misread page, an inference made without evidence, or a conflicting write from another agent. The cause determines the guard you add later.

3. Scope the blast radius. Check the changelog for everything the same run wrote, and for later runs that read the bad entry and wrote confirmations of it. Corruption spreads: a bad criterion gets cited by subsequent runs, which then look like independent confirmation.

4. Revert surgically. Delete the bad entries and their confirmations. If the damage is wide, restore the snapshot from before the first bad run, then replay the changelog entries after it, skipping the tainted ones. Surgical reverts beat full restores whenever the tainted set is small, which it usually is if you caught it within days.

5. Verify with a dry run. Trigger the agent once manually on the repaired memory and confirm clean output before the next scheduled run fires. A rollback you have not verified is a second incident waiting for its timer.

6. Write the guard. The incident exposed a gap in the agent's standing rules. Encode it: "billing questions route to support, never sales," or "shipping cutoff changes require a dated policy source." Save the guard to memory so the failure makes the system smarter. A rollback without a guard is just a pause before the repeat.

Build it or buy the history

The honest question is how much of this you want to operate yourself. The archive, the changelog, and the snapshots are all buildable with scripts and discipline. They are also exactly the kind of undifferentiated plumbing that quietly rots: the snapshot cron nobody monitors, the archive nobody prunes, the changelog format two agents disagree on.

The alternative is a memory layer where the history is the default. Vilix AI is cloud-hosted, so there is no snapshot cron to babysit and no archive to prune yourself. Every agent you connect over MCP shares the same memory, which means the conversation archive and fact history cover your whole fleet in one place instead of three unversioned ones. It keeps full conversation history rather than just derived facts, so the forensic layer of this playbook exists from day one. The free plan is free forever, the 7-day Pro trial needs no credit card, and the data stays portable: export everything or delete it anytime.

Whichever route you take, judge the memory layer by one test: can you answer "what did my agent believe last Tuesday, and why?" If the answer requires archaeology, the layer is not versioned yet.

Start with the archive

You do not need the full stack on day one. Start with layer 1: archive every run's conversation with a timestamp. That single habit turns the next incident from a mystery into a search query. Add the changelog when writes start conflicting, add snapshots when an incident makes you wish for a restore point, and rehearse the runbook once while everything is healthy. Scheduled agents will keep rewriting their memory every run. Versioning is what makes the job survivable.