Daytona has announced a $60 million Series B at a $1 billion valuation, adding capital to its effort to build computing infrastructure for AI agents. Its October 20 announcement names FirstMark Growth as the lead investor and puts total funding at $91 million.
In its funding announcement, Daytona describes an execution platform for agents that need to run software, use browsers and retain their work between steps. Strategic investors joining the round include Qualcomm Ventures, Samsung Next and Okta Ventures.
For businesses deploying agents, the practical question is what happens after a model decides on an action. Code needs somewhere to run, files need somewhere to live, and a failed attempt needs to be contained without disrupting other work.
What Daytona is building
Daytona provides programmable computing environments, often called sandboxes, that developers can create and manage through software. Its documentation describes operations for running code, handling files and controlling the environment’s lifecycle.
Consider a hypothetical coding agent asked to repair a spreadsheet-processing script. It needs to open files, install dependencies, change the code and run tests. The model’s answer is only one part of that job. The execution environment determines where those actions happen and which resources they can reach.
Daytona’s funding announcement places that execution layer at the centre of its strategy. The company describes environments that can preserve state, resume work and branch into parallel attempts. For a developer, that could mean comparing two approaches to a task without rebuilding the workspace each time.
That capability also creates an operational responsibility. A team must decide which branch contains the accepted result, which copies should be discarded and what data must survive after the task ends.
Fast startup is only one part of task completion
Fortune’s reporting on the round quotes CEO Ivan Burazin saying Daytona can configure a sandbox in 60 milliseconds. That is a company performance claim, not an independently established completion time for an agent’s task.
A fast environment can reduce the delay before work begins. It does not establish how long the model will spend reasoning, whether a package download will stall or how often the agent will need to retry a failed action.
The distinction becomes commercially important when teams compare suppliers. A service that starts quickly could still produce an expensive workflow if each task requires several failed attempts or leaves unused environments running.
Our coverage of doubleAI’s Maxwell execution technology examines a related measurement problem: a gain in one part of execution needs to be assessed against the time and cost of the complete workload.
For Daytona, a useful comparison would measure the interval from submitting a task to obtaining a correct, reviewable result. Startup latency belongs inside that measurement, alongside model calls, tool execution, retries and cleanup.
Isolation and permission need separate checks
Daytona’s isolation documentation distinguishes runtime, network and organization boundaries. It also describes different sandbox classes with different mechanisms, including containers and virtual machines. Buyers should check the class used for their workload rather than assume that every environment has an identical boundary.
For an agent deployment, containing a process and authorizing an action solve different problems. An isolated agent could still misuse a credential that a developer intentionally supplied to it.
In a hypothetical customer-support workflow, the environment might be allowed to read a sample ticket but should require approval before changing a customer’s account. Whether that restriction holds depends on the application’s permissions and approval design as well as the computing environment.
A deployment review should therefore ask what the agent can reach, what it can change and what evidence remains after an error. Useful checks include access to unrelated files, outbound connections and the handling of credentials when work is paused or copied.
What buyers should measure
A focused pilot could run the same harmless coding task on Daytona and a comparable environment, using the same model, dependencies and success criteria. Include both fresh starts and repeated runs, then increase concurrency to see how delays and failure rates change.
The commercial measure should be cost per successful task. Count the resources consumed by unsuccessful attempts, retained data and idle environments, together with the engineering time required to operate the system.
Recovery deserves its own check. Interrupt a task, resume it and confirm that the resulting files are correct. When an attempt is abandoned, verify that its resources are released and that its output cannot be mistaken for the accepted version.
Daytona’s new valuation raises expectations for a business supplying the computers behind agent workflows. The evidence that will matter to customers is whether those workflows become easier to operate, recover and budget for as usage grows.
Featured image: Daytona’s Series B funding announcement. Image credit: Daytona.
About Puneet Sharma
Puneet Sharma · Freelance Writer
Puneet Sharma is a freelance writer covering AI agents, automation and the software changing how we work. His coverage at AgentsCalling starts with the questions a reader might ask over a conversation: What does this tool actually do? Where does it fall short? And is it useful beyond the demo? His articles explore new launches, practical workflows and the trade-offs behind giving software more responsibility, with explanations that make room for readers who are still getting familiar with AI.
