Research

One Zinley Across Your Devices

A cross-device architecture for keeping one conversation and one Zinley across the computers and devices you connect.

Zinley Research·March 2026

Abstract

Owners often move between a browser, a desktop app, and a phone while the work itself spans files, tools, and networks. When Zinley Computer is enabled, it can continue approved work while personal devices sleep. This paper describes a coordination model in which one Zinley routes work to an approved device runtime without creating another public agent identity. Each runtime advertises only the capabilities and permissions available on that device. A shared control layer selects a valid target, records the handoff, and returns the result to the same conversation, relationship record, open work record, and owner Brief. The model is designed to preserve continuity while keeping device access explicit and revocable.

01

The Continuity Problem

A task may begin in a message, require a file on the owner's Mac, continue in a browser, and finish on Zinley Computer when enabled. Without a shared control layer, the owner becomes the router. They copy context, choose the machine, reopen the task, and reconcile the result.

The product invariant is simple: changing devices must not create a new Zinley. The owner and the people around them should keep working with the same assistant and the same relationship history.

One Zinley connected to approved device runtimesZinleyone identityOwner's Macapproved runtimeZinley Computeralways-on runtimePhone channeldelegate and reviewone memory · one authority policy · one result history

Figure 1. The devices and channels differ, but the assistant does not. Device runtimes receive scoped work from one Zinley and write results back to one continuous record.

02

Architecture

The coordination layer separates identity from execution. The inbox, shareable contact card, optional phone line, relationship history, open commitments, and owner rules remain tied to one Zinley. Device runtimes expose only the tools and data the owner has permitted on that device.

LayerResponsibility
Zinley identityKeeps one inbox, shareable contact card, optional phone line, private context, and owner policy across channels and devices.
Approved runtime registryRecords which owner devices are trusted, online, and permitted to perform each capability.
Dispatch and receiptRoutes a bounded task, records delivery, and returns the outcome to the originating thread.
Authority checkBlocks actions outside the owner's permissions, limits, or approval rules.
A task routed through identity, authority, and device capability checksTaskone conversationZinley control layeridentity + memoryowner rulescapability matchreceipt ledgerMac runtimefiles + appsCloud runtimealways onOther runtimeonly if approvedresult returns to the same Zinley

Figure 2. A runtime is selected only after identity, authority, availability, and capability checks. It executes a scoped task, not a second relationship with the owner or recipient.

03

Dispatch Without Losing the Thread

A dispatch contains a task, a target capability, the minimum required context, and an authority envelope. Delivery can be asynchronous, so the original app or device does not need to stay open. Completion writes a receipt and result back to the same open work record and owner Brief.

Owner-selected device
@mac send the latest deck to Dana

The owner names an approved device when location matters.

Capability-selected device
Send Dana the latest deck

Zinley selects an available approved runtime that can access the file and email tool.

Continuity invariant

The execution device may change. Zinley's inbox, shareable contact card, optional phone line, relationship history, owner rules, and open commitment do not.

04

Security and Authority Boundaries

Cross-device execution expands the attack surface. The design therefore treats every runtime as a revocable execution endpoint, not as a trusted copy of the owner or a new Zinley identity.

ControlPurpose
Explicit approvalOnly owner-approved devices may register a runtime.
Least accessEach runtime exposes only the tools, folders, and actions allowed on that device.
RevocationRemoving a device or permission stops future dispatches to that device.
ReceiptsThe system records the target, authority used, action taken, and result returned.
EscalationA task returns to the owner when no approved runtime or rule permits the next action.
05

Examples

The following flows illustrate the proposed model. They are not benchmark results or guarantees of unattended completion.

Scenario A · File handoff while traveling
Send Dana the deck from my Mac before the meeting.
1 · Zinley checks authority
The recipient, file scope, and outbound email rule are verified.
↓
2 · Mac runtime retrieves the file
Only the approved folder and required file are accessed.
↓
3 · The same Zinley sends and records it
The email comes from Zinley's disclosed AI identity. The delivery receipt returns to the open work record and owner Brief.
Scenario B · Long-running work continues overnight
Finish the approved report and ask me before sending it.
1 · Desktop context is handed off
The task state and permitted source material move to Zinley Computer when enabled.
↓
2 · Work continues asynchronously
The owner's laptop can disconnect while the approved task continues.
↓
3 · Sending waits for owner approval
The completed draft appears in the owner's Brief with the next decision, rather than being sent automatically.

Conclusion

Cross-device continuity should expand where one Zinley can work without multiplying identities. The owner keeps one assistant. Approved runtimes provide different capabilities behind it.

The architectural requirement is therefore not agent-to-agent social coordination. It is identity-preserving dispatch with explicit authority, minimum context, revocable access, and durable receipts.