A task-dispatch architecture that enables Orion beings on separate devices to discover, communicate, and coordinate — without requiring the user to relay through third-party applications.
"You shouldn't need to open Telegram to tell your server to restart, or paste a log into Discord so your laptop can read it. The beings should just talk to each other."
— Robert Perry
We present a cross-device coordination architecture for autonomous beings. In existing workflows, users act as the communication layer between their own devices — copying outputs from one machine, relaying commands through messaging applications, or manually establishing remote sessions. Our system eliminates this overhead. Each device runs an Orion being that automatically registers itself, discovers peer devices, evaluates their capabilities, and dispatches tasks to the appropriate target. Communication is asynchronous and non-blocking: neither the sending nor receiving being halts execution during the exchange. All transmissions are encrypted in transit and scoped to authenticated accounts. We describe the architecture, its security model, and demonstrate its behavior through two real-world coordination scenarios.
A typical user operates multiple devices: a laptop for development, a server for deployment, a phone for communication. Each device has distinct capabilities, file systems, and tool access. Yet these devices exist in isolation — they have no awareness of each other, and the user must manually bridge them.
The current approach to cross-device coordination relies on the user as the routing layer. To move information from a server to a laptop, the user opens an SSH session. To trigger an action on a remote machine, the user sends a command through Telegram, Discord, or a similar messaging application. The user becomes the bottleneck, manually serializing operations that should be parallel and autonomous.
This paper introduces an architecture where Orion beings on separate devices coordinate autonomously. The user states an intent once — the beings discover which device can fulfill it, dispatch the task, and return the result. No third-party application is required in the communication path.
Figure 1. Left: devices operate in isolation; the user manually bridges them. Right: Orion beings on each device discover and coordinate with each other autonomously.
We identify three deficiencies in how users currently coordinate across devices:
Third-party relay dependency. To send a command from a laptop to a server, users rely on external applications — Telegram bots, Discord channels, Slack integrations, or manual SSH sessions. Each introduces a separate authentication surface, a separate interface to manage, and a dependency on a third-party service's availability.
Synchronous, blocking interaction. When a user initiates a remote operation, they typically wait for the result before proceeding to the next task. The user's attention becomes the serialization point, limiting throughput to one device interaction at a time.
No capability awareness. The user must remember which device has which tools, files, and hardware. There is no automated mechanism for one device to query another's capabilities or determine the optimal target for a given task.
The user should not be a message router between their own devices. The devices should coordinate among themselves, and the user should only need to express intent.
The system consists of three components: a device registry for discovery, a task-dispatch protocol for coordination, and a capability-aware routing layer that determines which device should handle a given request.
When a device comes online, its Orion being registers itself in a shared device registry scoped to the user's account. The registration includes the device identifier, hardware profile (processor, memory, operating system), available tools and services, and current status (idle, processing, or offline). Other beings on the same account can query this registry to discover available devices and their capabilities.
Discovery is automatic. No configuration files, port forwarding, or network setup is required. Devices on different networks, in different countries, behind NATs — all register to the same account-scoped registry and become visible to each other.
When Being A determines that a task should be handled by Being B, it writes a task to Being B's device queue through the shared infrastructure layer. The task contains the instruction, the execution mode, and the source device's context (enabling the receiving being to respond). Being B asynchronously picks up the task from its queue, processes it, and can dispatch a response back through the same mechanism.
The sender briefly confirms delivery, then resumes its own execution. It does not wait for the remote task to complete — only for the task to reach the target's queue. Once confirmed, both beings continue their respective work independently. This decouples dispatch from execution and eliminates the synchronous bottleneck present in traditional request-response patterns.
Figure 2. Being A queries the device registry, selects Being B based on capabilities, and writes a task to B's queue through the coordination layer. Being B picks up the task asynchronously and dispatches the result back.
The routing decision — which device should handle a given task — is made by the being itself, not by the user. When a user says "deploy the API update," the laptop being queries the device registry, evaluates which registered device has deployment tools and server access, and dispatches the task to that device. The user does not need to specify the target.
Users can also override this with explicit targeting. The @device syntax allows direct dispatch to a named device, bypassing the automatic routing decision.
@server pull the last 100 lines of the API error logThe user names the target device. The being dispatches the task directly to that device's queue without evaluating alternatives.
"Deploy the API update" → being discovers server, dispatches taskThe user states intent without naming a device. The being queries the registry, evaluates device capabilities and status, and selects the optimal target autonomously.
Existing agent systems use a synchronous request-response model: the agent sends a request, blocks execution, and waits for the response before proceeding. This is equivalent to a blocking I/O call — the agent is idle for the entire duration of the remote operation.
Orion uses a non-blocking dispatch model. When Being A dispatches a task to Being B, it confirms delivery to B's queue and then resumes its own execution — it does not wait for the task to complete. Being B picks up the task asynchronously, processes it without interrupting its own workload, and dispatches the result back when ready.
Figure 3. Left: synchronous model where the sender blocks during remote processing. Right: Orion's asynchronous model where both beings continue execution.
In conventional agent systems, the majority of wall-clock time is spent waiting — not computing. Non-blocking dispatch reclaims that time. Both beings are always executing useful work.
Cross-device coordination introduces a larger attack surface than single-device operation. Our security model addresses three vectors: unauthorized access to the device registry, interception of dispatched tasks, and impersonation of a registered device.
The user's authenticated account defines the trust boundary. A being outside the account cannot discover, contact, or impersonate any device within it. A compromised external account cannot access another account's registry or task queues.
We compare the Orion coordination model against three baseline approaches: the standard single-device agent, the third-party relay pattern (using messaging applications as the transport layer), and manual remote access.
We demonstrate the coordination model through a production debugging scenario. The user's API begins returning 500 errors. The user issues a single instruction to their laptop Orion. The following sequence occurs autonomously:
"The API is throwing 500 errors. Figure out what's wrong and fix it."Case Study 1 (projected). Three beings across three devices coordinate to diagnose and resolve a production incident. The user issued one instruction. No third-party application was used in the communication path.
A new server is added to the user's fleet. Rather than manually configuring it, the user instructs the existing production being to transfer its configuration to the new server's being.
"Set up the new server to mirror production. Match all versions, configs, and security policies."Case Study 2 (projected). The production being dispatches its full configuration to the new server being. The new server applies every setting autonomously. No SSH, no copy-paste, no configuration management tool.
The coordination model described in this paper is not specific to laptops and servers. The same pattern — autonomous discovery, capability-aware routing, non-blocking task dispatch — applies to any domain where independent agents must coordinate without a centralized controller.
Figure 4. A drone detects an obstacle and dispatches a reroute task to a peer drone. The same coordination primitives apply: discovery, dispatch, no blocking.
One drone detects an obstacle and dispatches a reroute instruction to nearby drones. No centralized flight controller required for peer coordination.
A robot that completes its task early queries peer status and dispatches assistance to an overloaded peer. No central dispatcher bottleneck.
The lead vehicle detects a hazard and dispatches a braking instruction to the following vehicle, which propagates it down the chain. Latency is minimized by removing the central relay.
A smoke detector dispatches an activation task to the nearest sprinkler. No single point of failure in the response chain.
We have presented a cross-device coordination architecture for autonomous beings. The system eliminates the user as the communication layer between their own devices. Instead of relaying commands through Telegram, Discord, SSH, or any other third-party application, the user states intent once and the beings coordinate autonomously.
The architecture comprises three components: an account-scoped device registry for automatic discovery, a non-blocking task-dispatch protocol for asynchronous coordination, and a capability-aware routing layer that selects the optimal target device without user specification. All communication is encrypted in transit and scoped to authenticated accounts.
The same coordination primitives — discovery, capability-aware routing, and non-blocking dispatch — generalize beyond computing devices to any domain where autonomous agents must coordinate: drone swarms, warehouse robotics, vehicle platoons, and sensor networks.