How to back up and restore a persistent AI agent

Memory is not recovery.

Your agent can remember every preference you ever gave it and still fail to boot. It can recall a project in detail and still be missing the package it needs to work on that project. Memory protects what the agent knows. It does nothing for the environment that knowledge runs inside.

That gap is why people stop updating.

We watched it happen during the Mantlecore beta. Users wanted to update Hermes and Agent Zero, try new skills, switch models, let their agents experiment. They didn't, because they had finally made the setup useful and one bad dependency turns a useful agent into a weekend repair project.

Your agent is a computer, not a chat session

A chat session produces an answer and disappears. A persistent agent changes an environment and keeps the changes.

It writes files, installs packages, runs services, stores memory, creates scheduled jobs. It can rewrite its own configuration and connect to external tools. The longer it runs, the more state accumulates — and that state is the reason it's useful to you.

It's also the reason the environment is hard to rebuild. Install the wrong package and a tool stops working. Change the wrong setting and the agent loses access to its model. Apply an update and a skill that worked last week behaves differently this week.

You can repair that by hand: dig through old docs, diff config files, reinstall one package at a time, try to remember which version worked. Or you can create a restore point before the change and skip the archaeology.

There are two kinds of state, and you need both

Persistent memory gets most of the attention. It's the half that's easy to talk about and the half that can't repair a broken machine.

Agent state is what the agent has learned and been told:

• memory and preferences
• conversations and session history
• skills and instructions
• goals and scheduled tasks

Machine state is what the agent needs in order to act:

• workspace files
• installed packages
• model and provider configuration
• services and processes
• environment settings
• the agent runtime itself

Protect only the first and you get an agent that remembers everything and can do nothing.

Snapshot before a change, back up against loss

These two words get used interchangeably and they solve different problems.

A snapshot is a point-in-time restore target for the agent's machine. Take one before you update Hermes or Agent Zero, install a new skill or tool, switch models or providers, change load-bearing configuration, or let the agent attempt something larger than usual. If the change works, keep going. If it doesn't, restore and move on.

A backup protects against losing the machine or its data outright. It lives separately from the environment it protects and follows a retention policy suited to the workload.

Snapshots roll back a change. Backups recover from loss. If the agent does work you care about, you want both.

Why we snapshot the VM instead of the app folder

Every agent hosted on Mantlecore runs inside its own isolated virtual machine, which gives us one clean recovery boundary. We capture the machine the agent lives on rather than a single application directory, because the things that break an agent — a package, a service, a provider config — live outside that directory.

The workflow is four steps: snapshot, change, verify, keep or restore.

Crash-consistent is not application-consistent

A snapshot can restore every byte of the VM correctly and still hand you an application in a bad state. That matters when SQLite, a vector store, or another writable service is mid-transaction when the snapshot lands.

Mantlecore snapshots are crash-consistent today. Before writing one, we flush the guest filesystem and capture RAM; if the flush fails, we abort and surface the error rather than write a restore point we already know is torn. That's the guarantee we're comfortable making right now.

An application-consistent snapshot goes further and asks writable services to prepare first — checkpointing SQLite, flushing a vector store, pausing writes, recording model and tool versions, saving the last external-action cursor. We don't expose general quiesce hooks yet, and restore currently returns status rather than booting an isolated clone and proving the agent is healthy.

Test the restore, not the snapshot

A successful snapshot notification proves the platform captured something. It doesn't prove your agent comes back.

Verify the restore periodically against a real checklist:

1. The VM boots.
2. The agent process starts.
3. The expected workspace files are present.
4. Required services respond.
5. The agent completes a small tool-using task.
6. Scheduled work still has the configuration you expect.

For stateful workloads, exercise the database or vector store too. A snapshot you've never restored is a theory, and an upgrade failure is a bad time to test it.

A safe update checklist for Hermes and Agent Zero

Before the update:

1. Record the current Hermes or Agent Zero version.
2. Record the active model and provider.
3. Save the versions of skills and tools you depend on.
4. Stop or quiesce writable services if your setup supports it.
5. Create a named snapshot
6. Confirm the snapshot completed without error.

After the update:

1. Confirm the agent process is running.
2. Open an existing workspace file.
3. Run one familiar tool.
4. Complete a small test task.
5. Check scheduled jobs and integrations.
6. Keep the update only once those pass.

If the checks fail, stop debugging the broken state. Restore the working snapshot, then investigate the update separately, on a machine that isn't the one you need working today.

Snapshots cannot undo the internet

A VM snapshot restores state captured inside the VM. It cannot reverse an action the agent already took somewhere else. If your agent sent an email, opened a GitHub issue, wrote to an external database, or triggered a payment, restoring the machine changes none of that.

That's a different layer of controls: scoped and revocable permissions, policy checks before tool execution, human approval for expensive or irreversible actions, idempotency keys for safe retries, reconciliation for external side effects.

Isolation limits the blast radius. Snapshots restore the machine. Policy governs what the agent can reach outside it. Snapshots give the agent's computer a way back; they don't give the internet an undo button.

The obvious objection: snapshots aren't new

They aren't. Proxmox, ZFS, and btrfs have done this for years, and if you self-host on the right stack you already have the primitive. Nothing in this post is a novel piece of infrastructure.

The gap isn't capability, it's placement. The restore point is only useful if it exists at the moment you're about to approve a change, on the machine that specific agent lives on, without you assembling a hypervisor, a storage layer, and a retention policy first. That's the part we build, and the limits above are real: crash-consistent only, no general quiesce hooks, no automated health proof on restore.

If you'd rather run that stack yourself, run it. Just don't run a persistent agent without it.

What the beta changed about how we build this

We treated updates as an infrastructure problem: keep software current, keep deployments reliable, fix failures fast.

Beta users reframed it. They didn't want another infrastructure dashboard. They wanted enough confidence to update, to install a new skill, to let the agent try something without gambling the setup they'd already made useful.

So the principle we build against now is simple: your agent should be free to change its computer, and you should be free to change it back.

Before your next update, create the snapshot and name it after the change you're about to make. If you'd rather not build the VM, snapshot, and backup layer yourself, Mantlecore gives every agent its own isolated VM with managed snapshots and recovery.

Frequently asked questions

Does persistent memory back up an AI agent? No. Memory protects what the agent remembers. A recovery plan also has to protect its files, packages, configuration, services, and runtime.

Can I snapshot an AI agent while it's working? You can take a crash-consistent VM snapshot on a running agent, but active databases and writable services may need application-level quiescing for a clean restore. Treat mid-write snapshots carefully and test the restored workload.

Does restoring a snapshot undo tool calls? Only where the effect lives inside the captured VM. A restore cannot unsend an email, reverse an external payment, or remove a change from a third-party service.

What's the difference between an agent snapshot and a backup? A snapshot is a rollback target, usually created before a risky change. A backup is a separate copy used to recover from data or machine loss.

Should a self-hosted agent use snapshots? Yes, if it has persistent files, packages, or configuration you'd hate to rebuild. Use whatever your VM, filesystem, or storage stack already provides, and test the restore periodically.

Can I back up Hermes Agent or Agent Zero? Yes. Protect the agent's own state and the machine around it: record versions, quiesce writable services where possible, snapshot, then verify the agent after the change.