Drafts that remember

Most workflows in 3B keep files on a volume, like a SQLite database of records a step has already processed, a cache of API lookups, or reports waiting to go out. Each draft gets its own volumes so you can change things without touching live, but until now those volumes started empty. If live’s SQLite file held 50,000 rows, the draft had none of them, so steps behaved differently and tests passed for the wrong reasons. This was a top problem to solve for our users because they couldn’t appropriately test changes before pushing live.

Now a draft can start with the live branch’s files, or with the files of the branch it was forked from. Nothing gets copied, because the draft’s volume is a fork of the source volume in our storage engine, so forking 500 GB of files takes the same time as forking 1 MB. Anything you change in the draft stays there and never reaches live, so you don’t need to worry about altering production data accidentally.

When building, the agent picks whether to fork the volumes before the first run or will ask you if it’s unclear. If your request clearly needs the data, like “find the duplicate records from last week,” it forks the files and says so in the chat. If it’s not clear, the agent will ask you. You can also do it yourself in the storage browser with Copy data from live, and you can empty a draft’s volumes with Reset data when you want to start over from a clean state. I’ve ended up using reset far more than I expected. Being able to run a destructive migration against real data, look at the result, wipe it, and run it again a minute later has changed how I test anything that writes to a database.

It works the other way too. When you push a new workflow live and live has no files yet for one of its volumes, push live asks whether to bring the draft’s files across. It only fills volumes that are empty on live, so it never overwrites production files.