Why AI Agents Need Purpose-Built Computers, Not Cloud VMs

It's easy to assume an agent just needs a container or a VM, because that's what a developer needs. Ivan Burazin's crucial insight is that this assumption breaks down fast. Agents are a fundamentally different user. They need computers that are stateful and long-running—you don't want your agent's work environment destroyed because an eval run finished. They also demand insane cold-start speeds for spiky, parallel workloads like running 50,000 RL tasks concurrently. Daytona’s early pivot hinged on this mismatch: the infra built for humans (e.g., Kubernetes, EC2) is ergonomically and technically wrong for agents. Their solution is a bare-metal scheduler that treats a computer as a composable API primitive, enabling things like zero-network-latency snapshots and dynamic resizing to avoid out-of-memory errors.

A second, less obvious shift is happening in workload types. Daytona is seeing a move from predictable, “follow-the-sun” usage patterns of long-running coding agents to wildly spiky, all-or-nothing research and eval workloads. This creates a novel infrastructure problem: maintaining bare-metal capacity for 100,000-CPU peaks with a 15% mean utilization isn't sustainable without new orchestration and pricing models. It's the same problem serverless databases and edge compute providers are facing when repurposed for agentic traffic.

The company is also betting heavily on an under-explored angle: giving agents access to legacy Windows applications via ultra-fast computer-use sandboxes. This is a direct attack on the massive RPA (Robotic Process Automation) market. The logic is sound: 56% of knowledge work is locked in legacy apps, and APIs don’t cover everything. A headless API is often insufficient, so the most effective agent interface is often just taking over a desktop. The challenge is execution—managing Windows licensing and, critically, overcoming macOS's architectural hostility to scalable virtualization.

For engineering leaders, the core takeaway is that agent infrastructure isn't a commodity. Choosing between a generic cloud VM, Kubernetes, or a purpose-built agent runtime has direct consequences on your agent's reliability, speed, and cost. The market is demanding a 'Twilio for compute'—a consumption-based API that abstracts away the scheduler, not another infrastructure platform to manage. The competitive moat here isn't just speed, but ergonomics: enabling an agent to do things like dynamically install dependencies in a snapshot, or run Docker-in-Docker, without the development team building a bespoke orchestration layer.