Agents don't need a better sandbox. They need a computer of their own.

A lot of companies are now building "compute" for agents. Some ship isolation sandboxes. Some ship light VMs. Some put a full digital worker in front of end users. Cloudflare has started saying an agent needs a computer, not a container. The direction is right. Agents are no longer just Q&A in a chat box. They write code, call tools, edit files, talk to external systems, and sometimes run for a long time.

But I think one assumption is being waved through: a better box for the agent is the same thing as a compute environment.

Our judgment points the other way. What agents really need is not a faster sandbox, and not a more complete Linux VM. They need a computer redesigned for agents: one that can last, hold identity and state, constrain authority, make action history checkable, and leave with you when you change operators.

The market is building boxes

Agent compute has moved fast over the past year. Isolation sandboxes run untrusted code in light VMs. Another class of products made pause/resume and snapshot forking ordinary. Others treat light VMs as long-lived workers. Perplexity Computer speaks directly to end users as a general-purpose digital worker.

A sharper recent signal is Cloudflare. Their early preview of @cloudflare/computer almost uses the same sentence we care about: an agent needs a computer, not a container. The design is clear. Route work between isolates and full Linux containers, keep a shared durable filesystem across backends, and gate, audit, and observe file and shell operations. That is more realistic than giving every agent a permanent container, and it shows a major platform admitting that a container alone is not enough.

Each of these products solves a real problem: isolation, boot time, pause, concurrency, browser or terminal access, and now "when is light execution enough, and when do you need full Linux." For short code runs, evals, previews, and one-shot research jobs, a sandbox is still the right tool. You do not need to reinvent the computer for a throwaway Python snippet.

The problem sits in the top-level object.

For most products, that object is still a sandbox, machine, session, container, workspace, or task. You create an instance, inject credentials, run, then destroy or pause. Root identity comes from a platform account. Keys and audit logs mostly live in the platform backend. State can be snapshotted, and a shared filesystem can be strong, but both are usually still objects under a cloud account, not a whole machine you can carry away with continuous identity after you change operators.

Cloudflare renaming the frame from container to computer is real progress. What it mainly optimizes is still how execution is chosen and how a filesystem is shared: isolates for light work, containers for heavy work, workspace attached to a Durable Object. That answers "there is not enough global compute for every agent to keep a full Linux box forever." It does not automatically answer a different layer: whether the root identity, exit rights, and checkable history of that computer belong to you, or to the current platform.

You might say: isn't that just how infrastructure works? For stateless functions and short jobs, yes. Agents are no longer functions.

Take a concrete case. You have an agent that, for months, manages your repos, mail, calendar, and knowledge base. It reads private materials. Sometimes it sends mail, opens a PR, or changes config on your behalf. One day you want to switch clouds, or you simply want a straight answer: last week's outbound email, who authorized it, which materials it used, and how much resource it spent.

Then the real questions are not "how many milliseconds to cold start?" They are:

Who does this action represent? Why did it get this permission? Was the permission attenuated from another agent? Which model, which code, which inputs? Did the data leave a boundary you actually control? Can the result be verified? If you switch clouds, do identity and history still travel with you?

A VM alone does not answer those questions. Splitting the answers across cloud account permissions, a database, logs, key management, and application code leaves seams that are hard to audit. Sandboxes solve "where does untrusted code run?" They still do not fully solve "how does a long-lived actor safely own data, authority, history, and a verifiable identity?"

Design the machine the other way around

What we are building is called ARC: Agentic Realm Computer. The word realm is not decoration. It means this machine is meant to be held under self-sovereign control, not rented as a room on someone else's platform.

In one line: do not stuff agents into a computer designed for human apps and tenant accounts; redefine the computer as a sovereign container for agent identity, state, authority, and verifiable history.

On our side, that machine has three layers, in deliberate order.

At the bottom is AFS (Agentic File System). Think of it as a shared working surface for agents: databases, APIs, local files, tools, and memory all become paths that can be mounted and read or written the same way. People and agents are both first-class. We already wrote about Small World: every agent sees not the global world, but a small world projected for it; what is outside that world is not Permission Denied, it simply does not exist. We also wrote Context is not cognition: organizing materials well is not the same as the system learning to think. AFS first makes context a system problem. It does not pretend cognition has been solved.

In the middle is AOS (Agentic Operating System). This layer is meant to handle execution, scheduling, authority constraints, network policy, and lifecycle. That is the target design, not a claim that every piece is complete today. Agent behavior is probabilistic. Safety boundaries have to be deterministic. You cannot depend on the model "knowing better." Authority should not be a long-lived secret stuffed into an environment variable. It should behave more like a ticket that can attenuate, be revoked, carry a budget, and bind to a purpose: a child agent can only receive less power, never more.

On top, the machine finally appears as ARC to people and agents: identity, workspace, migration, governance. AFS and AOS are the guts; ARC is the layer you face when you actually "own a computer." On the product page the practical mapping is simple: an application describes what it is supposed to do, ARC runs it, and AFS expresses the resources it needs to touch. Keep the roles separate, and when something must change you know which layer to touch.

Deliberate order: AFS under, AOS between, ARC facing people and agents. AOS is named as target design in the text above.

We have spent years on decentralized identity (DID), verifiable credentials, and user-owned data. Self-sovereign is not a slogan for us. It is a first-principles result. If root keys, audit history, and exit rights default to the operator, your so-called agent computer is still a tenant on someone else's machine. Sovereignty does not mean the hardware must sit in your house, and it does not mean rejecting the cloud. The cleaner definition is this: whether the workload runs on a local device, a managed host, a public cloud, or a third-party sandbox, the owner can control root identity and data keys, constrain what the agent may do, export all state, and change operators without changing the upper identity semantics.

So sandboxes and light VMs are not enemies here. They are pluggable execution material. High-risk work can go into stronger isolation; low-risk work can stay light. The top-level object remains the agent and the workspace, not an instance ID owned by one cloud.

What we can say honestly today

The boundary has to be drawn here, or a judgment turns into a promise.

What is already real is the direction and the foundation. AFS is not a slide-deck abstraction. Shared paths, small-world projection, and hanging databases and tools into one working surface are in the implementation, and you can read concrete posts about them on our site. ARC as the environment that runs applications is a real product path, not a rebrand. We keep identity ahead of platform accounts, and we keep durable state separate from disposable runtime: an instance can be rebuilt; the data and credentials that matter should not vanish with one deployment.

What we cannot yet write as "complete today" also needs to be said. A full operating-system capability model, lossless multi-operator migration, checkable provenance for every agent action, and opening a sensitive workspace only after the execution environment has been proven trustworthy, are architecture directions we believe are right. That is not the same as every piece already sitting in your hands as a finished external product. Shipping design as if it were status is a lie. Naming it as direction is honesty.

You might ask: then why not just use an existing sandbox for now? Often you should. If the job is to run generated code, run an eval, or spin up a temporary environment, today's sandboxes are good enough and lower friction. ARC starts to matter when the agent must live for a long time, act across tools, produce external effects on your behalf, and when you care whether identity, the authority chain, and exit rights belong to you. That is an architecture judgment, not a filled-out feature checklist.

That is also why we refuse to position this as "a faster-booting, more heavily isolated sandbox." Someone will always boot a few milliseconds quicker. Next year there will be another light-VM product with a longer feature list. The difference that holds up is simpler: durable state, user sovereignty, constrained authority, and checkable execution are composed into one machine semantics, instead of being scattered across platform objects.

The market will keep shipping better boxes. That is fine. Sandboxes will keep being useful.

But the load-bearing word in the title is not "computer." It is "their own."

You can give an agent a machine that boots fast, has a full filesystem, and smartly routes work between isolates and containers. If root identity still comes from a platform account, if keys and history cannot leave the current operator, if switching clouds means switching personas - it is still a rented room. Rename it computer and the tenant is still a tenant.

Agents do not need a better sandbox, and they do not need a sandbox rebranded as a computer. They need a machine that belongs to the owner, can leave, can be checked, and remains the same machine after the execution backend changes. Without "their own," every other capability is still just a better box.

We call that ARC. Boxes can turn over every year. Machine semantics should not drift. If they drift, the agent has no "own."