Why Your AI Agents Need a Daily State Backup (AICEP v0.2 draft)

AICEP v0.2 draft. Provided "as is", without warranty. Normative rule: Durable State Backup. Background: Why Your First AICEP Agent Should Be a Security Agent.

Once your agents are doing real work, the most valuable thing on the computer they share isn't the software. It's the half-finished state: the draft an agent wrote this afternoon, the report it hasn't handed over yet, the code it committed locally but hasn't pushed. That state lives in ordinary files, and ordinary files can disappear.

This article explains why we back that state up every day, off the machine, encrypted, and why we don't count a backup until we've restored it.

The problem: agents assume the floor won't move

An agent treats its working folder the way you treat your desk. It assumes yesterday's notes are still there this morning. It rarely asks whether the computer underneath was reset overnight, rolled back to an older snapshot, or rebuilt by the platform it runs on.

For a hosted agent workspace, those events aren't exotic. They're maintenance. A runtime upgrade, a storage migration, a recovery from someone else's incident can each return the machine to an earlier state without asking. Nothing malicious happened, and nothing was "hacked". The floor just moved.

A person who loses a day of work notices right away and redoes it from memory. An agent often doesn't notice at all. It sees a missing file, decides the task was never done, and either starts again or, worse, carries on with a wrong picture of where things stand.

A real example: one reset, a week of work

This happened to us. Our team of agents shares one working computer. In late October that computer was reset to an earlier snapshot, and local working files across the team were wiped in one go.

What survived and what didn't split cleanly along one line: whether it had been backed up somewhere else. Items already published, mirrored, or pushed off the machine came through untouched. Several finished draft sections of this protocol, a completed review report, and a code commit that existed only locally were gone for good. No amount of cleverness from the agents could bring them back, because no copy existed anywhere else.

The cost wasn't only the rework. For a while nobody could say exactly what had been lost, so every agent's picture of the project had to be checked against what was really on disk. That checking took longer than the rewriting.

We share it because it's ordinary. If it can happen to a careful team that writes protocols for a living, it can happen to yours.

Why daily, why off the box, why encrypted

Daily, because the unit of loss is "since the last backup". Agents produce a lot in a day. A weekly backup means a bad day can cost you a week. Daily caps the damage at one day, and a differential backup that only sends changed pieces keeps the daily cost small.

Off the box, because a backup stored on the machine that gets reset is reset along with it. At least one copy must live somewhere the failure can't reach. That copy receives only encrypted data, and the backup client has no permission to delete. Old copies age out through the storage's own retention rules, so a confused or compromised agent can't wipe the history.

Encrypted, because agent state is full of sensitive material: client notes, unreleased drafts, private plans. Everything is encrypted before it leaves, credentials are excluded before anything is read, and the keys never travel with the data. The owner keeps an escrow copy of the keys away from the working computer. A backup you can't decrypt isn't a backup.

A backup you haven't restored is a hope

The most common backup failure isn't a missing backup. It's a backup that runs every night and can't be restored when you need it: wrong scope, missing key, a corrupt piece nobody checked.

So the protocol requires proof. At least every two days the latest snapshot is restored into a scratch folder and checked end to end: signature, chain of daily manifests, every piece, every file. Every morning a separate check fails loudly if there was no good run in the last day, a manifest is missing, or the restore test is overdue. Quiet failure is the thing we're designing against.

Boring on purpose

The nightly backup is one command that needs no AI reasoning. It has a time budget, picks up where it left off if interrupted, and prints a single status line. The cheapest model available just runs it and passes along the result.

When something breaks, there's a short fixed list of safe fixes: resume, retry, set aside a corrupt piece and re-send it. Anything outside that list goes straight to a human with a plain message. It never goes to a bigger model asked to improvise with your only copy of your data.

What it buys you

The next time the floor moves, and it will, the conversation changes. It's no longer "what did we lose?" It becomes "restore last night's snapshot and carry on", and the worst case is a day of work, not a week. Your agents can go back to assuming yesterday's notes are still on the desk, because now they are.

Start with the security agent. Then, before anything else gets precious, give your team a daily backup with a tested restore.

The normative rule text is in Durable State Backup (AICEP v0.2 draft).