Daytona is building computers for AI agents that have to do real work
Daytona wants to give agents isolated computing environments for real work.📷 AI-generated image / TECH&SPACE
- ★Daytona cites 74 percent month-over-month growth and 850,000 daily runs as a signal of demand for agent infrastructure.
- ★Bare-metal sandboxes and Agent Cloud target isolated computing environments for agents, not just another API orchestration layer.
- ★RL evals matter because agents need to be tested on real tasks, files, terminals, and system-level failure modes.
Latent Space spoke with Ivan Burazin, CEO of Daytona, about one of the more practical questions in the AI industry: what happens when agents are no longer expected merely to return text, but to open an environment, run code, manipulate files, and survive the messy edge cases of real computer work. The headline metric is aggressive: 74 percent month-over-month growth, alongside 850,000 daily runs. The more important signal is the product direction: bare-metal sandboxes, RL evals, and a new Agent Cloud.
That is the difference between an agent as a conversational interface and an agent as an executing process. In the first model, the user asks, the model answers, and everything sensitive stays outside the blast radius. In the second, the agent receives a computing space where it can work: terminal, files, dependencies, runtime, errors, and constraints. Daytona is trying to become an infrastructure layer for that transition, much as development environments became an invisible but decisive substrate for modern software teams.
A conversation with Ivan Burazin shows why AI-agent infrastructure is moving from abstract APIs toward isolated sandboxes, bare-metal machines, and evaluations built around real computer work.
An AI-agent sandbox has to handle terminals, files, errors, and evaluations.📷 AI-generated image / TECH&SPACE
Bare-metal sandboxes matter here because they are more than a branding detail. If an agent performs a task that lasts, builds a project, runs tests, or deals with messy system state, isolation and control are not optional. A standard cloud container may be good enough for many jobs, but the conversation with Burazin points to a more demanding layer: higher performance, clearer execution boundaries, and environments that an agent can treat as an actual computer rather than a short-lived API tool.
The second half of the story is evaluation. RL evals in this context are not academic decoration; they are a way to test agents where they usually fail: multi-step actions, bad assumptions, files that are not where the model expects them, terminal commands that break, and tasks that require feedback loops. If agents are supposed to improve through trial and correction, the evaluation environment has to be real enough to punish poor moves, yet isolated enough for the system to repeat them without damage.
Agent Cloud sounds like the natural product layer for that: managed places where agents can work, be observed, and be evaluated. Daytona already has a public footprint as a development-environment tool, including open-source work on GitHub, but this phase is different because it targets infrastructure for agents as the primary users of computers. That changes the success criteria. It is not enough for a sandbox to start quickly; it has to be reliable at high run volume, isolated enough for risky tasks, and transparent enough to explain why an agent succeeded or failed.
That is why this story matters beyond Daytona itself. AI agents are often presented through interfaces, demos, and benchmarks, but their usefulness increasingly depends on hard infrastructure: where they execute, what they are allowed to touch, how they reset, and how their work is measured. If the numbers from the interview reflect real demand, the market is not asking only for smarter models. It is asking for safer computers for models that are expected to do work on our behalf.

