Windows Node and Android Node are in testing. They are available to try, but compatibility and reliability are still being validated. An available installer does not mean every system, phone model or operation has been verified.
Personal describes who it serves; cloud describes where it runs
A personal agent is an assistant working on behalf of a person, often across ongoing tasks and services. It can run locally or in the cloud. A cloud agent runs its agent loop and some tools on remote infrastructure. These descriptions overlap, but do not imply the same access to the person's devices.
You might talk to such an agent from a phone while its actual runtime is in the cloud. It can search websites or use connected online services, yet still be unable to open a file on your work computer. The chat interface is not the execution environment.
Reasoning cannot substitute for access to a real device
Some tasks depend on a particular machine: editing a local repository, using installed engineering software, checking a home computer, reading logs on a GPU server, or operating an Android app. A cloud agent's own shell runs on its cloud machine. It does not gain these capabilities by reasoning better or by receiving a description of the target.
To act on the real device, there must be a reachable execution path. That path needs to know which device is meant, what tools it offers, who has access and how to return the result. A connector must actually perform the operation there. Without this path, the agent can suggest commands, ask you to execute them, or work on a copy in its own environment, but cannot complete the requested operation on the original device.
ADC is a service for this layer. An agent vendor can also build equivalent connectivity into its product, and existing networking plus remote execution can provide it. The necessary capability is device access; ADC packages discovery, authorization, tool routing and task records so different agents can reuse it.
Follow one request from your phone to a workstation
Consider an illustrative request sent from your phone: read the project logs on my Linux workstation, identify yesterday's error and run the existing check command. The cloud agent discovers authorized devices through ADC, selects the Linux workstation and sees its available folders and tools.
The agent chooses file.search and file.read to inspect logs, then a configured command template or shell.exec if the grant permits it. ADC checks the request and any required approvals, and routes it to the connector. The device runs the tool and returns output and task state; the agent interprets them and decides its next step.
The workstation needs the connector, the files and the programs the task requires. It does not need a second conversational agent just to receive the call. ADC does not invoke a model to generate the command, and its platform server is not where the user's command executes.
Phone: sends a task to your cloud agent
-> Agent: selects a device and tools
-> ADC: authorizes and routes each call
-> Linux Node: reads logs and runs the configured check
-> ADC: returns results and task state
-> Agent: explains the result and continuesDifferent systems contribute different capabilities
A Node is a device identity with advertised capabilities, not another copy of the model. A Mac can contribute a repository and local development tools; Linux can contribute a build environment, installed inference programs or access to a GPU; Windows can contribute desktop files and PowerShell tools; Android can contribute device state and supported app or interface actions.
Windows Node and Android Node are currently in testing. Windows installation and execution behavior continue to be validated; Android behavior depends on the phone model, OS and local permissions. macOS and Linux provide the available desktop connector paths. None of these labels promises that every installed application automatically becomes an ADC tool.
The agent must select the correct tool and syntax for the target. Bash on a Linux machine and PowerShell on Windows are different command environments. A GPU server is useful only if the local programs and permissions needed to use its hardware are present. Registering a Node supplies a route to capabilities, not missing software or drivers.
The opportunity is in combinations of devices
Once several devices are callable, an agent can place each step where its dependencies already exist. For example, inspect source on a Mac, invoke a build template on Linux, and read a check result from a Windows machine. This still needs an agent to coordinate the steps, compatible tools and suitable permissions; ADC supplies the device calls.
A shared laboratory or engineering team can expose selected test commands and results from equipment-connected computers. A personal assistant can inspect an authorized home machine when asked for help. An Android Node can add a supported screenshot or app action to a workflow whose reasoning runs elsewhere. These are directions and illustrative tasks, not a claim of an automatically implemented workflow for every application.
A locally registered MCP server can expose another service through a Node: a database, an internal system, or a hardware-control API. Credentials remain on that device. Supporting a television, printer, watch or instrument would require an actual connector or tool integration, an observable result and an access model. Calling it a future Node is a design direction, not a present compatibility claim.
Start with the task that your cloud agent cannot reach
Choose one task that truly needs a particular device, then identify its files, installed program or local service. Connect the device, create the access the agent needs and complete one call. Only then extend the workflow across additional Nodes. If a task lives entirely in an online service or the agent's existing sandbox, it may not need a physical device at all.
The Quickstart walks through device pairing and a first read. The integration guide explains how a cloud agent reaches ADC through MCP, CLI, Skill or a host plugin. The device guide covers local tools and platform status. Together, these turn the architectural idea into a request that actually reaches your machine.