A workspace has more than one boundary.
There is the host running the managed appliance, and there is the isolated guest where Agent Bridge actually runs. Updating the first does not, by itself, prove that the second has reached the intended release.
We found this out during a fleet upgrade.
The host side moved forward. The guest did not converge in the same way, and a later restart encountered a database schema mismatch. The change looked much further along than the running workload really was.
The missing acceptance check
The repair moved guest database migration and validation into the upgrade path. Before mutating the running workspace, the upgrade runs a read-only release check, drains the SQLite write-ahead log and writes a root-owned database backup with a SHA-256 digest.
The target release now has to validate the database it will actually use. If migration or stability acceptance fails, the retained guest tree and the database backup are restored together. Version metadata advances only after that work succeeds.
That sounds procedural because it is.
The important point is that an upgrade should be judged at the boundary where the application runs, not at the first layer that accepts a new artifact.
What this means for agent-operated software
An agent can complete a code change, pass its tests and open a pull request. Another agent can even initiate an upgrade. Neither action proves that the application now serving customers is healthy.
The last check must read the deployed system.
This is why we keep distinguishing work completed in a repository from outcomes verified in a running environment. The agent should be able to follow a task through the final acceptance boundary, but it should also be prepared to stop and show the evidence when that boundary cannot be crossed safely.
A successful deployment is not a filename, a commit hash or a version label. It is a condition the running software must satisfy.