Resetting the Agent Doesn't Undo the Action

The reset covers whatever the environment's restore mechanism explicitly captures. A checkpoint is a saved state you can return to; it isn't a promise that everything the agent touched returns with it. Fly's Sprites documentation describes checkpoints of the machine's filesystem and says restoration replaces that filesystem. That tells you where to start drawing the recovery boundary.

Draw every connection leaving that boundary: shared folders, remote databases, browser sessions and services that accept writes. If a service holds its own state, restoring the caller's files doesn't instruct that service to reverse a completed request. Treat that as an architectural consequence of separate systems, then test it against the actual integrations you intend to use.

The public article Two Kinds of Agent Computer distinguishes task computers in the cloud from agents driving an already signed-in desktop. It raises the account-access problem in both. Gunner Technology's position is that the next buying question should be about recovery: show us what remains after you throw the computer away.

Connections can leave effects in storage and accounts outside the machine, even when the local session disappears. Microsoft's Windows Sandbox configuration guide gives a concrete example: changes to a writable mapped host folder persist after the sandbox is disposed. A mapped folder makes files outside the sandbox available inside it. That convenience changes what disposal can undo.

Now consider a browser agent signed into a business application. The browser holds access to the account; the application holds the records. Rebuilding the browser environment may remove its local session, but it doesn't establish that the account's records or permissions are back where they started. The application needs its own check and, where supported, its own repair operation.

Inventory access by resource and permitted action. Name who can disable the account or revoke its sessions, where activity is recorded and which actions cannot be reversed. Our post on task-bound agent credentials covers limiting authority before the run. The recovery record needs to explain what happens after that authority has already been used.

Test it with harmless actions in disposable accounts and storage, then inspect the receiving systems after the reset. Create a local scratch file, modify a dedicated shared test file and create a clearly identifiable test record in a remote application. Use synthetic data and a restricted identity. Write the expected result for each surface before starting.

Restore or destroy the worker environment using the exact operation proposed for recovery. Check the local files, shared storage and remote record separately. Keep the external activity log somewhere the reset won't erase. A test that looks only inside the rebuilt machine can report a clean result while overlooking everything the worker already changed elsewhere.

Test revocation separately too. Disable the test identity or session through the receiving service's supported controls, then verify that another action is refused. Restoring files and withdrawing access are different operations. Preserve the result, including any delay or uncertainty, so the person approving unattended work knows what the stop procedure can actually enforce.

Stop new actions, preserve evidence and determine which external effects need attention before restarting the task. Use controls outside the worker to stop its execution and withdraw the relevant access. Keep a record of attempted and completed actions; an interrupted request may need investigation rather than an assumption that nothing happened.

Give each affected integration a specific recovery route. A remote record might need a compensating action, meaning a new operation that corrects the earlier one. A shared file might need a separate restore. A sent message may require a correction because delivery cannot reliably be undone. An exposed secret needs revocation or rotation even if every local file has been restored.

Don't automatically replay a task whose completion is uncertain. The first attempt may have succeeded just before the worker lost its response. Check the receiving system before repeating the action. Our broader post on rollback as a factory capability explains designing the way back before release. An agent computer needs that same discipline at each connection.

Start with a recurring task in a repository or application you own. Keep its account access narrow and its external writes easy to inspect. Have the factory collect the action record and run the known recovery checks. People choose the permitted consequences and judge the exceptions; rebuilding an activity history by hand should not become their nightly job.

Before expanding the agent's role, ask for evidence from the reset rehearsal beside the successful task result. Which files returned? Which remote changes remained? Which access was withdrawn? What still required a person's decision? A fresh machine is useful. Knowing what it left behind is what lets you trust the next run.