Why separate an agent from the devices it works on?

A task that spans several devices

Consider a developer with source code on a Mac, a Linux machine with a configured build environment, and a GPU server with training data. The developer asks an agent: inspect the code, run the build on Linux, then check the training logs. This is an illustrative workflow, not a published benchmark or a claim that ADC has completed it automatically.

The agent already knows how to read files and run commands. The missing piece is access to the machine where each step belongs. Copying every repository, dependency, credential and dataset into the agent's own environment may be unnecessary, expensive or prohibited. Installing a separate agent on every target is another possible approach, but it adds agent instances to manage when all the task needs is access to those devices' tools.

The agent and the execution environment do not have to be the same machine. One agent can request a file read on the Mac, a build on Linux and a log read on the GPU server. Conversely, different authorized agents can use the same device. Shared access still depends on the device owner and the grant assigned to each caller.

The agent plans, ADC routes, the device executes

The agent or its Runtime calls the model, interprets the request, chooses a tool and target, writes the command, and decides what to do with the result. ADC does not run another model to rewrite commands, plan steps or summarize the user's task. Model usage belongs to the agent service you selected.

ADC provides the common entry point: device discovery, current capabilities, authentication, authorization, optional approvals, routing, task state and activity records. Calling it a router describes its place in the architecture, but does not mean it is a stateless byte forwarder. It also keeps the records needed to operate the service.

A connector on the target device exposes local tools, validates the request and executes it. The target computer needs the connector and the programs required by the task, but does not need its own conversational agent or model API key merely to serve as an execution device.

Agent / Runtime
  chooses: shell.exec on Build Linux
  supplies: npm run build
          |
          v
ADC
  checks access and approvals
  routes the call and tracks its state
          |
          v
Connector on Build Linux
  executes with the configured local permissions
  returns stdout, stderr, exit code and receipt

MCP, CLI, Skill and plugins are ways to use the same service

MCP exposes tools and their input schemas to a compatible client. The CLI makes the same service accessible to an agent with a shell tool, to a script, or to a person. The Skill describes how to discover devices, invoke tools and follow tasks through the CLI. Host plugins can provide guided setup and device context, depending on the capabilities of that host.

These are not separate execution backends. Changing from MCP to CLI does not move the work onto the ADC server or remove the grant. The important decision is which agent will request work, which device should execute it, and which authorization connects them.

• Use a real device ID and an authorized directory from discovery, not the example values.
• The directory must permit execution and be writable; npm and the project dependencies must already exist on the target.
• Use Bash syntax on macOS/Linux and PowerShell syntax on Windows. ADC does not translate commands between operating systems.

adc connect my-agent
adc node list --json
adc tool show shell.exec --json
adc invoke shell.exec --node node_build_linux \
  --args '{"cwd":"/work/project","command":"npm run build","timeoutMs":120000}' \
  --idempotency-key build-project-001 --wait 4000 --json

From personal devices to shared execution environments

For an individual, the value may be using a home computer or server from an agent running somewhere else. For a team, several engineers' devices can hold distinct dependencies, private services or hardware. Sharing lets the owner make specific capabilities available to named people rather than requiring every collaborator to rebuild the same environment.

This is why permissions belong in the product. They make a shared environment usable without treating registration as blanket access. An administrator can define team device access; each person still connects their agent through its own grant. Approval and revocation remain operational controls, not a promise that arbitrary shell execution becomes harmless.

The boundary of this infrastructure

ADC supplies device access, not the intelligence or business logic of a workflow. A knowledge base decides how information is stored and retrieved; a business integration defines its own operations; the agent coordinates the task. ADC makes an authorized device or local tool reachable when that task needs it.

ADC can be used independently through supported clients or as the device service in Zioon. Using ADC does not require migrating to Zioon's Runtime or memory service. Self-hosting runs the same application and protocol under the operator's control; it does not create a second product with fewer authorization checks.

The wider idea is to expose more real-world execution environments to agents. macOS and Linux provide the available desktop paths; Windows Node and Android Node are in testing, and registered local MCP providers add further tools. A watch, television or printer needs an implementation, advertised capabilities and an access model before it can become a usable Node.

Evaluate it with a real task

If your agent already runs on the only computer it needs and has suitable local tools, ADC may add little. If you already operate SSH with a maintained task system, that may be the right solution. ADC is worth trying when device discovery, multi-device access, local tools and shared permissions are work you would otherwise have to assemble yourself.

Start by naming the device and environment the task really needs. Then check that you can discover it, call its tools, inspect a result and revoke access. This tests a concrete benefit; it is more informative than counting supported interfaces or claiming that every agent needs another platform.