Your agent stopped. Did its files disappear?

An agent finishes a task. Its browser window closes. The screen goes dark.

None of those events, by itself, proves that the files are gone.

For anyone building or renting computers for agents, “memory” is an easy word to misunderstand. It can mean the computer's RAM, its saved files or information an agent remembers in a separate service. A useful storage policy should explain each one.

RAM is working space

RAM holds information that running software needs. Ending an agent process normally allows the operating system to reclaim that process's memory, but the browser or another application may keep running. Shutting down a desktop ends its running processes; suspension and hibernation have different behaviour.

Even then, “the RAM is gone” is not a complete privacy promise. The system may have written temporary data to disk through paging, hibernation, application caches or crash reporting. Screenshots and task logs can exist outside the desktop as well.

Think of RAM as one part of the data lifecycle. It is not a substitute for a documented reset process.

Saved files are meant to survive

A spreadsheet, download, project file or browser profile usually belongs on persistent storage. Keeping it between sessions can be exactly what a customer wants. An agent may need to return tomorrow and continue the same work.

Orgo provides a concrete example in its stop-computer documentation. Its described stop operation archives the disk to object storage and releases the running host. Starting again restores the disk on another selected host. Running processes and RAM state do not survive that operation; saved disk contents do. That is a persistence feature, not a wipe. Source: Orgo stop-computer API.

The important question is therefore specific: which action deletes which data, and how long can other copies remain?

Agent memory can live somewhere else

An agent can remember preferences without keeping them on the computer it operates. Orgo's memory guide, for example, demonstrates Mem0: interactions and preferences are stored and retrieved separately by user identifier, with a separate deletion operation. Destroying a computer is not the same action as clearing that agent-memory store. Source: Orgo memory guide.

The same principle applies to a framework's conversation history, uploaded attachments and exported screenshots. To delete a task's data comprehensively, the service needs to know every relevant storage location. A single “clear memory” button should not hide several different retention policies.

Four actions deserve four clear meanings

For ComputerUse, the proposed product language separates the following actions:

Action	Intended meaning to define and verify
End task	Stop the agent's work; keep the assigned desktop and saved files unless the task explicitly used an ephemeral workspace.
Stop desktop	Shut down the desktop; state clearly whether the disk is retained and whether the rental still reserves the host.
Reset workspace	Revoke active access and remove the workspace data covered by the reset policy after an explicit destructive-action confirmation.
End rental	Revoke customer and agent access, apply the published retention policy and verify cleanup before reassignment.

These are design requirements, not claims that the production workflow has already been validated. The customer should be able to understand the consequence before pressing a button.

What about prohibited content?

A general-purpose desktop can receive unwanted material through uploads, browser caches and application downloads. A credible service cannot promise that unrestricted software will never write a prohibited file.

The product needs prevention measures, constrained permissions where appropriate, a way to report abuse and a controlled response when something is flagged. Any automated detection system needs a defined review process; a flag is not by itself a reliable judgment about a person or a file.

Routine deletion and an abuse investigation also serve different purposes. Suspected illegal material may require restricted preservation and reporting under the rules that apply to the operator. The service should settle that process with qualified local advice before launch, without exposing the content to staff or customers unnecessarily.

A reset should be evidence, not a slogan

Deleting a directory or reinstalling a desktop does not automatically establish that every recoverable copy is gone. NIST's media-sanitisation guidance treats sanitisation as a controlled process chosen for the data and media involved. The operator must define, execute and validate the relevant process. Source: NIST SP 800-88 Rev. 2.

For customers, the practical standard is straightforward: ask what persists, what the reset covers, how backups expire, who can access them and when a machine can be assigned again.

A computer that remembers your work can be useful. A service that explains exactly what it remembers is easier to trust.