Concepts

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.

Runtime mode is independent of control mode — both Host Mode and Companion Mode can run as Standalone or as OS Service. Higher privileges (OS Service) unlock additional capabilities such as RDP resilience and access to the Windows logon screen. 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: 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.

​

Standalone

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

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. If your agent can’t interact with an elevated application, see Troubleshooting.

​

How They Fit Together

Think of it as two independent choices:

1. Runtime mode — How does the AgentOS binary start, and with which privileges? Started by an external program (Standalone, user privileges) or registered as a system service (OS Service, SYSTEM privileges).
2. Control mode — What does it control once running? The local host (Host) or a separate device through a protocol (Companion).

Both runtime modes can be combined with both control modes. Your agent code stays the same regardless of the combination — the SDK connects to AgentOS via gRPC, and AgentOS handles the rest.