One Zinley Across Your Devices
A cross-device architecture for keeping one conversation and one Zinley across the computers and devices you connect.
The laptop, phone, and cloud computer are not separate assistants. They are approved devices and channels for the same Zinley, with one identity, one private context, and one set of rules.
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.
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.
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.
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.
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.
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.
@mac send the latest deck to DanaThe owner names an approved device when location matters.
Send Dana the latest deckZinley selects an available approved runtime that can access the file and email tool.
The execution device may change. Zinley's inbox, shareable contact card, optional phone line, relationship history, owner rules, and open commitment do not.
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.
Examples
The following flows illustrate the proposed model. They are not benchmark results or guarantees of unattended completion.
Send Dana the deck from my Mac before the meeting.Finish the approved report and ask me before sending it.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.