On September 8, 2026, Meta announced its personal agent, Muse. The key distinction between this service and typical chatbots was tucked away in an easily overlooked detail of the announcement: Meta assigns each user a dedicated cloud computer, and the agent lives inside it. When users close their laptops or turn off their phones, the remote system keeps running—with their files, browsers, and login sessions remaining intact on that machine.
On the surface, this marks Meta’s formal entry into the personal agent space. But when you piece together the recent moves of several companies, it becomes clear that Muse is just the latest milestone in a much longer timeline.
A month earlier, xAI’s launch of Grok Bot was built around the exact same premise: every user gets a persistent cloud computer, and all bots under their account share its filesystem and login sessions.
Go back another three months, and Manus had already launched Cloud Computer on April 30, offering an always-on Ubuntu cloud machine capable of running persistent bots, scheduled cron jobs, and self-hosted services. A month and a half before that, on March 16, Manus had also introduced My Computer, allowing agents to directly operate the user’s local machine.
Arranging these milestones chronologically makes the trajectory obvious: March 16, 2026 for Manus My Computer, April 30 for Manus Cloud Computer, August 11 for Grok Bot, and September 8 for Meta Muse. Within a span of months, three independent companies converged on the identical architecture: granting agents a dedicated machine that never shuts down. Despite vastly different backgrounds, these companies arrived at the exact same engineering consensus in a matter of months, pointing to a distinct underlying technological driver.
When one company does it, it’s a product choice; when three companies roll out the exact same form factor in rapid succession over just a few months, it means they have all hit the exact same constraint. While Meta and xAI are the latest tech giants to enter the fray, Manus was the first to act. In 2025, when the industry was still debating whether agents could do real work, critics and observers repeatedly used Manus as the test case; a year later, as the debate shifted to where agents should live, Manus once again delivered the first answer.
We have been tracking this technical trajectory over the past several months. In August, we wrote that the interfaces of coding agents are converging, and that the real divergence lies beneath the surface in the execution layer—specifically, whose machine actually runs the task. In June, we also noted that agents are moving from chat windows into background daemons. Manus leaned toward on-demand conversational sessions that stayed idle until summoned, whereas Google’s Spark functioned as a background daemon, monitoring changes autonomously once configured with rules. Looking back, those two articles documented the opening chapters of this evolution curve.
Not only is the form factor converging, but the target domain of these machines has shifted as well. Agents with dedicated workstations originally targeted software developers, accumulating state in the form of code. Today, the very same architecture is pointed directly at users’ inboxes, calendars, and smart home devices—swapping out the code repository for daily life as the fundamental unit of state. This transition mirrors the move from Claude Code to Claude Cowork: while the core mechanics of the tool remain similar, the audience has shifted from those who write code to those living their everyday lives.
At first, an agent was nothing more than a text box inside a chat window. The user asked a question, the model replied, and once the session ended, state reset to zero. It had no memory, could not invoke external tools, and its capabilities were strictly confined to the dialogue box.
Later, developer tooling began giving models hands and feet. Cursor’s Agent mode, Claude Code, Codex, and Devin enabled agents to read and write files, execute terminal commands, run tests, interpret errors, and attempt fixes. Interaction remained wrapped in a conversational interface, but dialogue evolved into iterative execution loops. Coding agents were the first to secure a foothold: a dedicated workbench equipped with a filesystem, a shell, and a toolchain. Yet this workbench remained entirely tethered to the code repository; step outside that project directory, and the agent had nowhere to go. If you asked it to read incoming emails, process expense receipts in the downloads folder, or look up travel itineraries, the traditional coding workbench lacked the necessary context.
Providers subsequently moved these execution environments to the cloud, triggering runs based on schedules or events. Cursor launched Background Agent in May 2025 (later renamed Cloud Agent) and upgraded it to a full virtual machine in February 2026. Claude Code debuted its web version in October 2025, running tasks in the cloud. Codex launched in May 2025 natively in the cloud, spinning up an isolated sandbox for each task. This stage solved the problem of agents operating autonomously away from the user’s foreground terminal, but the machines were ephemeral: spun up per task and destroyed upon completion, leaving behind no login sessions, files, or persistent memory.
For software development, ephemeral environments are virtually ideal. The state of software engineering lives in git, where code, branches, and commit histories can be fully synchronized. A virtual machine is merely a temporary hot desk: it pulls code, runs tests, and pushes changes back to the remote repository. Once the branch is pushed to the code hosting platform at the end of a task, the machine has fulfilled its purpose; tearing it down incurs zero loss of assets. The lifecycle of software engineering is structured around commits, making it inherently suited to sandboxed computing that spins up and tears down on demand.
Personal life has no external repository akin to git. You cannot
git clone a digital life. It is composed of messy runtime
state: web login credentials, browser profiles, download folders,
inboxes, local utilities, and learned memories of personal habits. This
state has no universal export format; it is embedded directly within the
operating system environment. Personal tasks often span days or even
weeks. If login authorizations or working documents vanish halfway
through, the entire automated workflow collapses. The moment the
computing environment resets, the operational state required to keep
things running disappears with it.
To handle personal affairs, an agent no longer needs an ephemeral hot desk that is dismantled after each use; it needs an always-on, dedicated machine—a permanent home base. The isolated environments in Manus Cloud Computer, Grok Bot, and Muse are simply different interior designs of this same home. What this machine truly anchors is the agent’s operational state: which services are logged into, what files are stored, which preferences are remembered, and what scheduled cron jobs are running.
A personal agent that genuinely gets things done on your behalf must be embedded and continuously present. It must be woven into the user’s accounts, files, and daily routines, all while advancing tasks autonomously when unattended. These dual requirements demand that it reside in a fixed place. The entity that actually settles down is the operational state, not the model itself. Since the state of daily life cannot be exported, whoever maintains custody over it effectively owns the asset. The convergence of all three vendors on the same architecture stems from this fundamental reality: operational state must find a physical space to call home.
Housing operational state requires a machine that never powers down, but that requirement does not inherently bind you to a vendor’s cloud. Persistence and managed hosting are, in reality, two entirely independent dimensions.
Viewed in isolation, persistence can be achieved just as well with an always-on local computer. Keeping a machine awake at home running an open-source harness keeps login sessions local, the browser local, and all files and scheduled tasks local. At the foundational capability level, there is no functional chasm between a local machine and a cloud virtual machine. When it comes to network environments, a residential IP is far less prone to bot-detection blocks when browsing everyday websites, and keeping authorization credentials on your own hardware offers far tighter control. In this context, the cloud provides a delivery mechanism, not an exclusive technical capability.
Arranging the major approaches by machine location and maintenance responsibility lays bare the engineering trade-offs. Each path draws its own boundary between user control and barrier to entry.
| Approach | Machine Location | Maintained By | Session State Location | Runs After Local Shutdown? |
|---|---|---|---|---|
| Cursor Cloud Agent | Cloud (one per task) | Vendor | Ephemeral | Yes |
| Always-on Local Codex | Your home | Yourself | Local | Yes |
| Cowork | Cloud planning, local rendering | Vendor + You | Imported locally | No, desktop must stay online |
| Grok Bot / Muse | Cloud (dedicated, persistent) | Vendor | Vendor cloud | Yes |
| OpenClaw / Hermes | Your home | Yourself | Local | Yes |
The true dividing line lies beyond the final column: who holds custody of the operational state. The self-hosted path leaves control in the user’s hands, but at the cost of turning the user into a full-time system administrator. You have to purchase hardware, perform system maintenance, apply patches, manage power and network stability, handle disaster recovery, and forgo seamless multi-device access across account ecosystems. An occasional home power outage, network hiccup, dynamic router port change, or forced system restart will grind local services to a halt. The vast majority of people have zero interest in maintaining a private server long-term, which naturally pushes the market toward managed hosting.
In exchange for handing over custody, users receive a clear set of concrete benefits: freedom from routine hardware and OS maintenance; turnkey connectors maintained by the vendor (Muse comes pre-configured with email, calendar, payments, and smart home integrations); platform-exclusive capabilities (such as Stripe Link generating single-use virtual card numbers tied to specific merchants, amounts, and expiration windows, with each transaction requiring user approval); and multi-device access that follows your account wherever you log in. Taken together, the core product users are buying is the outsourcing of custody. The pricing benchmark of these products is not determined by how smart the underlying model is; it is anchored to the combined cost of hiring someone, building and maintaining your own machine, or absorbing operational errors.
Talking simply about “moving to the cloud” obscures the real variable at play. The cloud is merely a delivery mechanism; the decisive shift has always been the outsourcing of custody. The primary product vendors are selling you is taking over management of this operational state.
Vendors are eager to take on custody because the economic ledger is crystal clear: controlling the execution environment yields vital behavioral data and locks in the long-term customer relationship.
When tasks run on a vendor’s cloud machine, their engineering team gets full visibility into how agents use tools in real-world scenarios, where they get stuck, and what users approve or reject. These first-hand behavioral traces are indispensable for refining models. If the agent runs inside a user’s home, those interaction nuances remain strictly local, leaving the vendor with visibility into nothing more than isolated API calls. By holding the execution environment, vendors secure both a proprietary data flywheel and deep user lock-in. Files, login sessions, persistent memories, and scheduled cron jobs all reside on that machine; over time, preferences and custom rules compound. Switching to a competitor requires rebuilding the entire environment from scratch—exporting chat transcripts is practically useless. The convenience the user gains and the moat the vendor builds originate from the exact same asset.
This architectural shift is reshaping commercial pricing models. Chatbots bill per query, where users pay strictly for what they consume; persistent machines, by contrast, allocate dedicated compute resources per user that incur costs around the clock, regardless of whether the user is actively issuing commands. Continuously reserved memory, disk storage, and idle background processes represent fixed daily operational expenses for vendors. Consequently, free tiers must enforce strict rate limits, while premium tiers transition to fixed monthly subscriptions. According to media reports, Muse’s paid tiers are priced at $20 and $100 per month. Data flywheels, ecosystem lock-in, and recurring subscriptions are in total commercial alignment.
Different user segments perceive this calculus quite differently. Technical developers who possess the capability to self-host tend to favor tools like OpenClaw or Hermes, keeping credentials locked in their own hardware. Time-constrained professionals care far more about efficiency than managing servers; needing turnkey connectors and mobile support, managed commercial hosting offers immediate productivity gains. For everyday consumers without technical backgrounds, managed solutions are virtually the only practical path forward.
In real-world workflows, always-on machines can genuinely power through complex, long-running processes. Following the Grok Bot launch, one user had a bot interface with roughly forty Vietnamese fabric suppliers, negotiating quotes one by one across email and supplier websites before finally selecting one to complete sample procurement. That kind of task would normally require a human spending days toggling back and forth between inboxes and browser tabs. Delegating it to a background machine to execute autonomously was only viable because that machine stayed perpetually online while preserving every authenticated session.
When evaluating marketing claims around dedicated cloud computers, I find it most useful to assess them against four core questions: Is the environment always-on, persistent, and capable of retaining authenticated sessions? Who is responsible for routine machine maintenance? On whose servers do credentials and data reside? How much configuration must be rebuilt from scratch if you switch providers? Laying out these questions makes it easy to see whether a service is genuinely taking operational chores off your plate, or simply relocating that exact same operational state to someone else’s infrastructure.
That intelligent assistants need a home is now an industry consensus. Whose turf that home sits on—and who holds custody over the operational state inside it—is the real battleground ahead.