Updates & rollback
intentic ships several times a day. These are the promises every one of those updates keeps: what an update can never touch, how you find out when something will change, and the way back when one turns out badly.
On this page(4 sections)
The promises
- Your files are never touched. Your code, notes and agent history live outside the software that updates. Updating, rolling back and rebuilding all keep them, and we test that nightly against real releases: a sandbox is updated, rolled back and force-failed mid-update, and the files must survive all three.
- Updates are offered, never forced. A new release shows up as a card in your workspace saying what's in it, in plain words. Nothing updates while you're not looking, and nothing interrupts an agent mid-task without you choosing it.
- The worst outcome of an update is the sandbox you already had. An update that can't come up healthy puts your previous sandbox back by itself. And every update keeps one step back: if the new version misbehaves, rollback is a single command, offered right on the same card.
- Breaking changes are flagged before you take them, not after. When an update removes or changes something you may rely on, its card stops looking routine: it becomes a warning naming what stops working and what to do instead, and asks you to read it before handing over the command. The changelog carries the same lines under a Breaking badge.
- Nothing we ship can take your data hostage. The sandbox runs on your hardware and your state is plain files on your disk. Stop updating, roll back, or leave entirely: everything you made is already yours, readable without us.
When a release reaches you
As soon as it passes. A release is built, installed and verified on real machines before it is published, and the moment that finishes it becomes the version every download link and every update card offers. There is no waiting room: what the tests proved is what you get, and a fix reaches you the day it is written rather than two days later.
The trade is that we carry the risk on our side rather than yours. If a release turns out badly we put the previous version back centrally, in one step, and your sandbox simply stops being offered the bad one. Anything already running keeps running, because the older release is never withdrawn.
What can change freely
The promise is narrow. Everything outside it can improve without ceremony: how screens look, how features work internally, defaults you never set. A changelog entry tells you when a change is worth noticing; the warning treatment is reserved for changes that take something away, so that when you see one it means it.
If an update went badly anyway
Open the update card and take the rollback it offers: your files stay as they are and only the software moves back. If a settings file then reads as unreadable, that is usually the older version looking at a newer file, and the notice says so rather than asking you to fix something that is not broken.