Dan Peng
Built for the Device Boundary
Most software agents operate inside a browser, a desktop session, or a cloud API. They are effective when the environment exposes a stable DOM, accessibility tree, command interface, or application API. Aiden is designed for a different class of problem: tasks where the important state exists on a real phone or physical device, and the agent must interact with what is actually displayed.
Aiden treats the device boundary as a first-class part of the agent runtime. The target phone, screen-capture path, firmware services, input provider, and task state are connected as one workflow. This makes the agent responsible for more than producing an instruction. It must observe the device, choose an action, execute it through the available transport, and determine whether the device reached the expected state.
Beyond Browser and PC Agents
A browser agent usually works through page structure and browser APIs. A PC agent often depends on a particular desktop session, fixed keyboard and mouse mappings, or application-specific integrations. These approaches can become fragile when a mobile interface changes, when an application does not expose enough structured information, or when the task must continue outside the original computer session.
Aiden is built around visual device state instead. It can reason from the screen that a person would see, including interfaces where the useful state is not available as a convenient API. After an input action, the agent can request another screen state and use the result to decide whether to continue, retry, wait, or ask for help.
The input path is also replaceable. Android ADB, HID, and compatible HTTP environment bridges can provide the underlying device control while the agent keeps the same task-level action model. A tap, gesture, keyboard shortcut, or text entry does not need to be rewritten for every transport. The provider handles the device-specific details, such as connection status, coordinate range, input format, and supported capabilities.
This is different from a fixed macro or remote-control script. A macro assumes that the screen is still where it was before the previous action. Aiden can re-observe the screen after an action and adapt to the state it actually finds.
Runtime Support for Long Tasks
A multi-step device workflow has timing problems that a single chat request does not solve. A screen may take time to update. A tool may return late. A user may need to approve an action or take over the phone. A voice conversation should remain responsive even while a longer operation is running.
Aiden separates the foreground interaction layer from the backend task executor. The foreground agent can listen, speak, receive an interruption, and communicate task updates while the backend handles a longer visual workflow. Tasks have an explicit lifecycle and can be queried, cancelled, paused for a required user action, and resumed with their execution identity and device context.
This separation also makes device ownership clearer. A task that controls one screen and one input path should not silently compete with another task for the same device. The runtime can keep execution serial and observable while still allowing the conversation layer to remain available.
Memory Connected to Real Work
Aiden's memory is intended to support device workflows, not simply store an ever-growing chat transcript. Screen and notification data can be extracted, deduplicated, validated, given a source and confidence, and cleaned up when it expires. Crash-safe and idempotent writes reduce the risk of creating partial or duplicate records when a request is retried.
Supported hardware can also provide a physical quick-capture path. A GPIO trigger can save the current screen as a searchable snapshot, allowing an important message, reminder, or device state to be recalled later. The saved content remains associated with where it came from and how confident the system is in the...
Read more »