The Takeaway: Agents stop being toys the moment you give them their own computer, permissions, and isolation.
- Sandboxes are not just security wrappers; they’re the actual execution environment for digital knowledge workers.
- The old cloud stack was built for stateless apps, but agents are stateful, long-running, and often need concurrency.
- The real bottleneck isn’t the model anymore — it’s memory, tool access, and whether the agent can safely act in the real world.
Ivan Burazin, CEO of Daytona, has spent years building developer infrastructure, first in cloud IDEs and now in agent sandboxes. His core thesis is blunt: “every agent will need at least one sandbox, sometimes more.” Why? Because if an agent is supposed to do real work — fetch bank data, run scripts, browse the web, or operate across multiple steps — it needs a machine the way a human worker needs a laptop.
That’s why he rejects the idea of running serious agents on your own laptop. It breaks security, kills concurrency, and makes long-running work fragile. His bank-data example is telling: Claude asked him to “log in and give me access,” and that was the moment the whole setup failed. The fix was to give the agent its own Daytona account, its own phone number for 2FA, and tightly scoped permissions. The point isn’t trust; it’s containment.
Burazin also draws a sharp line between the pieces of the agent stack: models are the brain, tools are the hands, memory is still messy, and orchestration is basically management. The big frontier labs are bundling more of this together, but Daytona’s bet is that the sandbox remains the execution layer underneath it all. The deeper insight: agents don’t just need intelligence — they need infrastructure that lets them work like employees without becoming liabilities.