Survive Updates

Level 2 · Course 16

The platform will change under your feet. Files will move. Defaults will reset. Plugins will break. A release note will say "improvements" and your agent will wake up different. If your architecture only exists inside the platform's current behavior, every update is a threat.

Level 2 ends with update survival because sovereignty has to hold when the ground moves. Your agent builds a plain-text update shield — four steps, in order. Here's what each one looks like in practice.

Backup

Before any update runs, the agent snapshots your config files to a dated folder. An operator wakes up to a platform update notification. The agent says: "I've backed up your config to /backups/2026-05-20. Update when ready. If it breaks, I roll back from the snapshot in under a minute." The operator clicks one button. The agent handles the rest.

Sandbox

Test the update in a copy of the workspace first, not the live one. The agent clones the workspace to a test directory, runs the update there, and checks: do trigger words still fire? Do operating rules still load? Does the boot chain complete? It reports results before touching anything live. If the sandbox update breaks the boot chain, the operator knows before the live workspace is touched.

Verify

After the update goes live, the agent runs a quick checklist: do trigger words work? Does the boot chain load? Can the agent read and write files? Is the gateway reachable? Each check gets a pass or fail. If anything fails, the agent flags it before the operator starts the day's work — not three hours in.

Rollback

If verification fails, the agent restores from the pre-update backup. The operator doesn't spend the morning debugging. The workspace goes back to the last known good state, and the update waits until the platform fixes whatever broke. Rollback is not panic. It is the last step of the plan.

You Decide

How often do you check for updates? Weekly is common. Set a recurring task. Your agent handles the rest.