Rabbit announced the general release of OS3 on September 22, describing an outcome-based assistant that can work through a web portal, messages and connected devices. It says a local agent can operate desktop software and files while connected model providers process relevant task context under their own terms. Those are product claims from the company’s announcement, not an independent privacy audit. The design question is concrete: when a single assistant can cross devices and act on a person’s behalf, where does the user see what it can access, what it has done and how to stop it?
One entry point hides many powers
A single conversational entry point can reduce tool selection. A user says what they want instead of choosing between browser automation, code execution and a document workflow. But those capabilities have different risks and levels of reversibility. A search query is not the same as editing a local file, sending a message or purchasing an item. An outcome-first interface needs a way to reveal the action plan without requiring a person to learn every technical primitive.
The key moment is before an agent crosses an authority boundary. State which device and account it will use, what data it needs, what change it proposes and whether the action can be reversed. A persistent task view should remain available after the conversation scrolls away. The chat can be the entry point; the audit trail and controls must live somewhere stable.
Context portability is not data invisibility
OS3’s announcement describes model flexibility and the ability to change models without losing context, memory or skills. That is appealing because users do not want to rebuild a working setup after switching providers. But portability creates questions: which data remains with the OS3 service, which information travels to the model provider, and what should be removed when a connection ends? The company describes some of these flows, including handling through its own servers before model handoff. Readers should inspect the current product terms for their chosen provider.
A useful interface should distinguish local file presence, extracted context, stored conversation and remembered preferences. ‘Your files stay local’ does not answer every question about snippets sent for inference. A user may accept a specific transfer for a task while rejecting persistent memory. Those decisions should be separate controls with concrete previews, not one broad trust toggle.
The interruption test
An agentic OS earns trust when the user can pause, inspect and recover. Imagine a task that edits three files, waits for a web response and then prepares a message. Can the user stop after the second edit and see the exact state? Can the system resume without repeating an external action? Does it ask again when the destination or cost changes? Those details decide whether an agent feels helpful or unpredictable.
Design task states around real consequences: planned, awaiting approval, running, blocked, partially complete, completed and reverted where possible. Each state should have a next action in plain language. A decorative progress bar is less useful than a list of actual changes and pending permissions. Multi-device products especially need a single source of task truth when the user moves from phone to desktop.
How to evaluate the promise
Run a bounded task with connected apps that contain only low-risk test data. Record every request for permission, what was sent to the provider, what the agent changed and what a human had to correct. Disconnect midway and reconnect on another device. Check whether the task history is coherent and whether any work happens twice. These observations are more informative than a polished launch demonstration.
Also test a refusal. A person should be able to say ‘do not touch this folder’ or ‘draft but never send’ and have that preference honored visibly. If the system cannot explain the boundary it is respecting, the user has to trust an invisible promise. This is not a claim that OS3 fails those tests; it is a product checklist prompted by the breadth of the announcement.
The category that emerges
Rabbit’s release suggests an operating layer that connects intent with many device-level capabilities. The strategic advantage may be less about the model and more about continuity: a remembered task, clear authorization and reliable execution across surfaces. The corresponding liability is also continuity: a mistaken instruction or excessive permission can follow the user everywhere.
The product teams watching this category should study recovery as carefully as creation. More autonomy makes transparent limits more valuable. The best interface will make a powerful agent feel interruptible, inspectable and accountable, even when the execution crosses applications the user never opened directly.
Questions to take into your next review
- Can a user see every device and account a task will touch?
- What task state survives a model or device switch?
- Can a partially completed action be stopped and reviewed safely?