A computer for AI agents is a dedicated virtual machine — with its own Linux kernel, filesystem, and network stack — that an agent can create, control, and destroy programmatically through an API. It gives an autonomous agent the same thing a human developer has: a real machine to install packages on, run untrusted code in, persist state across, and operate with root privileges, all without touching the host infrastructure it runs on.
That definition sounds obvious until you try to build agent infrastructure on the primitives most teams reach for first. Spin up a container, let an agent install its dependencies and clone a repo, then watch the whole environment vanish the moment the container restarts — every pip install, every cloned repo, every hour of build cache, gone. Or try to point a computer-use agent at a real browser inside a sandbox that has no display server, no GPU, and no root, and watch it faceplant on the first CAPTCHA. The pattern is the same in both cases: most "agent sandboxes" are built to run one function call, not to be a computer.
The Persistence Gap That Sets Up the Architecture
Most container and sandbox primitives treat storage as scratch space. That's fine for a request-scoped function: it runs, it returns a value, it disappears, and nobody misses the filesystem underneath it. Agents don't work that way. A coding agent clones a repo, builds a virtual environment, and expects both to still be there an hour later when the next tool call comes in. A research agent runs for days, checkpointing intermediate results it cannot afford to recompute. A computer-use agent midway through a multi-step browser flow needs the session it left open to still be open.
A computer for agents has to be defined by more than kernel isolation and boot time. It has to be defined by what the machine can still do for you an hour, a day, or a week after it started.
What a Computer for AI Agents Actually Means
A computer for AI agents is a full virtual machine, provisioned and torn down through an API in well under a second, whose filesystem and state can outlive any single execution. Four properties distinguish it from both a stripped-down sandbox and a traditional cloud VM:
- A persistent, durable filesystem. The home directory — cloned repos, installed toolchains, build caches, model weights — survives the machine sleeping, waking, and even moving to a different physical host. State isn't something you re-create every time; it's something you accumulate.
- The full flexibility of a real Linux machine. Root access, arbitrary packages, and no artificial ceiling on what kind of workload runs inside it. That includes batch jobs and long compiles, but it also includes full GUI and browser stacks — Xvfb, Chromium, whatever an agent needs to actually see and click a page. A locked-down runtime that only knows how to execute a function call can't do this; a real machine can.
- Programmatic lifecycle. The agent, or the platform running it, creates the machine, runs commands, and destroys it via API calls — not a dashboard, a Dockerfile, or a provisioning ticket. On Dedalus, that's a single call: for example
dedalus machines create --vcpu 1 --memory-mib 1024 --storage-gib 5, thendedalus machines createto run a command inside it. - Fast enough for agent needs. Traditional cloud VMs boot in tens of seconds to minutes — fine for infrastructure you provision once, fatal for an agent that spins up a machine per task. Dedalus Machines cold start in 50ms. That number matters because if you're paying a multi-second boot tax on every task, the boot speed of your machine becomes your agents main bottleneck.
A computer for agents also needs a real security boundary — its own kernel, not a shared one with namespaces layered on top. That's a big enough topic on its own that it lives in a separate post; the isolation model is necessary to agents that break containment. The mental model for the rest of this post is right there in the name: it's a computer. Everything you know about operating a Linux box — files, processes, ports, packages, root — applies. The only difference is that the operator is an LLM and the machine's entire lifecycle is an API surface.
Flexibility: Beyond Batch Jobs
Root access is table stakes for a real machine, but it's also the thing most agent sandboxes quietly take away — usually in the name of safety, sometimes just because the runtime never had it to begin with (a V8 isolate or a WASM sandbox was never going to give you a kernel). That tradeoff shows up hardest with computer-use workloads. Driving a real browser means Chromium wants its own sandbox, a real network path, a display server, and often root to install its own dependencies. A locked-down container or an isolate-based runtime can offer none of that. A full VM can offer all of it, because it isn't pretending to be anything other than a Linux machine.
That flexibility is what lets one primitive cover an unusually wide range of agent workloads without special-casing any of them: a coding agent compiling a large project, a browser-driving agent clicking through a multi-step flow, a research agent downloading and processing a large dataset, a swarm of parallel workers each exploring a different path through a task. None of these need a bespoke runtime. They need a computer.
Container vs. VM vs. Dedalus Machine
Containers are fast and cheap, but the durable-state question they punt on usually gets solved with a bolted-on network volume — which reintroduces exactly the latency containers were supposed to avoid. Traditional VMs solve persistence and isolation properly but take tens of seconds to boot, which kills the create-a-machine-per-task model agents depend on. Dedalus Machines collapse that tradeoff, dimension by dimension:
Kernel isolation. Containers share the host kernel. Traditional VMs and Dedalus Machines each get their own.
Filesystem persistence. Containers are ephemeral by default, and the usual fix — a bolted-on network volume — is slow. Traditional VMs persist, but the VM itself is slow to provision. Dedalus Machines persist through an in-kernel hot path that survives sleep, wake, and even host migration.
Flexibility (root, GUI/browser workloads). Containers are often limited — no root, no display stack. Traditional VMs and Dedalus Machines both offer the full flexibility of a real machine.
Cold start time. Containers start in under a second. Traditional VMs take tens of seconds to minutes. Dedalus Machines start in about 50ms.
Idle billing. Containers vary by provider. Traditional VMs are usually billed while running. Dedalus Machines bill per second, with no charge while asleep.
Persistence and flexibility at container-like speed is where the architecture actually pays off for agent workloads.
What Agents Actually Do Inside These Machines
A computer for AI agents is where the following happen without anyone having to think about it:
- Drive real browsers for computer-use tasks. A full display stack, a real Chromium process, real network access, and root to install whatever the agent's tooling needs.
- Build and persist real projects.
apt install,pip install,cargo build,npm ci— the agent gets a mutable system with root, and whatever it installs survives to the next session, so a long-running agent keeps its working directory, cloned repos, and toolchains between runs instead of re-paying setup cost every time. - Run long, stateful workflows. Research tasks that run for hours or days, checkpointing as they go, without the platform quietly discarding everything the moment a call hangs or a process needs to sleep.
How to Evaluate a Computer for AI Agents
Filesystem and persistence model. Does state actually survive sleep and wake? More importantly, does the filesystem stay fast under the small-file-heavy operations agents actually run — package installs, repo checkouts, editor indexing — or does it only look good on a sequential-read benchmark?
Flexibility. Root access, arbitrary packages, and no ceiling on workload type. Can it run a full GUI or browser stack for computer-use agents, or only a narrow language runtime?
Cold start time. This decides whether you can provision a machine per task rather than pooling and reusing one. Fast enough to be invisible to the agent loop is the bar; slow enough to notice defeats the point of persistence in the first place.
API-first provisioning. The entire lifecycle — create, execute, expose a port, sleep, destroy — has to be API calls an agent can author itself. A dashboard or a Dockerfile in the loop means it wasn't built for autonomous use.
Cost model. Per-second billing that stops when the machine is idle suits bursty agent traffic; reserved capacity suits steady load.
Isolation model. Your agent needs kernel level isolation to run untested code or complete non-deterministic tasks without impacting other machines.
Frequently Asked Questions
What is a computer for AI agents?
A computer for AI agents is a dedicated virtual machine — with its own Linux kernel, filesystem, and network stack — that an AI agent creates, controls, and destroys through an API. What makes it a computer rather than a sandbox is that its filesystem and state persist across sessions and it can run any workload a real Linux machine can, from long builds to full browser stacks for computer-use tasks — not just a narrow, request-scoped function.
Why does persistence matter for AI agents?
Agents are frequently long-running: they build toolchains, clone repositories, checkpoint research, and pick up multi-step tasks across many separate calls. If the environment resets between calls, the agent re-pays the full setup cost — every install, every clone, every warmed cache — on every single task. A persistent filesystem turns that recurring cost into a one-time cost, provided the persistence layer stays fast under real, metadata-heavy workloads rather than just under simple benchmarks.
Can AI agents run browser-based or computer-use workloads on a computer for agents?
Yes, and this is one of the clearest advantages of a real VM over a container or an isolate-based sandbox. Driving a browser for a computer-use task requires a display server, a real Chromium process, genuine network access, and often root to install dependencies — all things a locked-down runtime typically can't provide. Because a computer for agents is a full Linux machine, it supports a GUI stack the same way any Linux desktop or CI runner would, with no special casing required.