Concepts

The key concepts behind AgentOS — how control modes, runtime modes, and capabilities fit together.

AgentOS has three core concepts that determine what it can do and how it connects to a target machine. While the concepts below involve OS-level services, kernel drivers, and hardware interfaces, you don’t need to understand these internals to use AgentOS. The installer handles the complexity — non-technical users can set up AgentOS through a guided UI without touching configuration files or the command line.

AgentOS is platform independent — it supports Windows, macOS, Linux, Android, and iOS Simulators (experimental), so the same agent code works across operating systems.

Control Modes

Control modes define how AgentOS connects to the target machine. There are two:

• Host Mode — AgentOS runs directly on the target as software. It uses OS-level APIs for screenshots, input, and window management. This is the most common setup.
• Companion Mode — AgentOS runs on a separate device and controls the target through hardware (USB, Bluetooth, HDMI capture) or device bridges (ADB, IDB). No software installation on the target is needed.

Both modes expose the same interface to your agent code — the SDK doesn’t need to know which mode is active.

Learn more about Control Modes →

Runtime Modes

Runtime modes define how AgentOS runs on the machine it’s installed on. There are two:

• Standalone — AgentOS runs as a regular process in the user’s session. Install via pip install askui-agent-os. Best for local development and testing.
• OS Service — AgentOS runs as a Windows system service with SYSTEM privileges. Install via the Service. Best for CI/CD, headless VMs, and enterprise deployments.

The runtime mode only applies to Host Mode. Companion Mode always runs standalone on the companion device.

Learn more about Runtime Modes →

Capabilities

Capabilities are the building blocks your agents use — screenshots, keyboard input, mouse control, window management, process management, and more. All capabilities are optimized for token cost efficiency, low latency, and cross-device communication.

What’s available depends on the combination of control mode and runtime mode:

	Host Mode (Standalone)	Host Mode (OS Service)	Companion Mode
Screenshots	Yes	Yes	Yes (HDMI capture)
Keyboard & mouse	Yes	Yes	Yes (USB/Bluetooth HID)
Window & process management	Yes	Yes	—
RDP resilience	—	Yes	—
Logon screen & CTRL+ALT+DEL	—	Yes	—
Mobile devices (ADB/IDB)	—	—	Yes

See all Capabilities →

Administrator Rights (Windows)

AgentOS consists of two components: the AgentOS Service and the Remote Device Controller (internally called the Execution Engine in installer parameters). Each can run elevated (with administrator privileges) or non-elevated (standard user privileges). Elevation determines what your agent can interact with — Windows prevents non-elevated processes from sending input to elevated applications.

Session 0 vs Interactive Session: Windows runs services in Session 0 — an isolated, non-interactive session with no desktop. Users log in to Interactive Sessions (Session 1, 2, …) where the desktop and GUI applications live. The AgentOS OS Service runs in Session 0 but attaches to the user’s interactive session to control the desktop. This is why it can keep automating even when no user is logged in or an RDP session disconnects.

Standalone

Component	Default	Elevated
AgentOS	Not elevated (recommended)	Run with admin rights
Remote Device Controller	Not elevated (recommended)	Run with admin rights

In standalone mode, both components run with the privileges of the current user. This is sufficient for most development scenarios. Only run with admin rights if you need to automate applications that themselves run as Administrator.

OS Service

Component	Default	Configurable
AgentOS	Elevated (SYSTEM)	—
Remote Device Controller	Not elevated (recommended)	SERVICE_EXECUTION_ENGINE_ELEVATED=1

The OS Service always runs AgentOS as SYSTEM (elevated). The Remote Device Controller defaults to non-elevated, which is recommended. Enable elevation for the controller only if your agent needs to interact with applications running as Administrator.

We recommend the principle of least privilege: keep both components non-elevated unless your agent specifically needs to automate admin-level applications. Only elevate what is necessary.

If your agent can’t interact with an elevated application, see Troubleshooting.

How They Fit Together

Think of it as two independent choices:

1. Control mode — How do I reach the target? Software on the target (Host) or hardware from outside (Companion).
2. Runtime mode — How does AgentOS run? As a regular process (Standalone) or as a system service (OS Service).

Your agent code stays the same regardless of the combination. The SDK connects to AgentOS via gRPC, and AgentOS handles the rest.

Control Modes

Host Mode vs Companion Mode.

Runtime Modes

Standalone vs OS Service.

Capabilities

Full capability matrix.