A Forecast: Everyone Will Have a Fleet of Productivity Devices

AuraBaba believes that every person will own more device assets over time. They will not all sit on the same desk or come from the same vendor: there may be a personal computer for communication, a Mac mini that stays on 24/7, a Tencent Cloud workstation for long-running jobs, a phone that is always nearby, and a fixed-IP server dedicated to API integrations and distribution.

These devices are more than “the computers I happen to own.” Together, they become a person’s general-purpose productivity toolkit. Each has a different operating system, installed software, account set, network, compute profile, and online schedule. The questions therefore change: Which device should execute a task? Who takes over when it goes offline? How do browsers, files, and credentials move with the task safely? How does a request made from a phone finish on a remote device and report back?

That is the product problem of multi-device management. It is not turning every computer into one remote desktop, and it is not syncing an entire hard drive to the cloud. It is registering each device’s capabilities, routing the right work to the right place, and returning the result to one shared workspace.

The short version: devices become productivity assets

In the past, one main computer was usually the center of a person’s work. If it failed, they replaced it; if they needed more compute, they rented a server temporarily. The future looks more like a small team of specialized devices:

The goal is not to make these devices look identical. It is to acknowledge their differences and use them. People should communicate and make judgments on the device best suited for that; agents should execute on the device best suited for execution.

What multi-device management actually manages

“The device is online” is only the shallowest layer. Useful device management should answer at least six questions:

1. What is it? Which person and workspace own it, and what is it used for?
2. Can it work right now? Is it online, when was its last heartbeat, and are its disk and network healthy?
3. What can it do? Is it macOS, Windows, or Linux? Does it have a browser, GPU, specific CLI, editing software, database tools, or a fixed IP?
4. How long can it work? Is it only online while someone is using it, or can it run continuously? Can it recover after interruption?
5. What is it allowed to do? Which projects, accounts, and APIs can it access, and which actions need human confirmation?
6. What happens when something fails? Can the task queue, retry, move to another device, and preserve its artifacts and logs?

A device asset record should therefore include more than a name and an online/offline badge. It needs capability labels, cost, network location, software versions, permission scope, and recent task history. For an agent, a device is not an ambiguous “remote machine”; it is an execution environment that can be searched and selected.

The relationship can be pictured as one chain:

Person / phone
   ↓ start, inspect, approve
Workspace / project / issue
   ↓ describe goal, inputs, acceptance
Agent + skill
   ↓ select required capabilities
Device runtime
   ↓ execute commands, browser, or local apps
Results, logs, artifacts, and status
   ↓ return for human review

This is a natural extension of AuraBaba’s runtime model today: a daemon connects a local or cloud machine to the workspace, the assigned agent executes through the appropriate device, and the result returns to the issue timeline. The next step is to make “the appropriate device” more precise, explainable, and automatic. See Install an Agent Runtime for the foundation.

Four concrete scenarios for a device fleet

Scenario 1: a Mac mini stays on 24/7, and the task needs a browser

A Mac mini is a useful always-on workstation at home or in an office. It has a manageable power profile, does not occupy someone’s main computer, and can keep a project directory, command-line tools, and a browser environment available.

Consider a recurring task: every night, an agent signs into a supplier portal, downloads the previous day’s order data, creates a summary, and posts the report to a project issue. This is not necessarily a script-only job. The portal may require a login, pagination, a download button, a popup, or a preserved browser session. Running it on a personal PC introduces interruptions: the user may shut down, sleep, occupy the window for a meeting, or accidentally close the browser.

A better division of labor is:

1. Install the daemon, agent CLI, browser, and required tools on the Mac mini.
2. Register capabilities such as browser, macos, and always-on, with an allowlist for browser domains.
3. Create an issue or Autopilot that defines the data range, report format, and failure-reporting location.
4. When the scheduler sees that the task needs a browser and the Mac mini is online, route it there.
5. Return the downloaded source file, script log, and summary to the issue; send, delete, and submit actions go through human review.

The important idea is not “control a Mac remotely.” It is treating the browser as a declared, authorized, auditable device capability. Browsers increase risk: a session may contain personal information, and a page may try to persuade an agent to perform an unsafe action. Browser jobs should use an isolated profile, domain allowlists, least-privilege credentials, and explicit approval gates.

If a data source has an API, use the API first. Use a browser only when web interaction is genuinely required. The Mac mini’s value is not that it clicks every page forever; it is that it provides a stable execution path for real systems that do not expose an API.

Scenario 2: a Tencent Cloud workstation does not need a browser login

Cloud devices are often misunderstood as “a computer moved into a browser.” Many cloud tasks do not need the Tencent Cloud console at all, and a browser login should not be a prerequisite for execution.

Suppose a project needs to transcode a batch of videos overnight, run an analysis, build an installer, or perform a migration preflight that takes several hours. The desired output is an artifact and a log, not an agent clicking “Log in to Tencent Cloud” in a web console.

A headless cloud path can work like this:

• Create, start, stop, and inspect cloud resources through controlled provider APIs or deployment tools.
• Run the AuraBaba daemon on the server so it registers as a workspace runtime through a secure outbound connection.
• Execute through SSH, a CLI, containers, or project scripts without a Tencent Cloud console session.
• Read inputs from project documents, issue attachments, or object storage, and return artifacts and logs to the workspace.
• Declare capabilities such as linux, headless, long-running, and high-cpu.

There is a practical benefit: the control plane and execution plane are separate. A person can inspect the cloud workstation, adjust a task, or approve a result from a phone or personal PC while the long-running work continues remotely. Closing a laptop does not stop the job.

Cloud runtimes still need cost and lifecycle management. Should the instance stop after the task? How many retries are allowed? How long should intermediate files remain? Can a network retry cause duplicate execution? A cloud workstation is not unlimited free background capacity; it is a productivity asset with cost, permissions, and a lifecycle.

Scenario 3: a phone is a mobile control plane, not a smaller PC

The phone’s value is not replacing a desktop. It is always nearby and well suited to capture, notifications, and critical confirmations.

A typical flow might start with someone photographing a whiteboard and adding a voice note from the road. The phone uploads the evidence to a project; an agent identifies action items and creates an issue; a remote Mac mini or cloud workstation organizes the material and drafts a plan; the owner receives an approval request before anything is sent to a customer.

A phone can act as:

• An entry point: dictate an idea, photograph a field problem, or create a task quickly.
• A dashboard: see which devices are online, how far a long-running job has progressed, and where work is blocked.
• An approver: confirm publishing, sending, deletion, payment, or an online configuration change.
• An alarm: receive device-offline, task-failure, budget, or fixed-IP service alerts.
• A temporary terminal: pause work, add parameters, or switch execution devices when a computer is unavailable.

A phone should not handle large builds, long video transcodes, or complex desktop automation. Its job is to reliably carry “what I want to do” and “whether I approve the next step” to the workspace, then bring the result back to the person.

That changes mobile design priorities. The mobile client does not need to reproduce the entire desktop console; it should make notifications timely, context sufficient, approvals unambiguous, offline recovery predictable, and sensitive information safe from lock-screen leaks.

Scenario 4: a daily assistant connects a personal PC, remote devices, and a fixed-IP server

This is one of the most practical combinations. A personal PC has WeChat, Tencent Meeting, and the videos that need editing. It is the best place for communication, quick changes, and final judgment, but it should not carry every 24-hour job.

The same work may also need:

• A remote device for hours-long transcoding, rendering, batch cleanup, or data processing.
• A fixed-IP server for external APIs, webhooks, and public-account distribution.
• One project context where meeting decisions, video assets, scripts, and publishing results remain connected.

A day of work might look like this:

Personal PC: Tencent Meeting, WeChat, editing, and human judgment
       ↓ meeting notes / assets / task brief
Workspace: issue with inputs, deliverables, approver, and deadline
       ↓ capability-based routing
Mac mini / cloud workstation: transcode, render, batch, draft
       ↓ reviewed structured result
Fixed-IP server: public-account API, callbacks, and distribution
       ↓ status, receipts, and logs
Phone: notify the owner and confirm publish or next step

Here is a concrete example: an afternoon Tencent Meeting decides that a product demo should become a 60-second video and be posted to a public account at 9:00 the next morning. Once the meeting notes enter the project documents, an agent creates an issue listing the source footage, intro/outro requirements, subtitle format, public-account draft, and reviewer.

1. The personal PC remains available for WeChat and meetings instead of being occupied by a long transcode.
2. A cloud workstation or Mac mini handles media cleanup, transcoding, and a first subtitle draft, then returns a preview and checksum to the issue.
3. The owner reviews the preview, title, cover, and copy on the phone or personal PC.
4. The fixed-IP server uses a restricted public-account API credential to create a draft or perform the approved distribution action.
5. The API receipt, publishing time, failure reason, and final link are written back to the issue.

The fixed IP is not a symbol that the server is “more powerful.” It is part of the service’s network identity. External APIs, webhooks, or enterprise firewalls may require an allowlist, so placing that integration behind a stable egress reduces failures caused by changing IPs. The fixed-IP server should not receive every project permission in return; it should have only the credentials needed for the API and require approval before public distribution.

Route by capability, not by device name

“Give this to Alex’s computer” is not a stable task definition. Alex may replace the computer, the machine may be offline, or the work may need a different tool. A more durable approach is to state requirements:

task:
  duration: long
  needs:
    - browser
    - macos
    - project-files
  network:
    outbound: approved-domains
  approval:
    before: external-publish

The device declares what it can provide:

device:
  name: office-mac-mini
  capabilities:
    - macos
    - browser
    - always-on
    - local-media-tools
  policy:
    browser_domains:
      - supplier.example
    external_publish: approval-required

The scheduler can then make an explainable choice: Why did the work go to this device? What other candidates exist? If the device is offline, can the task move to the cloud? If no device meets the conditions, should the task wait instead of running unsafely?

The routing decision should appear in the issue. Users do not need every daemon log, but they should see “this task needed a browser, so it went to the office Mac mini,” “this task needed a fixed IP, so it went to the API server,” or “the device is offline, so the task is queued.” Explainability is a prerequisite for trust.

A development forecast: make the device a first-class asset

Multi-device management should not start as a complicated universal remote-control console. A more practical sequence is to establish a common device model, then add scheduling and automation in layers.

Phase 1: device registration and capability descriptions

Start by answering “which devices do I have?” and “what can each one do?”

• Associate devices, runtimes, agents, and working directories with stable identifiers.
• Report operating system, agent CLI, software versions, network information, and capability labels.
• Record online heartbeats, last connection, health, and current task.
• Let users name, group, describe, and schedule maintenance for devices.
• Mark browsers, fixed IPs, GPUs, and private-network access explicitly instead of guessing from a name.

The acceptance bar for this phase is simple: a user can open the device list and understand whether each machine can accept work and why.

Phase 2: capability routing and recoverable execution

Once device records exist, real scheduling becomes possible:

• Issues or Workflows declare system, browser, compute, network, and duration requirements.
• The scheduler selects a runtime by capability, availability, cost, and permission.
• A task enters a queue before the device binds it to a work directory and session.
• A short outage preserves task state; the task resumes or retries according to policy.
• An idempotency key prevents a network retry from publishing twice, charging twice, or creating duplicate resources.
• The system records the routing reason, attempted devices, and each retry result.

Separate session continuity from disk synchronization. Continuity means that an agent knows what the previous run completed; it does not mean copying an entire local disk between machines. Project facts should return to the workspace, while devices keep only the local cache and working directory required for execution.

Phase 3: browsers, mobile, and network identity

This phase creates visible differentiation and higher risk:

• Use isolated browser profiles, domain allowlists, download restrictions, and sensitive-action logs.
• Let mobile clients start work, inspect status, approve actions, and recover offline input.
• Provide fixed-IP egress checks, allowlist management, certificate rotation, and API receipts.
• Produce intermediate artifacts for long jobs instead of hiding failure until the end.
• Detect capability changes: an uninstalled browser, changed IP, or low disk should mark the device unavailable.

At this point, device management becomes productivity infrastructure rather than a status list. Adding a device adds capabilities, risk, and operational responsibility.

Phase 4: cost, policy, and governance

When a person owns a dozen devices or more, they need to answer “what did this automation cost?”

• Track cloud cost by runtime, instance size, and storage.
• Estimate local-device cost by online window, resource use, and power profile.
• Report task volume, failure rate, and device cost by project and agent.
• Support maintenance windows, budgets, and automatic shutdown rules.
• Scope credentials by project and action; never store them in project documents or issue text.
• Require human confirmation by default for external sends, deletion, payment, production configuration, and other high-risk actions.

Governance does not exist to stop automation. It gives users confidence to run more work. Without cost visibility, they will not keep a device online 24/7; without permission boundaries, they will not connect real accounts; without audit records, they will not let an agent touch external systems.

A deployment forecast: separate control, execution, and data planes

Deploying a multi-device system requires more than checking whether a service starts. The network, version, and failure boundaries between control and execution need to be explicit.

Control plane: workspace, tasks, and policies

The cloud control plane stores workspaces, projects, issues, agents, device records, task state, permissions, audit records, and result indexes. It is the shared source of project facts for web, desktop, mobile, and API clients.

Execution plane: local and cloud runtimes

The execution plane consists of the daemon, agent CLI, local tools, and working directory on each device. It establishes a secure connection, receives authorized work, and sends heartbeats, logs, artifacts, and status back. Personal PCs, Mac minis, cloud workstations, and fixed-IP servers all belong here, but each has a different capability and policy profile.

Data plane: documents, attachments, media, and results

Project documents, video assets, exports, and execution reports need their own storage and access rules. Large files should not be repeatedly placed into task messages, and sensitive credentials should not follow ordinary project-document sync. The workspace stores traceable project content; devices keep temporary execution caches that can be cleaned by policy.

The deployment should reserve boundaries for at least these cases:

Observability should also go beyond “the endpoint returned 200”: device availability, queue time, first-claim latency, success rate, retries, device switches, external API receipts, cloud cost, and time waiting for human approval. Only with these measures can a team tell whether multi-device management creates output or merely creates more invisible background activity.

A launch forecast: validate three roles before expanding the fleet

The first release does not need to support every kind of hardware. The most useful starting point is three complementary roles:

1. One personal PC: validate communication, human confirmation, and local-file input.
2. One always-on Mac mini or cloud workstation: validate long jobs, offline devices, and recovery.
3. One fixed-IP server: validate restricted APIs, webhooks, receipts, and approved public distribution.

The phone can join the first preview as the control entry point, but its main role is notification and approval, not complex execution.

A sensible rollout looks like this:

Internal validation: make sure tasks are not lost

Choose a low-risk, repeatable flow such as overnight data cleanup or video transcoding. Observe whether:

• a reboot, disconnect, or sleep returns the task to the right state;
• the same task can execute twice;
• the result, logs, and input map back to the issue; and
• users understand why the system chose a device.

Private preview: validate capability routing

Add browser work, cloud jobs, and phone approval, while keeping send, delete, and publish actions behind confirmation. Invite a small set of real workflows and look for misrouting, devices that appear online but cannot execute, and results that fail to return.

Public launch: validate operations and cost

Before general availability, users should be able to complete the full lifecycle: register a device, inspect capabilities, bind an agent, create, pause, or cancel a task, upgrade a runtime, rotate credentials, inspect cost, move work to another device, and delete device data.

The launch gate can be stated as a checklist:

• Device identity, capabilities, and permissions are understandable.
• Tasks have clear inputs, outputs, timeouts, and approval rules.
• An offline device cannot silently lose or duplicate a task.
• Browser sessions, API keys, and local credentials never enter project documents.
• Public actions from a fixed-IP server have receipts and audit records.
• Cloud workstation cost, idle behavior, and cleanup are explicit.
• Runtime upgrades, rollback, and protocol compatibility have an operational plan.
• The same task context can be continued from a phone, personal PC, and web client.

The real goal is to manage attention

More devices should not force people to learn more consoles. Good multi-device management hides the differences inside scheduling and policy. A person states the goal, chooses the risk boundary, and reviews important results; the system sends work to a suitable device, waits for it to return online, records evidence, and offers a next step when it fails.

The personal PC remains useful for communication and creation. The Mac mini provides always-on browser and local tools. The cloud workstation handles long computation. The fixed-IP server protects the network identity of external APIs. The phone brings initiation and approval everywhere. They do not replace one another; they form one person’s productivity network.

AuraBaba should not become another list of remote computers. It should make these devices understandable, schedulable, recoverable, and auditable digital teammates. When everyone has a device fleet, productivity is no longer about which computer you own. It is about whether the right device can safely complete the right work at the right time.