Agent devices

Devices are the machines agents use to do real work. MIOSA has three active device classes and one hosting target:

Type	Product meaning
Sandbox Worker	Isolated code/file/build/preview/artifact workspace
Computer	Persistent cloud desktop/browser with screenshot and input APIs
Local Device	Paired user-owned machine for local files, apps, and private network access
Docker Deploy	Durable app-container host after development is finished

Docker Deploy is not where an agent edits code. It is where a verified sandbox-built app runs as a durable container.

Device selection

Job	Pick
Generate code, run tests, install packages	Sandbox Worker
Build a Next.js preview	Sandbox Worker
Generate PDFs, DOCX, images, diagrams, charts	Sandbox Worker
Browse a website, fill forms, login, click UI	Computer
Screenshot visual QA	Computer
Use a private VPN, local IDE, local files, customer desktop app	Local Device
Host many customer apps under one workspace	Docker Deploy

How devices relate

The agent can switch devices during a run. For example, a sandbox writes a web app, a computer opens the preview and checks it visually, then the sandbox publishes the verified result.

Sandbox Worker

A sandbox is the normal runtime for coding agents.

Capabilities:

persistent /workspace
file read/write/list/delete
Bash, Python, Node, package managers
long-running dev servers
public preview URLs
snapshots and forks
generated artifacts
deploy and Docker Deploy publish prep
scoped environment variables and connectors

Use a sandbox to build products like app builders, artifact factories, research workspaces, evaluation runners, and code agents.

Computer

A computer is a full desktop/browser runtime.

Capabilities:

screenshot
click, type, scroll, drag
clipboard
window control
browser sessions
visual QA
terminal and shell
persistent storage
embeddable desktop stream

Use a computer when the job requires a visible browser, GUI automation, manual handoff, or desktop-only software.

Local Device

A local device is a paired machine owned by the user or tenant.

Use it when an agent needs:

local files that cannot be uploaded
private network access
installed desktop apps
local credentials that should not leave the machine
customer-controlled hardware

Local devices are powerful but should be opt-in. The user should see exactly which workspace and agent can reach the device.

Primary device

Each workspace should have a primary device policy. Agents use it by default when a task does not specify a runtime.

Recommended defaults:

Workspace type	Primary policy
App builder	Sandbox Worker
Browser automation workspace	Computer
Enterprise RPA	Computer, with local device fallback
Customer-owned coding workspace	Persistent sandbox
Artifact factory	Sandbox Worker

The primary device can change over time, but historical runs should still record which device actually executed each action.

Persistence

Agent work should survive normal stops.

Runtime	Expected behavior
Persistent sandbox	Timeout stops compute and preserves state for resume
Non-persistent sandbox	Timeout destroys state
Computer	Stop/start preserves filesystem and desktop state
Local device	State stays on the user’s machine
Docker Deploy	App keeps running as a deployment until stopped or replaced

For agent-building workflows, persistent sandbox should be the default. Use non-persistent only for one-off untrusted jobs where the filesystem should be discarded.

Activity and timeout

Active agent work should reset the idle clock:

exec calls
file writes
terminal input
preview traffic
browser/computer actions
artifact generation
deployment publish
explicit extend calls

The UI and CLI should warn before a device is paused or destroyed. Long-running workflows should create snapshots at stable checkpoints.

Device permissions

Device access should be explicit:

Permission	Example
`devices:use`	Run commands or browser actions on an assigned device
`devices:create`	Create child sandboxes or computers
`devices:destroy`	Permanently delete a device and saved state
`devices:connect-local`	Pair or use a local device
`devices:set-primary`	Change workspace default device policy
`deployments:publish`	Promote workspace output to durable hosting

High-risk permissions should be gated by owner/admin roles or human approval.

Building virtual-device products

With these primitives, you can build products that look like an always-on agent workspace:

Workspace
  -> primary sandbox for code and files
  -> optional computer for browser/desktop
  -> connected accounts and managed connectors
  -> jobs and schedules
  -> artifacts and previews
  -> deployment targets

This supports products like:

24/7 research agents
browser automation workers
AI app builders
cofounder-style task operators
artifact generation studios
agent teams with shared files
customer-owned coding workspaces

Code, files, commands, previews, snapshots, and publish prep.

Desktop and browser automation for visual tasks.

Built-in tools, app actions, permissions, and product surfaces.

Durable app containers on a workspace appliance host.