Agent Device Cloud

Why separate the agent from its devices?

Your agent may run in a cloud service, an IDE or another computer, while the work requires a repository on your Mac, dependencies on a Linux server or an app on your phone. Those environments already exist. You should be able to use them without first moving every file and dependency to the agent's own machine.

ADC turns those devices into tool targets. One agent can use several authorized devices, and several agents can reuse one device with separate grants. The target needs a connector and the local programs the task requires, not another model account or agent loop.

Read the design motivation and its limits

When a personal agent runs in the cloud

A personal agent may work on your behalf from a cloud runtime while you talk to it from a phone. Its cloud tools can reach online services, but your computer's files, installed programs and phone apps require a separate device execution path.

When a task must happen on the original device, that access layer is necessary. ADC supplies it as a reusable service: discover the device, expose its actual tools, authorize the caller, execute there and return results. An agent vendor can also provide this layer internally.

Read why cloud agents need a device access layer

What happens when an agent calls a tool

1. 01Your agent

   Calls the model, plans the steps, selects a device and supplies tool arguments. This is where the intelligence lives.

2. 02ADC service

   Discovers devices and tools, checks access and any required approval, routes the call and tracks its result. It does not call a model.

3. 03Your device

   The connector validates the request, runs the local tool and returns its result. A target device does not need another conversational agent.

Example: an agent builds on your Linux machine

After setup, the agent discovers a device called Build Linux and its authorized /work/project folder. It sees that the device runs Linux and offers shell.exec. The agent writes a Bash command, selects that device and submits a call such as this:

{
  "target": {
    "nodeId": "node_build_linux"
  },
  "tool": "shell.exec",
  "args": {
    "cwd": "/work/project",
    "command": "npm run build",
    "timeoutMs": 120000
  }
}

This is the relevant part of the request; clients also attach identity, authorization and idempotency fields. ADC checks the call, waits for approval if configured, and dispatches it. The connector runs npm on the Linux machine, where npm and the dependencies must already be installed. It returns output, exit status and a receipt. Your agent reads those results and decides whether to fix the code or continue.

ADC does not translate Bash into PowerShell, generate a command with another model, or run the build on its platform server. Naming a working directory also does not sandbox a shell process: execution uses the connector's configured operating-system permissions.

Choose how to call the service

MCP exposes callable tools and schemas. CLI offers commands to agents, scripts and people. The Skill teaches an agent how to use those commands. Plugins add host-specific setup and context. They all reach the same ADC service and device authorization; they are not separate products or execution locations.

You can use ADC with your existing agent without adopting Zioon's Runtime or memory service. A developer can also use the HTTP API or SDK to put device capability into an application.

When it helps, and where it stops

ADC is useful when execution environments are spread across devices or shared with other people: development and training machines, private services, home devices, and team-owned tools. It does not supply the reasoning or business logic of the workflow. A knowledge base still needs its own retrieval service; the agent still coordinates the steps.

If the agent already has all it needs on one local computer, you may not need another service. SSH and remote desktop can remain appropriate for their own workflows. Today, ADC supports desktop connectors, Android and registered local MCP providers; other devices need an explicit integration before they can become usable targets.

Different systems, different Nodes

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.

A Node represents the capabilities its connector advertises. Operating systems do not all provide the same tools. Local permissions, installed software, online presence and the Agent grant still determine what can run.

The opportunity is to combine their capabilities: a repository on a Mac, a build or inference environment on Linux, a local Windows tool, or a supported Android app action. A Node supplies the execution environment and interfaces; the agent still coordinates the workflow.

Start here

Four terms to know

Device

A computer or phone running the ADC connector. It connects out to ADC and never needs an open port.

Agent access

A revocable permission for one agent: which devices, folders and tools it may use.

Approval

An optional rule that makes writes, commands or every call wait for you.

Activity

The record of every call: which agent, which device, the decision and the device's receipt.