Device fleet and desktop

A device is a computer that runs a small worker and takes shell commands from your agents. An agent runs a command on it with exec_command and the machine's deviceId, in a conversation or in a routine. Because the same worker can drive the desktop, an agent can also open an ERP client, read a window and fill a form on a machine that has no API to call.

Personal and managed machinesCopy Anchor Link

An agent uses a machine when two things hold: its definition holds the machine as a grant, and the person it acts for is allowed to use the machine. That person is the one in the conversation, or the routine's creator on an automatic run. A routine whose creator loses access to the machine stops being able to use it.

On a managed machine, the owner and every devices: manage holder (the owner role has it) can rename it, revoke it, change its runners and decide whether agents may run commands on it. An agent acting for a devices: manage holder uses the managed machines its definition holds, but manages none of them unless the agent holds devices: manage too. Runners are people you let use the machine without managing it. Add them under Settings → Agents → Devices, in the same access panel used for other resources.

A managed machine that agents may execute on runs its runners' commands without an approval card: that decision was made when it was enrolled or switched on by an administrator.

Enroll a machineCopy Anchor Link

Under Settings → Agents → Devices, create a token and copy the command for your system: Enroll your computer makes a personal token for your own machine, and Enroll machines, for devices: manage holders, a fleet token. The installer comes with the platform release and installs the worker as a service for the current user.

# macOS and Linux
curl -fsSL https://get.standards.new/device | sh

# Windows
irm https://get.standards.new/device.ps1 | iex

The command asks for the token. The token is never an argument, so it does not appear in a process list or a shell history; for a script, set STANDARDS_ENROLL_TOKEN instead.

A token reads stndrds_enroll_<tenantId>.<secret> and is shown once.

Settings lists every token with its uses and expiry, and revokes one at any time; a revoked token enrolls nothing more. A machine already enrolled stays. A token whose creator has left the workspace, or a fleet token whose creator no longer holds devices: manage, enrolls nothing either.

Enrolling again from a machine that already has a device needs that machine's current credential, which the worker keeps in its own store. A machine reinstalled from scratch is a new device: an administrator revokes the old one.

Platform notesCopy Anchor Link

• macOS: the worker needs Accessibility. On a single machine you grant it once in System Settings. For a fleet, an MDM profile with a Privacy Preferences Policy Control payload grants it without a person.
• Windows: the worker needs an interactive session that stays unlocked, so a scheduled task starts it at logon. It is not a Windows service.
• Linux: Ubuntu 24.04 or later with GNOME, on X11 or Wayland, with AT-SPI available. The worker runs as a systemd --user service of the graphical session.

Each machine's row shows whether its desktop is ready, or why not (permission missing, no desktop session, unavailable).

Shells on a machineCopy Anchor Link

A conversation gets its own shell on each machine it uses. Unlike the agent's sandbox, which starts a fresh shell for each command, cd, exported variables and an activated virtual environment carry over from one call to the next. This needs an up-to-date worker, the standards-device service or the desktop app; on an older worker each command starts a fresh shell and background is not available. Commands are not interactive: standard input is closed.

• background: true starts a command and returns a process id and a log path at once; the agent reads the log with tail. A shell keeps at most 8 background processes, with 1 MB of log each.
• A machine holds at most 4 shells, so up to 4 conversations work on it at the same time. Inside one conversation, commands run one at a time.
• A shell is released when you press Stop, when the conversation is archived, or after 15 minutes without a command.

Finished commands, their output included, are kept for 30 days.

The desktop skillCopy Anchor Link

On a machine whose desktop is ready, agents get the built-in skill agent-desktop. It teaches them to run agent-desktop through exec_command with that machine's deviceId, and to read the tool's own guides before the first command. Output is the window as text with element references, which the agent then clicks and fills.

By default an action goes through the accessibility API, without moving the pointer or taking focus. When an element offers no such route, for example a message field in some apps, an agent can run the step with --headed, which uses real clicks and keystrokes on that element. The cursor moves and the window comes to the front, so this interrupts anyone using the machine.

Standards refuses no agent-desktop command: screenshots, the clipboard, mouse coordinates and sessions are all available to an agent that holds the machine. A screenshot also needs Screen Recording on macOS.

Each conversation's shell sets AGENT_DESKTOP_SESSION to that conversation, so by default the element references one conversation reads do not resolve in another.

Next stepsCopy Anchor Link

• Agents and routines — granting a machine to an agent or a routine.
• Roles and permissions — the devices capability.
• Cloud browsers — the hosted browser for sites.
• Book a demo