OpenClaw Isn't Dead: It Lives in Big Tech's Answers for Agents

OpenClaw’s agent architecture remains relevant as personal-agent products converge on persistent workspaces, browser access, reusable skills, and long-running tasks. My argument is about that shared design pattern; it does not establish that another company copied OpenClaw.

Google has Gemini Spark. OpenAI has ChatGPT Work. Anthropic has Claude Cowork. Meta is pushing Muse, while xAI has built Grok Bot around a persistent cloud computer.

All five products are trying to move AI beyond the chat box, but they did not start from the same place.

Google, OpenAI, and Anthropic began with assistants that already had large user bases and then added more access: files, SaaS apps, browsers, scheduled tasks, event triggers, and computer use. Muse and Grok Bot started from a different assumption. Instead of gradually extending a chatbot, they put the agent inside a working computer environment from the outset. I examined that bet in detail in Meta Muse and Grok Bot: are cloud-hosted agents the next form?.

That distinction still matters, but less than it did a few months ago. ChatGPT Work now has a cloud browser. Claude Cowork already relies on virtual-machine isolation. Spark is becoming more event-driven. At the same time, Muse and Grok Bot still benefit from APIs, connectors, and skills whenever those are faster and more reliable than clicking through a website.

The products are beginning to meet in the middle.

And that middle looks surprisingly familiar.

Long before “personal agent” became the phrase every major AI company wanted to own, OpenClaw had already bundled many of the same building blocks into one system: a persistent workspace, reusable skills, browser access, computer use, memory, automation, triggers, and long-running sessions.

The interesting question is not whether OpenClaw will beat these companies as a consumer product. It is whether it identified the right shape of an agent earlier than most of the industry.

The big three started with the assistant

Google has the clearest reason to begin from context rather than from a computer.

A large part of a user’s digital life may already sit inside Gmail, Calendar, Drive, Docs, Sheets, Search, Maps, YouTube, and other Google services. Spark does not need to recreate the act of opening those applications one by one if Gemini can already work across them at the account level.

That is why Task, Schedule, and Skill matter more than they may appear to at first glance. The change is not simply that Gemini can do more. It can also begin work in different ways.

A traditional assistant waits for a prompt. Spark can react to time, conditions, or events. A morning routine can look at email and calendar entries without waiting for the user to start a conversation. A particular kind of incoming message can kick off a workflow that already knows how it is supposed to be handled.

That moves the product away from pure request-and-response interaction.

OpenAI arrived at the same problem from a less convenient position. It does not own Gmail, Drive, Slack, GitHub, or most of the other services people use at work, so ChatGPT Work has had to pull those services inward through connected apps.

The result is less vertically integrated than Google’s approach, but potentially broader. ChatGPT can move across files and external applications, gather information, and produce a document, spreadsheet, presentation, or other finished output.

Event triggers push it further in the same direction. A new email, Slack message, or GitHub pull request can start a task without the user manually opening ChatGPT first.

Then OpenAI added Cloud Browser.

That addition matters because connectors have a ceiling. No company can realistically build and maintain a perfect structured integration for every website or internal tool a user may need. A browser is slower and less elegant than a well-designed API, but it gives the agent a fallback when no formal integration exists.

Anthropic’s path is harder to place in a neat category.

Cowork grew out of Claude Code, not out of a conventional office assistant. Developers were already giving Claude Code access to real project directories and letting it read files, modify code, invoke tools, and keep working through multi-step tasks. Cowork extends that pattern into more general knowledge work.

Anthropic has also described an early Cowork architecture in which the agent ran inside a full virtual machine with its own Linux kernel, filesystem, and process table. The user’s authorized workspace was mounted into that environment while the rest of the host stayed outside it.

That makes Cowork an important counterexample to any simple “three incumbents versus two computer-native challengers” story. Anthropic is already using a model in which the agent gets a real working environment and the security system constrains the environment around it.

The same is increasingly true of OpenAI.

So the difference between the two camps is better understood as a difference in starting point, not destination.

Muse and Grok Bot started with the computer

Meta describes Muse as “a secure computer with its own browser.”

That sentence captures the product more accurately than a long feature list would.

Muse runs inside a persistent Secure VM. The agent can use a browser, visit websites, fill in forms, and continue working in the background. Instead of asking whether every service has a dedicated AI integration, Meta gives the agent a general-purpose environment that can fall back to the web when necessary.

The appeal is obvious. Humans do not stop working because a supplier portal has no API. They open the website and use it.

Computer use gives an agent the same escape hatch.

xAI takes the idea even further with Grok Bot, which it describes as “an agent with a computer.” Its cloud environment includes a desktop, filesystem, terminal, browser, and apps, and it persists between tasks.

That changes the product in a way that is easy to miss if you focus only on features.

A normal chat assistant temporarily receives tools. Grok Bot is designed as if the tools and environment are already there, and the main question becomes how much of that environment the agent is allowed to use.

That is a different default.

It also helps explain why these products can feel more autonomous even when the underlying models are not necessarily more capable than the best models from Google, OpenAI, or Anthropic. Much of the difference comes from what the product lets the model touch.

Meta and xAI are not ignoring safety. Muse uses a secure environment, and Grok Bot has its own approval and policy layers. The difference is that the computer exists first. The restrictions are applied around it.

For products that evolved from chat assistants, the sequence was usually reversed: start with very little access, then add permissions one capability at a time.

The two approaches are already merging

The clean version of this story says that Spark, Work, and Cowork are workflow-centric while Muse and Grok Bot are computer-centric.

The products themselves are already making that description obsolete.

ChatGPT Work has a cloud browser and persistent execution. Cowork has always had a strong workspace and VM model. Spark increasingly depends on triggers and actions that move beyond conversation.

In the other direction, Muse and Grok Bot have every reason to use structured tools when they are available. A stable API is usually faster, cheaper, and easier to audit than having a model repeatedly interpret a page and click through it.

A capable personal agent will probably use both.

It will call structured interfaces for predictable work and fall back to a browser or computer for the messy remainder.

Once viewed that way, the industry’s direction becomes easier to see. A personal agent needs somewhere to keep state, a way to reuse procedures, tools for interacting with software, and some mechanism for continuing work without waiting for another prompt.

OpenClaw put those pieces together early.

That does not mean the major labs copied it. Similar designs can emerge simply because the engineering problem keeps producing the same requirements.

If an agent is expected to remember what it was doing yesterday, it needs persistent state. If it is expected to repeat a workflow reliably, it needs reusable instructions or skills. If it has to use software that lacks an API, it needs browser or computer access. If it is expected to act while the user is away, it needs scheduling and event triggers.

The convergence is more interesting than any claim of influence.

Permissions are becoming the real product problem

Once agents can actually do things, safety stops being an abstract model-policy discussion.

A chatbot can produce a bad answer. An agent with access to email, code, CRM systems, shopping sites, cloud infrastructure, or company files can perform a bad action.

That changes the stakes.

Google has years of user data sitting inside Gmail, Drive, and Calendar. OpenAI is connecting Work to enterprise systems. Cowork is designed to operate on real workspaces and internal material. Every increase in autonomy therefore creates a second layer of product work around authorization, logging, revocation, administrator controls, and liability.

Those controls are necessary, especially in large organizations. They can also make an agent frustrating to use.

Anthropic has published one of the clearest examples.

In an earlier permission model for Claude Code, users were repeatedly asked to approve file edits and terminal commands. Anthropic found that roughly 93% of those requests were approved.

That is not strong evidence that every requested action was safe. It may instead show that people stop paying attention when they are asked the same question too often.

The company later moved more activity inside clearly defined sandbox and workspace boundaries. According to Anthropic, the change reduced permission prompts by about 84%.

That result points to a more practical approach to agent safety.

Instead of asking a human to evaluate every low-level action, the system can define what the agent is allowed to reach in the first place. Inside that boundary, the agent gets room to work. Crossing the boundary triggers a stronger control.

Anthropic often frames this in terms of blast radius, which is a useful way to think about the problem.

The goal is not to assume the agent will never make a mistake. The system needs to limit how much damage a mistake can cause.

That is a different philosophy from stacking confirmation dialogs on top of every tool call.

The disagreement is really about who controls the boundary

This is where Muse, Grok Bot, and OpenClaw become more interesting.

Their advantage is not that they have somehow solved agent safety. They have not.

What they do differently is expose more of the control surface to the user.

With a computer-native agent, the platform can provide isolation, credential handling, logging, and review mechanisms while still allowing the user to decide how much of the environment should be available.

OpenClaw takes that idea furthest. The user can choose where the agent runs, which model it uses, which skills are installed, what files it can access, and what kind of automation it is allowed to perform.

That is powerful, but it also shifts responsibility outward. A power user may welcome that tradeoff. A mainstream consumer may not want to think about it at all.

The larger AI companies face the opposite problem.

The more enterprise customers, regulated workloads, and long-lived user data they handle, the harder it is to make broad autonomy the default. A product team may know that fewer interruptions would make the agent much better to use, while the legal, security, and enterprise requirements push toward tighter controls.

Neither side has solved the tradeoff.

But the tension is becoming visible in the products.

There is another constraint: running agents is expensive

Permissions are only half of the problem.

Muse also exposes the infrastructure cost of this product category.

Meta launched Muse first in the United States and Canada. Apptopia estimated around 2.8 million downloads in its first 12 days, including roughly 1.8 million iOS installs across the two markets.

That is rapid adoption for a product that was still geographically limited.

At the same time, some users have reported that Muse feels less available or slower during periods of heavy demand. Meta has not publicly confirmed that user growth is the cause, so it would be premature to treat the two as directly linked. But the architecture makes capacity an obvious concern.

Muse is not just serving isolated text requests. Meta describes its Secure VM as a persistent, dedicated environment with its own browser. A long task may keep state, run a browser session, call models repeatedly, invoke tools, and stay alive for far longer than a normal chatbot turn.

“Dedicated VM” does not mean every user permanently occupies an entire physical server. Meta can suspend environments, share accelerators, and schedule workloads aggressively. Even so, the operating model is heavier than a short-lived inference request.

Meta’s own product limits reflect that reality. The free tier has usage caps, after which users have to wait for the quota to refresh or move to a paid plan.

The scale of Meta’s infrastructure spending makes the constraint even more striking.

The company reported 2025 capital expenditures, including principal payments on finance leases, of $72.22 billion. It later raised 2026 full-year CapEx guidance to $130 billion to $145 billion.

Those numbers are not a Muse budget. They include Meta’s broader data-center buildout, training infrastructure, and core services.

But they are a useful reminder of the scale of the problem. Even a company spending well over $100 billion a year on infrastructure still has to think carefully about quotas, rollout regions, and paid usage when the product involves persistent agent environments.

A chatbot and a personal agent impose different kinds of load.

The first mainly needs to answer requests. The second may need to remain available, keep state, operate a browser, execute tools, and continue work while the user is gone.

If personal agents eventually reach billions of users, infrastructure may become as important a product constraint as model quality.

OpenClaw has a different cost model

This is where OpenClaw’s local-first design becomes relevant again.

Running an agent on a user’s Mac, PC, home server, or VPS does more than give the user more control over permissions and data. It also moves some of the operating cost away from the platform.

The user has already paid for the hardware. The user also pays for the electricity, storage, memory, and network connection required to keep the agent running.

That does not automatically make self-hosting cheaper. Large cloud providers operate hardware far more efficiently than individual users can, and local machines introduce their own maintenance burden.

The economic structure is simply different.

For a cloud agent, growth means the provider must absorb more concurrency, more persistent environments, and more background execution. For a local or self-hosted agent, part of that load is distributed across hardware the users already own.

That distinction may matter much more if personal agents become something people leave running all day rather than tools they invoke occasionally.

OpenClaw’s real contribution may be the question it asked

OpenClaw may never become the dominant consumer product in this category.

That is not what makes it interesting.

Spark is extending the Google account into an agent environment. ChatGPT Work is combining connected apps with browser-based execution and triggers. Cowork is carrying Claude Code’s workspace model into general knowledge work. Muse and Grok Bot started with persistent computers.

They are all confronting variations of the same questions.

Where does the agent keep state? How does it learn a repeatable workflow? What happens when there is no API? How does it continue working when the user is not present? How much authority should it have? And who pays for an environment that may need to stay alive for hours?

OpenClaw surfaced many of those questions early because it never treated the agent as just a model behind a chat interface.

It treated the agent as something that needed a place to live and work.

That idea now looks much less fringe than it did before.

The major AI companies are arriving there by different routes, with different business models and very different tolerance for risk. They may end up building products that look nothing like OpenClaw on the surface.

But the underlying shape is becoming easier to recognize.

The next stage of AI competition will not be decided by model intelligence alone. It will also depend on who can give an agent enough access to be useful, enough isolation to be trusted, and enough infrastructure to keep it running—a tension now boiling over into the economics of persistent agents like OpenAI Dots.

That is the part of the OpenClaw idea that is still very much alive.