A build is a prepared state of the machine: repositories fetched, dependencies installed, caches warmed. A successful build becomes active and serves as the base for runs; a failed one does not replace the last successful baseline. That simple rule gives an important property - a failed attempt to update the environment does not break work for those launching tasks right now. The flip side of the same rule: until the new build passes, agents keep working on the old description, and the divergence between what is in the repository and what is on the machine is yours to notice.
The dashboard offers more than it seems at first glance: logs, pinning a specific active build, launching an agent from a chosen version and restoring a previous environment configuration. All of that is reproducibility tooling. The ability to run a task on yesterday's build turns the question of when did this break from a guess into an experiment.
It helps to write the build readiness criteria out as a checklist once. It is given below: install completed successfully and repeats idempotently, all repositories are on the expected refs, tool and system package versions are pinned, services start separately from install, a focused test passes without manual tuning, the logs contain no secrets and a previous successful build exists for rollback.
The last two items are skipped most often, and both cost dearly. Build logs are read by people and stored by systems; a secret accidentally printed during installation ends up in a place you did not think about, and revoking it takes the same work as one leaked into a public repository. And the absence of a previous successful build means there is nowhere to roll back to: any failed environment edit stops all autonomous work until you fix it.
Snapshots are a separate topic. They are convenient and therefore dangerous: along with useful state, an accidentally created local environment file may end up in the snapshot. The recommended channel for secrets is the dashboard's separate store rather than a file that happened to be on disk at the moment of capture. That is exactly the case where convenience and security diverge, and the choice has to be deliberate.
Snapshots also have a lifetime: after a long period of inactivity they expire automatically, and each start or resume extends the window; a corporate retention policy does not move that boundary. The practical conclusion is simple - a snapshot is not an archive. Everything that must survive for months lives in the repository and in the environment description, not in machine state the system is entitled to reclaim.
The ability to run a task on a chosen build deserves treatment as a technique rather than as a menu item. When autonomous runs suddenly start failing at the same step, the question is always one: did the code change or did the environment change. The answer takes two runs - the same task on the current build and on the last one where everything worked. If it passes on the old one, the environment is at fault, and the investigation narrows to the differences between two descriptions. If it fails on both, the environment is innocent, and attention moves to the code and to external services. It is the same technique as hunting for the commit that broke things, applied to the environment.
Pinning a build has a price, and it is worth remembering so the technique does not become the problem. While a project lives on an old pinned build it accumulates divergence: tool versions, system packages and the base image move forward while the machine stays put. That is a reasonable temporary measure for the duration of an incident and a poor permanent policy, because returning costs more the longer it is postponed. The sign that tells you in real work that the divergence has gone far is an environment update that fails not at one step but at several unrelated ones at once.
The engineering conclusion: a build is a version of your environment and should be handled as a version. Pinning the active build, having a previous successful one, clean logs and a reproducible install give the same thing a tag in a repository gives: the ability to return to a known good state without archaeology.
The typical failures are predictable. Updating the environment without a previous successful build and being left with no rollback. Leaving secrets in install logs. Keeping something needed in a snapshot that will expire. Pinning a build for the duration of an incident and forgetting about it for half a year. And treating a successful build as proof of workability without running at least one focused test.
A ready-to-run build
[ ] install completed successfully and a repeat run is idempotent
[ ] all repositories are checked out at the expected refs
[ ] tool and system package versions are pinned
[ ] services start separately from install
[ ] a focused test passes without manual tuning
[ ] the build logs contain no secrets
[ ] a previous successful build exists for rollback